IRC Logs

Log of #ghostscript at irc.freenode.net.

Search:
 <<<Back 1 day (to 2013/01/30)2013/01/31 
tkamppeter henrys, thanks.00:08.55 
kens Hmm, according to the Register, VS 2012 is to gain support for Git....07:59.03 
chrisl That'll be MS Git, which will be similar, but confusingly incompatible with actual git.......07:59.52 
kens <sigh> Probably true....08:00.03 
  "Embrace and extend".....08:00.18 
chrisl Oh yes08:00.31 
  kens: just double checking - for linearised output from pdfwrite, you use "-dFastWebView"?10:40.43 
kens Yes, its called 'optimised for fast web viewing' in the Acrobat dialog10:41.05 
chrisl Thanks - it's just for the "highlights" section in the release notes10:41.34 
kens 'Linearized' woudln't mean much to anyone not familiar with teh spec, in the same way that 'Outlines in the spec are called 'Bookmarks' in Acrobat10:41.36 
paulgardiner Robin_Watts, tor8: Just about to rename fz_make_annot. Should I move that and the other call to fitz-internal.h too?11:05.40 
Robin_Watts paulgardiner: Just done it.11:06.57 
  Or rather, I've just pulled in your changes and rewritten the history so that it's always been fz_create_annot.11:07.20 
  I'm just cluster testing before pushing it to golden.11:07.41 
paulgardiner Magic11:08.05 
Robin_Watts Dunno about moving the calls. Probably a good idea.11:10.08 
paulgardiner I guess that can be a follow up, in any case11:10.37 
Robin_Watts fz_create_annot and fz_set_annot_appearance ? and fz_annot_type ?11:10.47 
  I'll move them too in the history. Will just take a second.11:11.30 
paulgardiner fz_annot_type is not new and can be used with access only to fitz.h11:12.16 
  No sorry11:12.25 
  You're right11:12.33 
Robin_Watts cluster seems to have jammed.11:24.37 
  it'll clear itself in a mo.11:24.48 
  paulgardiner: Pushed.11:33.39 
paulgardiner ta11:33.48 
Robin_Watts oh, do you still have the second half of the pdf write commit ?11:34.57 
  I should get that back from you.11:35.09 
paulgardiner It's on paulg/robin, but has yet to be rebased11:35.46 
Robin_Watts I have cherry picked it in.11:37.55 
paulgardiner May not build because of the fz_bbox changes11:38.47 
Robin_Watts hmm. I had a review that made pdf_functions into fz_functions because the pdfwrite commit needed it.11:39.01 
  Did you roll that into your commit? Or did it get flattened into the "what's left" commit ?11:39.22 
paulgardiner That's there isn't it? Just before the second part of the edit changes11:39.35 
Robin_Watts on master?11:40.10 
  no, on paul/robin. I see it. Thanks11:40.32 
paulgardiner "Make pdf_functions public as fz_functions" on paulg/robin11:40.33 
kens doesn't like the look of the latest support email for chrisl13:32.37 
chrisl Well, if the fonts are embedded then they are using the old, deprecated code, and that's not really an area I know much about14:24.54 
kens Hmm, I've meddled with it in the (dim and distanat) past14:25.33 
chrisl I assume that "BLK memory" is their memory manager, and I have no idea how our interaction with that works14:30.39 
kens Beats me boss14:30.50 
chrisl I'll just wave my magic "make it faster" wand, and all will be well.......14:31.25 
kens Yeah, that's largely how I felt14:31.37 
chrisl No test job attached either......14:40.52 
kens Not ideal14:43.49 
Robin_Watts chrisl: Urm... isn't blk memory the basic memory thing in unix?14:54.39 
  Nope. That's brk, sorry.14:55.29 
