| <<<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 yes | 08: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 dialog | 10:41.05 |
chrisl | Thanks - it's just for the "highlights" section in the release notes | 10: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 Acrobat | 10: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 | Magic | 11: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 case | 11: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.h | 11:12.16 |
| No sorry | 11:12.25 |
| You're right | 11: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 | ta | 11: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 rebased | 11:35.46 |
Robin_Watts | I have cherry picked it in. | 11:37.55 |
paulgardiner | May not build because of the fz_bbox changes | 11: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 changes | 11:39.35 |
Robin_Watts | on master? | 11:40.10 |
| no, on paul/robin. I see it. Thanks | 11:40.32 |
paulgardiner | "Make pdf_functions public as fz_functions" on paulg/robin | 11:40.33 |
kens | doesn't like the look of the latest support email for chrisl | 13: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 about | 14:24.54 |
kens | Hmm, I've meddled with it in the (dim and distanat) past | 14:25.33 |
chrisl | I assume that "BLK memory" is their memory manager, and I have no idea how our interaction with that works | 14:30.39 |
kens | Beats me boss | 14: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 felt | 14:31.37 |
chrisl | No test job attached either...... | 14:40.52 |
kens | Not ideal | 14: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 it | 14:56.40 |
kens | chrisl if/when you get a test job let me know if I cna help at all | 14: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 so | 15: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 suppose | 15:09.36 |
chrisl | yeh, I think we did something there for them | 15: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 slower | 15:09.53 |
| I must admit I wouldn't have bothered compressing small glyphs | 15:10.20 |
| especially if we are writing a display list | 15: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 pages | 15: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 = giraffe | 15: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 images | 15:13.17 |
chrisl | Page 1, show takes 27, page 2 27.5, page 3 27, page 4 27.4, ......... page 11 show takes 27.3 | 15:14.22 |
kens | Well that seems pretty consistent | 15:14.35 |
chrisl | So, the text ops aren't getting slower in the way that I'd expect if the cause was fragmented memory | 15:14.54 |
kens | Well he's suggsting that freeing the memory takes longer with each page, so the page time should increase | 15:15.28 |
| THough I guess it might take quite a few pages | 15:15.41 |
| Presumably you still don't have a test file, so we don't know what kind of fonts they are actually using | 15:16.02 |
chrisl | They're CIDType 2 - base on the calls to buildfont11 in the stats | 15: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[h | 15:16.58 |
chrisl | Not in this case - it's definitely spending the time in "show" - there are a few calls to ashow | 15: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 glyphs | 15:18.29 |
Robin_Watts | tor8: ping | 15:18.35 |
tor8 | Robin_Watts: hey | 15: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 one | 15:19.11 |
kens | Yes, that makes sense | 15:19.19 |
| They need to be 'encouraged' to always do that | 15: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 look | 15: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 that | 15: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 stuff | 15:22.33 |
| fz_widget_bbox shouldn't return a rect pointer (who owns it) but fill in a passed one | 15:23.10 |
kens | CDevProc, that's the thing I'm trying to remember | 15:23.11 |
chrisl | kens: Yes, CIDType 2 - but the point is still valid for other font types, just type1execchar, type2execchar and so on | 15:23.19 |
tor8 | fz_widget_bbox(&out, widget) | 15:23.19 |
| or pass by value | 15: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 functions | 15: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 CDevProc | 15: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 file | 15:24.44 |
tor8 | Robin_Watts: how does fz_pixmap_bbox return? that one doesn't have a fz_bbox internally | 15:24.46 |
chrisl | kens: But it still wouldn't appear in the "show" time | 15: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 setacachedevice | 15: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 matrices | 15:26.07 |
chrisl | kens: yes setcachedevice2, and yes it is instrumented | 15: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 ownership | 15: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) etc | 15: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 functions | 15:28.44 |
| ah, right. | 15:28.47 |
| well, separate step for that then | 15:28.51 |
| but the transform ones can be done in this one I think | 15: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) set | 15:32.43 |
| but it would let us easily see which are modified and expected to hold output, and which are just input | 15:33.05 |
| still, heavy use of const could do that too, but would mean looking at headers more | 15: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 now | 15: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 order | 15: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 doubles | 15:40.29 |
Robin_Watts | paulgardiner: Do we care about mudraw.c ? | 15:40.45 |
tor8 | we only care about the inner loops | 15: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 me | 15: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 me | 15: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 issue | 15:41.47 |
| but restrict doesn't hurt either | 15: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 a | 15:43.28 |
Robin_Watts | That's what restrict is for, AIUI. | 15:43.33 |
tor8 | which restrict does | 15:43.36 |
paulgardiner | Robin_Watts: oh yeah. You're right | 15: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 chunks | 15: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 display | 15: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 functionality | 15: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> --interactive | 15:52.55 |
tor8 | paulgardiner: git add -p | 15: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 up | 15: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", yet | 15:56.09 |
| yes even | 15: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 perfect | 15:56.46 |
paulgardiner | tor8: gitk too? I like that for cherry picking, or resetting branches | 15:57.36 |
tor8 | paulgardiner: gitk to do code reviews :P | 15:57.49 |
paulgardiner | yes. That too | 15:58.02 |
tor8 | cherry picking and resetting branches I do from the command line | 15: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 tree | 15: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 branch | 16: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 them | 16: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 paul | 16:02.20 |
paulgardiner | Robin_Watts: I think it should | 16: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 part | 16: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 wow | 16:06.05 |
chrisl | I think it still brings into question continuing with their own OS | 16: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 directly | 16:09.24 |
| http://git.ghostscript.com/?p=ghostpdl.git;a=shortlog;h=refs/heads/gs907 | 16: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 good | 16:10.37 |
Robin_Watts | henrys: "should" maybe, "currently do, the way the system is set up" no. | 16:11.21 |
henrys | okay | 16:11.32 |
| for some reason I thought we did | 16: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 yes | 16:30.05 |
chrisl | I will check e-mails and IRC logs when I return - in case of any sh*t/fan interaction | 16:30.25 |
henrys | sounds good | 16: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_bbox | 16: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: ping | 16:57.33 |
kens | mvrhel_laptop : pong | 16: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 stuff | 16: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 chunky | 16:58.48 |
kens | OK waht about indexed and so on | 16: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 table | 16: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 /Indexed | 17:00.35 |
Robin_Watts | For indexed, you make a buffer containing each palette value, and convert it. | 17:00.52 |
mvrhel_laptop | exactly | 17: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 values | 17: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 values | 17:02.08 |
| whcih are indices into tha tpalette ineffect | 17: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 up | 17: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 DeviceN | 17: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 transform | 17:04.09 |
kens | Oh, ick, oh well | 17:04.23 |
mvrhel_laptop | kens: actually, there is code for this in imscale.c | 17:04.36 |
| where I do this on a line buffer basis | 17:04.48 |
kens | ah OK i'll look there | 17:05.01 |
mvrhel_laptop | At least there is code to handle the wacky encoded cases | 17:05.40 |
| and the Sep and DeviceN stuff is not going to be much different | 17:05.51 |
| actually I meant gxiscale.c | 17:06.56 |
| kens: gxicolor.c may have something also | 17:07.19 |
| in particular image_render_color_DeviceN | 17:07.38 |
| It pushes the DeviceN image colors through an ICC work flow | 17:08.10 |
| It uses our favorite macro decode_sample and then pcs->type->remap_color to get the device value | 17:09.14 |
| kens: that is probably what you will need to do | 17: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 case | 17:10.08 |
| kens: if I had the time, I would make a new CMM interface for us that handled these cases more cleanly | 17:10.57 |
kens | Not to worry, as long as I know ehre to go next | 17:11.11 |
mvrhel_laptop | ok | 17:11.15 |
kens | Now I have to be off, thanks Michael, I'll get back to this tomorrow | 17:14.40 |
| Goodnight all | 17:14.45 |
mvrhel_laptop | ok kens bye | 17:14.47 |
Robin_Watts | tor8: ping | 17: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 bit | 18: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 in | 18:36.32 |
| it feels wrong to pass a bbox, since the device can be used for other things too | 18: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 need | 18: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.html | 19:39.25 |
tor8 | Robin_Watts: henrys: so, reflow eh? | 23:05.19 |
henrys | seems to be the "missing" feature of interest | 23:07.18 |
tor8 | henrys: well, if it's a high priority as I assume then I'll get right on it | 23: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 hope | 23:08.29 |
| and from there on it's an everlasting project in improving heuristics | 23: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 yet | 23: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 responsibility | 23: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 then | 23:19.46 |
tor8 | nn | 23:19.59 |
| Forward 1 day (to 2013/02/01)>>> | |