chrisl Robin_Watts: and sbrk(), yes. BLK memory is definitely the memory from their memory manager - it's possible we're being too aggressive in freeing memory back to it14:56.40 
kens chrisl if/when you get a test job let me know if I cna help at all14:58.28 
chrisl kens: okay, thanks. This may well be a minefield :-(14:59.07 
Robin_Watts likewise.14:59.19 
  chrisl: oh, their performance problems are clist and afs?15:08.26 
kens Indeed so15:08.37 
Robin_Watts Does that mean they are fax encoding glyphs bitmaps into the clist ?15:08.57 
kens I don't think so, why would they be fax encoded ?15:09.16 
Robin_Watts ISTR a tweak we did to disable that for someone.15:09.23 
kens Really ? Well tht could be it I suppose15:09.36 
chrisl yeh, I think we did something there for them15:09.40 
Robin_Watts kens: Cos all mono bitmaps going into the clist were '2d' compressed - which means fax.15:09.51 
kens But one of their main concerns seems to bte that the memory gets slower15:09.53 
  I must admit I wouldn't have bothered compressing small glyphs15:10.20 
  especially if we are writing a display list15:10.34 
chrisl I'm not convinced of the memory connection, the time taken for the font and glyph drawing operations doesn't vary that much between pages15:10.54 
kens Well, I'm going by what Len says, which may not be a good idea...15:11.19 
Robin_Watts I definitely found something in this area, and tweaked it for someone. I just can't remember who. I don't think the changes made it back onto the trunk though.15:11.23 
  kens: They have a habit of 2+2 = 18.15:11.35 
kens :-)15:11.44 
  I htought it was more like 2+2 = giraffe15:11.55 
Robin_Watts No, that'd be a compiler error, so they'd catch that.15:12.14 
kens I think I'm going to have a look at this xpswrite thingy, my head is spinning too much with pdfwrite and images15:13.17 
chrisl Page 1, show takes 27, page 2 27.5, page 3 27, page 4 27.4, ......... page 11 show takes 27.315:14.22 
kens Well that seems pretty consistent15:14.35 
chrisl So, the text ops aren't getting slower in the way that I'd expect if the cause was fragmented memory15:14.54 
kens Well he's suggsting that freeing the memory takes longer with each page, so the page time should increase15:15.28 
  THough I guess it might take quite a few pages15:15.41 
  Presumably you still don't have a test file, so we don't know what kind of fonts they are actually using15:16.02 
chrisl They're CIDType 2 - base on the calls to buildfont11 in the stats15:16.34 
kens Well, that's probabl;y going to be slower then. Don't fortget that the PDF interpreter does a cshow for each glyp[h15:16.58 
chrisl Not in this case - it's definitely spending the time in "show" - there are a few calls to ashow15:17.53 
kens Hmm, that's 'odd' if its a CIDFont I'm reasonably sure all glyphs are drawn individually and we do the hacky PostScript thing to reposition between glyphs15:18.29 
Robin_Watts tor8: ping15:18.35 
tor8 Robin_Watts: hey15:19.06 
chrisl kens: well, I'm not going to try to dig out a job to try it, I'll wait until they supply one15:19.11 
kens Yes, that makes sense15:19.19 
  They need to be 'encouraged' to always do that15:19.30 
Robin_Watts tor8: I just pushed the latest 'reference' patch.15:19.32 
  Can you see anything else I should change in it?15:19.42 
tor8 I'll take a look15:19.47 
Robin_Watts I want to tweak fz_bound_gel and fz_scan_convert.15:19.56 
chrisl kens: I do find it strange that "show" takes so much time, but not "type42execchar"......15:20.15 
kens Well if its doing the 'exit back to the interpreter and run the PostScript' thing for every glyph, it would be slower.15:20.41 
Robin_Watts chrisl: remember that their profiling is down to them manually adding code, I think.15:20.45 
  So "show" probably means "show, and anything it called that they didn't instrument"15:21.01 
kens It could be that15:21.25 
chrisl Yeh, but "show" doesn't interpret or render any glyphs, that's what type42execchar does - and that's where I would expect the time to go.....15:21.56 
kens Only if its a TrueType font, I suppose it is ?15:22.15 
tor8 Robin_Watts: fz_transform_xxx should have out argument first, since we're changing the prototype might as well fix that while we're breaking stuff15:22.33 
  fz_widget_bbox shouldn't return a rect pointer (who owns it) but fill in a passed one15:23.10 
kens CDevProc, that's the thing I'm trying to remember15:23.11 
chrisl kens: Yes, CIDType 2 - but the point is still valid for other font types, just type1execchar, type2execchar and so on15:23.19 
tor8 fz_widget_bbox(&out, widget)15:23.19 
  or pass by value15:23.27 
chrisl CDevProc would "register" as part of the execchar or setcachedevice, not show.....15:23.48 
tor8 same with all the other fz_bound_xxx functions15:23.49 
Robin_Watts tor8: It returns a const one currently.15:24.05 
kens chrisl they may not be counting the call out to the interpreter for executing the CDevProc15:24.18 
Robin_Watts which implies ownership stays with the widget to me. but I can update that, sure.15:24.38 
kens TBH I think we need to see the file15:24.44 
tor8 Robin_Watts: how does fz_pixmap_bbox return? that one doesn't have a fz_bbox internally15:24.46 
chrisl kens: But it still wouldn't appear in the "show" time15:24.57 
Robin_Watts That returns into a bbox passed into it.15:25.04 
kens chrisl, where do you think it would appear ?15:25.15 
chrisl Probably setacachedevice15:25.30 
tor8 Robin_Watts: would it be horribly messy to split this into two--one for matrices, which I completely agree with should be done, and anoher for rects?15:25.41 
kens Not setcachedevicde2 ? DO they instrumetn that ?15:25.51 
tor8 I think the rects may end up more trouble than gained by passing by reference since they're used as return values a lot more than the matrices15:26.07 
chrisl kens: yes setcachedevice2, and yes it is instrumented15:26.33 
Robin_Watts tor8: It'd be an awful lot of tedious unpicking of changes.15:26.38 
kens chrisl oh well then#15:26.44 
tor8 if we pass in the rect to fill out, we can return it, to allow nesting and make clearer ownership15:26.54 
chrisl But as you say, stabbing in the dark at the moment....15:27.07 
Robin_Watts tor8: Yes. I was wondering about changing fz_transform_rect(m, r) to be (r, m) etc15:27.24 
  but I had a look last night and couldn't see any obvious gains to be had with chaining that.15:27.54 
tor8 I'm surprised to see so many places where you pass the inout / out argument last. I guess it you haven't done what you talked about yesterday yet?15:28.10 
Robin_Watts I started to, but then cowarded out.15:28.37 
tor8 Robin_Watts: I keep having to look up the argument order every time I use the fz_transform functions15:28.44 
  ah, right.15:28.47 
  well, separate step for that then15:28.51 
  but the transform ones can be done in this one I think15:29.08 
  I think all the fz_bound_xxx should take the same pattern. to go with what you've done elsewhere: fz_rect *fz_bound_xxx(ctx, xxx, fz_rect *out)15:30.17 
Robin_Watts ok.15:31.03 
  and transform_rect should be (m, r) or (r, m) ?15:31.33 
tor8 though I'm happy enough if you decided on fz_rect *bound(out, ctx, xxx)15:31.36 
  (r, m) and (p, m)15:31.42 
Robin_Watts With 2 args, I think C's (out, in) convention wins.15:32.03 
  With longer sets of args (especially involving ctx), I think putting out at the end is probably best.15:32.28 
  Though I admit there may be a schizm in my logic there.15:32.42 
tor8 where we're already sending in a ton of other args I don't see a stunning benefit to the (out, in) set15:32.43 
  but it would let us easily see which are modified and expected to hold output, and which are just input15:33.05 
  still, heavy use of const could do that too, but would mean looking at headers more15:33.29 
Robin_Watts Well, in VS, you get the prototype after you type fz_function_name(15:34.03 
tor8 I prefer not to rely on such things :)15:34.24 
Robin_Watts Something is hammering apache on casper.15:34.32 
tor8 Robin_Watts: is there really a need for separate fz_scale and fz_pre_scale?15:35.15 
  I guess you could call it an optimization over initializing an identity matrix at the head of every matrix calculation, but API bloat!15:35.53 
  s/fz_pre_/fz_cat_/ ?15:36.23 
Robin_Watts fz_scale(matrix, sx, sy) is the same as fz_pre_scale(&(matrix = fz_identity), sx, sy) (if that's even real C).15:36.27 
  I much prefer pre, as it reinforces the ordering.15:36.48 
  cat would imply post to me.15:37.00 
tor8 as in fz_concat matrix? ;)15:37.11 
  fz_mul_scale then?15:37.15 
  we only every do it in one direction now15:37.26 
Robin_Watts in fz_concat we specify all 3 args.15:37.27 
  hence the order is implicit. fz_concat(a, b, c ) a = b.c;15:37.50 
tor8 explicit you mean?15:38.13 
Robin_Watts fz_cat_scale(m, sx, sy) is that: m = m .scale(sx,sy) or m = scale(sx,sy) . m ?15:38.30 
  both :)15:38.41 
  It's implicitly explicit :)15:38.50 
  or explicitly implicit. One of the two.15:39.11 
paulgardiner Robin_Watts, tor8: looking at mudraw.c, might that be slower because each rect->x0 needs to do the indirection, whereas before the values might be in registers?15:39.39 
tor8 Robin_Watts: well, going by opengl experience, where the scale and rotate etc calls always concatenate onto the current matrix in the same order15:39.45 
paulgardiner ... compiler can't know if rect is altered by the fprintf call.15:40.12 
tor8 paulgardiner: quite likely. on LLVM intermediate code, the rects were passed as arguments in two doubles15:40.29 
Robin_Watts paulgardiner: Do we care about mudraw.c ?15:40.45 
tor8 we only care about the inner loops15:40.54 
Robin_Watts mudraw.c is not speed critical. I think it's a win in all the places we care about.15:41.10 
tor8 which is why the 1% performance boost on windows surprised me15:41.15 
Robin_Watts Probably I ought to add a sprinkling of 'restricts'15:41.21 
paulgardiner Robin_Watts: I was just thinking it could be more general. I'd just taken a quick look at the patch and the thought struck me15:41.28 
tor8 Robin_Watts: I think const can serve a lot of the same purpose for hinting to the compiler that aliasing won't be an issue15:41.47 
  but restrict doesn't hurt either15:41.55 
paulgardiner Oh yeah. The 1% proves it. I forgot.15:42.02 
  Ah right. const could help. Good point.15:42.30 
Robin_Watts tor8: I would be MUCH less resistant to the idea of losing fz_scale to fz_pre_scale now than I was previously.15:42.35 
  I'm not sure const does help.15:42.40 
  fz_concat(a, const b, const c)15:42.53 
tor8 Robin_Watts: hm, yeah. point.15:43.01 
  (re the const not always helping)15:43.06 
Robin_Watts All const says is that fz_concat can't change anything via b or c.15:43.13 
  it doesn't say that writes to a won't change b or c.15:43.26 
tor8 Robin_Watts: yeah, it doesn't say anything about b or c being changed via a15:43.28 
Robin_Watts That's what restrict is for, AIUI.15:43.33 
tor8 which restrict does15:43.36 
paulgardiner Robin_Watts: oh yeah. You're right15:43.45 
Robin_Watts Are there any funky git tools for separating a commit into two?15:49.15 
  something in gitk where you can choose which chunk goes in which commit ?15:49.36 
sebras Robin_Watts: git reset HEAD~1; git add -p ...?15:49.58 
tor8 what sebras said :)15:50.08 
sebras Robin_Watts: though you'd loose your commit message.15:50.13 
paulgardiner git gui allows you to stage seperate lines and chunks15:50.28 
Robin_Watts Ah, ok.15:50.30 
tor8 paulgardiner: it does? how!?15:50.37 
Robin_Watts I could try to split the review into matrixes/rects/other opts then.15:50.58 
sebras paulgardiner: how about if the hunks have already been comitted..?15:51.00 
tor8 paulgardiner: oh, right click!15:51.28 
Robin_Watts sebras: git reset HEAD~1 then whatever paulgardiner meant :)15:51.31 
tor8 wish I'd known about that!15:51.32 
paulgardiner Select the file in the left pane andthen right click on a hunk in the display15:51.35 
sebras Robin_Watts: but then that's no different to git add -p...?15:52.09 
  from... different _from_!15:52.21 
tor8 sebras: nope. just a nice gui on top of the same functionality15:52.28 
  sebras: but I know you're allergic to both mice and rats ;)15:52.52 
sebras tor8: are we going to have this gui discussion again today? >;)15:52.53 
paulgardiner There's also some sort of thing like git <some command or other> --interactive15:52.55 
tor8 paulgardiner: git add -p15:53.11 
sebras paulgardiner: git rebase -i ?15:53.13 
  paulgardiner: I don't think that command let's you split a commit in two, but you can certainly reword a commit message or reorder commits.15:53.45 
paulgardiner One or other of those.15:54.00 
  I often use git-gui to split commits up15:54.36 
  stage everything, then unstage the debugging, i.e.15:55.07 
sebras paulgardiner: does it keep the commit message?15:55.29 
paulgardiner If you are using it to "Ammend last commit", yet15:56.09 
  yes even15:56.13 
tor8 I do exactly the same as paulgardiner. I'm a heavy git-gui addict...15:56.30 
  then I use the command line for everything else, but for staging changes I find git-gui to be perfect15:56.46 
paulgardiner tor8: gitk too? I like that for cherry picking, or resetting branches15:57.36 
tor8 paulgardiner: gitk to do code reviews :P15:57.49 
paulgardiner yes. That too15:58.02 
tor8 cherry picking and resetting branches I do from the command line15:58.07 
paulgardiner but then you need to know a name for the commit to cherry pick or the commit to reset to.15:58.46 
  also good for diffing between any two places in the tree15:59.22 
tor8 paulgardiner: copy-paste the sha1 from "git logg" or just robin/master~1 to get the second to last commit from a given branch16:00.05 
  I've even cherry picked commits from scroll back that I've wiped out via git reset --hard to get them back on the branch I want them16:00.47 
Robin_Watts Should fz_widget_bbox be fz_bound_widget ?16:01.25 
paulgardiner With gitk, if you use update and avoid reload, it'll leave unreffed commits visible in case you realise you did need them after all.16:02.10 
tor8 Robin_Watts: I think it should, but I'll leave the decision to you and paul16:02.20 
paulgardiner Robin_Watts: I think it should16:02.42 
henrys reading about the new blackberries - they are supposed to support android apps so I don't think we have much to worry about.16:03.44 
  good move on blackberries part16:04.07 
chrisl Brings into question why they didn't just use android......16:04.50 
Robin_Watts henrys: No.16:05.01 
  henrys: They support java only apps. They don't support apps that use JNI to get to native code.16:05.19 
  I spoke to someone about this at the show in SF.16:05.32 
tor8 Robin_Watts: so they rule out pretty much all the interesting apps?16:05.48 
henrys oh wow16:06.05 
chrisl I think it still brings into question continuing with their own OS16:06.17 
  henrys: are you happy for a release candidate to go out today?16:06.48 
Robin_Watts So they are an exact replica of Android in the same way that I'm an exact replica of Cameron Diaz.16:06.49 
henrys probably moot I think this is a last breath for blackberry - stock price from 150 - 5.00 or something I think they're done.16:07.39 
  I didn't get email that you had cherry picked the stuff discussed yesterday with till and hintak did I miss that?16:08.35 
Robin_Watts Given that their mainstay has always been corporate contracts, and supposedly companies are now wondering if taking a 2 year contract with RIM out is safe as they might go bust in that time, I think the end is in sight.16:08.46 
chrisl henrys: the two commmits tkamppeter_ are in the release branch - I guess he mailed me directly16:09.24 
  http://git.ghostscript.com/?p=ghostpdl.git;a=shortlog;h=refs/heads/gs90716:09.55 
henrys no what I mean is shouldn't everyone get email notifications for the 9.07 branch?16:10.23 
  but yes if those 2 commits are in I'm good16:10.37 
Robin_Watts henrys: "should" maybe, "currently do, the way the system is set up" no.16:11.21 
henrys okay16:11.32 
  for some reason I thought we did16:11.58 
Robin_Watts I believe we only get it for branches that we explicitly nominate.16:12.35 
  (ICBR of course)16:12.52 
henrys Islamic Center of Boca Raton ?16:14.40 
sebras tor8: while we're on the subject do you know of something similar to git reset -p (think git add -p but reset instead)...16:15.08 
chrisl We do get mails for commits to these branches (base on what I've just done!) - but maybe not cherry-picked ones?16:15.32 
sebras tor8: git add -p, adding the what to keep and then git reset --hard HEAD seem a bit annoying.16:15.41 
Robin_Watts Ahem. I meant ICBW.16:15.41 
  (I could be wrong)16:15.47 
  (I studied Maths, not English :) )16:16.15 
henrys I could be right works too!16:16.41 
chrisl Robin_Watts: so you can't do mental arithmetic either ;-)16:17.28 
Robin_Watts That resolves to a proposition proved earlier.16:19.00 
henrys chrisl:yeah I was pretty sure I'd seen the messages before.16:28.30 
chrisl henrys: yes, so it must be cherry-picked ones as they already exist as commits - maybe?16:29.09 
  Anyway, now I've sent the rc announcement out, I'm going to disappear off to squash training.......16:29.56 
henrys I guess maybe it has to be a new checksum - rebase no merge yes16:30.05 
chrisl I will check e-mails and IRC logs when I return - in case of any sh*t/fan interaction16:30.25 
henrys sounds good16:30.34 
Robin_Watts tor8: OK. Updated commits pushed. I've done the fz_transform_ swap over as a separate one.16:44.13 
  It's certainly more consistent this way. Can't imagine any real speedups with it though.16:44.37 
  tor8: So, in the new world, we pass an fz_rect to fz_run_display_list.16:52.35 
  But we pass a bbox to fz_new_draw_device_with_bbox16:53.22 
  The bbox is created by rounding the rect.16:53.30 
  Thus the bbox is slightly bigger than the rect, so we might choose not to render things that fall into the outside pixels of the bbox.16:54.11 
  We won't see it in testing, but it might give glitches when we do partial updates etc.16:54.32 
  Do you see what I mean?16:54.36 
mvrhel_laptop kens: ping16:57.33 
kens mvrhel_laptop : pong16:57.40 
  (but I'm leaving shortly)16:58.03 
mvrhel_laptop kens: I got your email about the buffer conversion. So if any sort of decoding or encoding is required you will need to do that outside the ICC stuff16:58.22 
  The ICC stuff is just set up to operate on buffers of data that are scaled in 8 or 16 bit range, planar or chunky16:58.48 
kens OK waht about indexed and so on16:58.56 
mvrhel_laptop again, you have to decode or lookup and/or encode your self. Index is easy though. as you just do the conversion on the table16:59.36 
kens mvrhel_laptop : not sure how that works, surely not conretize every sample ?17:00.13 
mvrhel_laptop kens: not sure how what works?17:00.24 
  index?17:00.28 
kens converting eg /Separation or /Indexed17:00.35 
Robin_Watts For indexed, you make a buffer containing each palette value, and convert it.17:00.52 
mvrhel_laptop exactly17:01.00 
  with separation, what is it that you want to convert from and to. Is this from Separation to CMYK or RGB?17:01.26 
kens No don't follow. I ahev a bunch of 8-bit values and I need n 8-bit values17:01.27 
  Say I'm going to a device space which is not the base space of the Indexed space.17:01.44 
Robin_Watts kens: so you have a palette, right?17:01.52 
mvrhel_laptop kens: oh I see.17:01.57 
kens Robin_Watts : yes and a whole load of 8-bit values17:02.08 
  whcih are indices into tha tpalette ineffect17:02.23 
Robin_Watts So you can map the palette values through to the final destination, right?17:02.27 
  Then that gives you a new palette.17:02.35 
mvrhel_laptop and you use that as your look up17:02.52 
Robin_Watts Your pile of 8 bit values now index the new palette to get you your final results.17:02.58 
kens Robin_Watts : yes, you are saying I need to do this one sample at a time ?17:03.00 
Robin_Watts No, you convert the palette at the start of the image, and then never need to call the CMS again.17:03.18 
kens Yes, OK for Indexed, what about /Separation or DeviceN17:03.41 
mvrhel_laptop So in this case, you will need to do these one by one, as you have to go through the alternate tint transform17:04.09 
kens Oh, ick, oh well17:04.23 
mvrhel_laptop kens: actually, there is code for this in imscale.c17:04.36 
  where I do this on a line buffer basis17:04.48 
kens ah OK i'll look there17:05.01 
mvrhel_laptop At least there is code to handle the wacky encoded cases17:05.40 
  and the Sep and DeviceN stuff is not going to be much different17:05.51 
  actually I meant gxiscale.c17:06.56 
  kens: gxicolor.c may have something also17:07.19 
  in particular image_render_color_DeviceN17:07.38 
  It pushes the DeviceN image colors through an ICC work flow17:08.10 
  It uses our favorite macro decode_sample and then pcs->type->remap_color to get the device value17:09.14 
  kens: that is probably what you will need to do17:09.32 
  not pretty but thats the way it goes 17:09.39 
kens OK no problem, I was assuming I was missing something ;-)17:10.06 
mvrhel_laptop no buffer mapping in that case17:10.08 
  kens: if I had the time, I would make a new CMM interface for us that handled these cases more cleanly17:10.57 
kens Not to worry, as long as I know ehre to go next17:11.11 
mvrhel_laptop ok17:11.15 
kens Now I have to be off, thanks Michael, I'll get back to this tomorrow17:14.40 
  Goodnight all17:14.45 
mvrhel_laptop ok kens bye17:14.47 
Robin_Watts tor8: ping17:17.43 
ray_laptop this (bug 693592) is too strange. First, it's one of those hideous Cairo jobs, then it only dies on 32-bit linux, then the problem exhibits in at least two different ways on the debugger :-(17:21.06 
Robin_Watts sebras: Did you find your chip design doc?18:03.38 
sebras Robin_Watts: forgot it yesterday. I have set an alarm so that I will not forget once I get home tonight.18:06.16 
Robin_Watts sebras: ah, thanks.18:08.18 
  Good and bad news on the timings front.18:16.24 
sebras ok..?18:16.36 
Robin_Watts Bad news first; I can't reproduce the results I was getting yesterday on windows.18:16.43 
  Yesterday I was consistently seeing both old and new binaries taking roughly 18 seconds to do 100 pages at 200dpi, 12 seconds to do 400 pages at 72dpi, and 40 seconds to do all the pdf reference at 72dpi.18:17.46 
  and I seemed to be getting 1% better or so in the new code, but the measurement error between runs was around about that same margin.18:18.37 
  Now today, with the latest stuff, both old and new builds are running roughly 10 times faster.18:19.06 
  so something has changed; probably me cocking up the testing somehow.18:19.41 
  So lets ignore those figures and go to the beagleboard...18:19.53 
  Good news: On the beagleboard, running the entire pdf reference manual to /dev/null at 72 dpi, without -d...18:20.43 
  old code = 47.22elapsed.18:20.53 
  new code = 44s elapsed.18:21.06 
sebras Robin_Watts: that sounds like a worthwhile improvement.18:26.58 
Robin_Watts yeah.18:27.19 
sebras Robin_Watts: but I'm curious.. why would -d matter. are there less matrix ops with -d?18:27.22 
Robin_Watts I just chose not to use -d.18:27.41 
  presumably there are fewer matrix ops if I use -d.18:27.59 
  as there are matrix ops involved on writing the list and playing it back.18:28.10 
sebras right.18:28.43 
Robin_Watts (when you play the list back you can give a new matrix to apply - so we can render the page to the list once, then play it back at different zooms)18:29.08 
  oh gawd. Now ubuntu wants to reboot. It's turning in windows.18:29.40 
sebras btw, tor8 mentioned that the improvements might not be so huge for the chip design in case the different substrate layers are not individual xobjects. I don't remember whether they are. but is a huge amount of patsh.18:29.50 
  Robin_Watts: probably updated the nvidia driver. I took that updated at my debian/testing box at work the other day...18:30.32 
  I _could_ have continued running, but anything video-related would just be a blank blue rectangle...18:31.00 
Robin_Watts This is a vmware image. I doubt it's driving my graphics card direct :)18:31.02 
sebras true, but what graphics card does ubuntu believe that vmware provides..?18:31.31 
Robin_Watts Aha, a tor8.18:31.45 
tor8 Robin_Watts: sorry, had to pop out for a bit18:31.58 
Robin_Watts no worries.18:32.06 
  various things in the logs for you.18:32.13 
tor8 so about the run_display_list rect/bbox what do you recommend?18:32.15 
Robin_Watts Either we need to make the run_display_list fuzz the rect a bit, or we need to have a rethink in the way we calculate the rect.18:32.48 
  (i.e. the rect needs to be calculated back from the bbox)18:32.56 
tor8 Robin_Watts: or make sure we fz_rect_from_bbox what we feed in18:36.32 
  it feels wrong to pass a bbox, since the device can be used for other things too18:36.48 
Robin_Watts tor8: Right. So a rethink in the way we calculate the rect.18:37.15 
tor8 Robin_Watts: in the draw device, the area rect gets set as the first scissor?18:38.01 
Robin_Watts I'm not sure what you're asking.18:38.53 
  The problem is that the rect is smaller than the bbox. hence the rect can exclude things that should be rendered into those pixels.18:39.21 
tor8 right. display list, not drawing device.18:39.49 
  let me play dense: why do we pass that area argument at all?18:40.52 
Robin_Watts Cos we can elide non visible items entirely.18:41.39 
tor8 and it's only for the display list, so that we can tell the display device what the draw device further down the pipeline won't need18:45.15 
Robin_Watts marcosw: Dunno if there is something up with casper?18:45.49 
  There are 2 large long running apache jobs...18:45.58 
marcosw Robin_Watts: I'll check...18:46.08 
Robin_Watts 19664 and 22021 and 24221. 3. 3 large long running apache jobs. soft cushions etc.18:48.13 
marcosw I've restarted apache. I think this is related to running bugzilla as a mod-perl job.18:49.21 
henrys Robin_Watts:see your mail I think you are probably best for this project but if somebody else on the mupdf team can do it quickly … fine by me.19:00.23 
  who talked me out of reflow?19:00.53 
Robin_Watts OK. I'll start work on that.19:02.12 
henrys some interesting testing ideas for us from sqlitehttp://www.sqlite.org/testing.html19:39.25 
tor8 Robin_Watts: henrys: so, reflow eh?23:05.19 
henrys seems to be the "missing" feature of interest23:07.18 
tor8 henrys: well, if it's a high priority as I assume then I'll get right on it23:07.51 
  we have something rudimentary already working, but giving that polish and putting images into it to make it demoable should be a few weeks I'd hope23:08.29 
  and from there on it's an everlasting project in improving heuristics23:08.43 
henrys I think Robin_Watts is already writing some up are you two in sync on this?23:09.01 
  s/some/something/23:09.15 
tor8 no, I haven't talked to robin about it yet23:09.51 
  henrys: html out is one thing, being able to render the reflowed results are another (which needs more work)23:11.12 
henrys by my read of the email that is not our responsibility23:13.23 
  aren't they just going to shove it into a browser?23:13.58 
tor8 henrys: I guess that's my question. would be good to know what exactly it is they expect.23:14.15 
henrys I really think that is it. Do you want to try to ping Raph ?23:16.51 
tor8 henrys: remind me tomorrow, too tired to write coherently now...23:19.24 
henrys okay see you then23:19.46 
tor8 nn23:19.59 
 Forward 1 day (to 2013/02/01)>>> 
ghostscript.com
Search: