| | <<<Back 1 day (to 2012/02/05) | 2012/02/06 |
| sebras | tor8 Robin_Watts: I have a suggestion... | 00:20.51 |
| | fz_rect rect = fz_bound_page(doc, page); | 00:20.52 |
| | rect = fz_transform_rect(transform, rect); | 00:20.52 |
| | fz_bbox bbox = fz_round_rect(rect); | 00:20.52 |
| | this is cumbersome. when using mupdf as a client I don't really care about the subtle differences between rect and bbox. | 00:21.28 |
| | bound the page, transform it, and give me a variable suitable for giving to fz_new_pixmap_with_rect(). | 00:22.02 |
| | I know there's a difference between rect and bbox, but I'm not so sure a first time user would understand it. | 00:23.50 |
| | tor8: would it make sense to have a fz_open_document() that takes a filename and does the extension-guessing? | 00:50.52 |
| | or perhaps a fz_open_document_stream() that takes a stream and guesses, if it's another type of document it catches the exception and tries the next type. | 00:51.46 |
| | tor8 Robin_Watts: I tidied the usage example, and started a new overview.txt to which I moved the error handling text. | 01:36.23 |
| | I also wrote a brief description of context, and I intend to write some more about NULL-handling and reference counting. | 01:37.24 |
| ray_laptop | Robin_Watts: I'll check with you in the AM (For me) about cust 532 -- I think there is a REALLY messed up aspect to image processing. With PWTTQ1CC, even though there are only 157 calls to gx_begin_image1 that call image_init_clues, there are 206K+ calls to image_init_clues. | 06:26.18 |
| | Robin_Watts: Since the color spaces are "Indexed" we are wiping out the Indexed color lookup cache (and calling the 'remap' function MANY more times than we should, not to mention the overhead of continually clearing out the 'cliues' cache. | 06:27.45 |
| | Robin_Watts: for single component (Indexed or Gray) images, this is a waste. For color images, image_init_clues is a waste since the cache is too small to be useful. | 06:28.59 |
| | Robin_Watts: I think one call to 'image_init_clues' per gx_begin_image1 is adequate, and the we should the the cache accumulate until the image is done (mononchrome or Indexed color space). | 06:32.40 |
| | s/the the/let the/ | 06:33.04 |
| dxp2532 | can anybody kindly provide a contact where security issues can be submitted? | 09:29.28 |
| kens | http://bugs.ghostscript.com | 09:29.40 |
| dxp2532 | I thought there may be a separate email box, but thank you for clarifying | 09:41.32 |
| kens | There is only one place for free users to report bugs. | 09:41.46 |
| | But please do raise a report for any issues. | 09:42.14 |
| malc_ | Robin_Watts: hi, seen my message regarding xps links? | 10:06.48 |
| Robin_Watts | malc_: Morning. | 10:53.20 |
| | Tor reworked links a bit at the end of last week. | 10:53.32 |
| | What's the latest? | 10:53.37 |
| malc_ | Robin_Watts: i can "reliably" trigger a segdfaults | 11:13.18 |
| | s;a;; | 11:13.26 |
| Robin_Watts | malc_: How. | 11:20.49 |
| | Are you testing with up to date code ? | 11:21.02 |
| malc_ | yep | 11:21.11 |
| | gdb --args build/debug/mupdf ~/tmp/xps/ECMA-388.xps | 11:21.12 |
| | moving around, making sure page with links is loaded | 11:21.23 |
| | then unloaded | 11:21.26 |
| | then moving a mouse | 11:21.29 |
| | yields | 11:21.30 |
| | Program received signal SIGSEGV, Segmentation fault. | 11:21.37 |
| | 0x1000b2e8 in pdfapp_onmouse (app=0x10623014, x=464, y=881, btn=0, modifiers=0, state=0) at apps/pdfapp.c:925 | 11:21.37 |
| | 925 if (p.x >= link->rect.x0 && p.x <= link->rect.x1) | 11:21.40 |
| | (gdb) bt | 11:21.43 |
| | #0 0x1000b2e8 in pdfapp_onmouse (app=0x10623014, x=464, y=881, btn=0, modifiers=0, state=0) at apps/pdfapp.c:925 | 11:21.45 |
| | #1 0x10004898 in onmouse (x=464, y=881, btn=0, modifiers=0, state=0) at apps/x11_main.c:572 | 11:21.48 |
| | #2 0x10005040 in main (argc=2, argv=0xbffffa04) at apps/x11_main.c:728 | 11:21.51 |
| | (gdb) | 11:21.54 |
| Robin_Watts | OK. I'll talk to tor8 about it later when he arrives. | 11:22.06 |
| malc_ | you actually don't need the mouse part, but it was easier to trigger | 11:22.07 |
| Robin_Watts | At the moment I'm buried in gs. | 11:22.16 |
| malc_ | i can feel your pain | 11:22.35 |
| | tor8: http://ghostscript.com/irclogs/current.html | 11:57.37 |
| tor8 | sebras: re fz_open_document ... that'll need a central registry of supported file types so needs a bit more work | 11:58.56 |
| | malc_: segfault, hmm | 12:00.11 |
| malc_ | tor8: a few days earleier i pointed Robin to some workaround i had (which does not really workaround anything but might point into a good direction), let me find it | 12:01.45 |
| | s;earleier;earlier | 12:01.54 |
| | http://pastebin.ca/raw/2109511 | 12:02.32 |
| | tor8: also, i was wonder, if it would be possible to add an API to query page dimensions without actually loading the page (cbz is a prime example where i need it) | 12:04.12 |
| | (i was wonder)ing | 12:04.21 |
| tor8 | malc_: sadly, that's not really possible | 12:04.35 |
| malc_ | i need to get some sleep, maybe that will improve my spelling.. | 12:04.35 |
| tor8 | for pdf we could, but not xps and not cbz | 12:04.59 |
| malc_ | tor8: i need to buy a faster machine then.. or maybe not | 12:05.01 |
| | tor8: for pdf i do it myself :) | 12:05.08 |
| tor8 | both xps and cbz need to decompress bits of the zip file and parse the content to know the page size | 12:05.32 |
| malc_ | tor8: sure, but in cbz case one might stop short of actually decompressing the png/jpg | 12:05.57 |
| | and just look for wxh | 12:06.07 |
| tor8 | yeah, but that means a fair bit of extra work writing partial decompressors | 12:07.16 |
| | are you loading page dimensions when you open the document? | 12:07.46 |
| Robin_Watts | malc_: We plan to change the way images are handled after v1.0; | 12:08.01 |
| malc_ | tor8: yep.. continous view always | 12:08.05 |
| Robin_Watts | in particular we will be loading the image data compressed, but not doing the decompression until it's required. | 12:08.23 |
| tor8 | may I suggest making a "wild guess" at first, and then adjusting it when you actually load the page? | 12:08.46 |
| Robin_Watts | Whether or not that leads to partial decompressors remains to be seen. | 12:08.51 |
| malc_ | tor8: btw. easier way to trigger a fault in ECMA..xps: 3g 100g 3g | 12:09.13 |
| | tor8: hah.. i did just that | 12:09.24 |
| | tor8: in cbz case i guess it's 900x900 | 12:09.32 |
| tor8 | malc_: can reproduce, will see if I can spot it | 12:09.38 |
| malc_ | and do load all of them only in trim margins | 12:09.45 |
| sebras | tor8: yes, a central extension registry would be required, or just a best effort guess. | 12:13.18 |
| tor8 | malc_: your patch is correct, but not the patch I want | 12:14.38 |
| | sebras: a best effort guess means fitz/doc_document.c knowing about (and linking to) mupdf, muxps and mucbz | 12:15.02 |
| | which may or may not be an issue, depending on how allergic you are to spaghetti dependencies | 12:15.26 |
| | Robin_Watts: morning. I have a question about the fz_storable free callback. | 12:15.47 |
| Robin_Watts | morning | 12:15.59 |
| tor8 | when we store pdf_foobar type objects, I ideally want to pass the pdf_document as the context to the free function | 12:16.12 |
| | so, another argument (void*) as the context to pass for freeing or do you have any other ideas? | 12:16.40 |
| Robin_Watts | Hmm. | 12:17.05 |
| | At the moment documents are tied to a context once they are created, right? | 12:17.16 |
| tor8 | subclassing by embedding the fz_context struct at the top, well, we then get into multiple inheritance with fz_document (but that's easy enough to change) | 12:17.49 |
| | yes | 12:17.59 |
| Robin_Watts | So putting them into the store with a context, rather than a document doesn't seem like a problem to me. | 12:18.15 |
| | If they need a document pointer, can we not store it in the object itself ? | 12:18.41 |
| tor8 | pattern, xobject, fontdesc and cmap are the current pdf storables | 12:19.52 |
| | ah, and functions too | 12:20.45 |
| Robin_Watts | All of which happily take a context *. | 12:21.33 |
| | Are you saying that's wrong? | 12:21.40 |
| tor8 | it's a bit confusing and annoying, some pdf stuff takes fz_contexts and some take pdf_document as the context parameter | 12:21.56 |
| | I'm trying to make it consistent | 12:22.11 |
| | one thought was that all pdf functions take a pdf_document as the context, but I'm not sure that's the best way | 12:22.47 |
| Robin_Watts | Let me stare at the code for a bit. | 12:22.54 |
| tor8 | stare at the header file prototypes in mupdf.h | 12:23.04 |
| Robin_Watts | fz_drop_storable *must* take an fz_context. | 12:23.42 |
| tor8 | I added in a fz_context to almost all fitz functions on friday; in the name of consistency | 12:23.48 |
| | yeah, it does fz_lock/unlock | 12:23.54 |
| malc_ | tor8: oh btw.. how should one, in your opinion, go about cbz which contains a gif disuised as a x.png, try/catch? | 12:25.23 |
| Robin_Watts | tor8: So you'd like to add a new void * to fz_store_item ? | 12:26.25 |
| tor8 | Robin_Watts: I can live with a pdf_document pointer stowed away in the objects instead | 12:26.50 |
| | I'll stare a bit harder at the mupdf header file and see if I can find some other system of saying "these take fz_context, but these here take pdf_document" without sounding crazy | 12:27.25 |
| Robin_Watts | Well, that 'bloats' every such object by 4 bytes (8 on 64bit) | 12:27.32 |
| | tor8: They way I look at it is that the store is something offered by the fitz layer. | 12:27.53 |
| | As such anything that gets put into the store should work 'at the fitz level'. | 12:28.09 |
| tor8 | Robin_Watts: by object, I mean in the pdf_pattern, not the fz_storable | 12:28.15 |
| Robin_Watts | Yes, I realise that. | 12:28.27 |
| | So effectively, for every object we want to put in the store, we export a 'fitz level interface' for that. | 12:28.56 |
| tor8 | yeah. so we could organize things and say "these structs are fitz-level objects, but live in the pdf namespace" | 12:28.58 |
| Robin_Watts | And it doesn't seem unreasonable to me that those things work with fz_context etc. | 12:29.19 |
| tor8 | and the various graphic resources and helper objects would be at that level (cmaps, font descriptors, patterns, etc...) | 12:30.00 |
| Robin_Watts | I had thought(/hoped/prayed/assumed) that those fitz level interfaces were not exposed to the user. | 12:30.02 |
| tor8 | well, the ones mentioned are all hidden by the interpreter | 12:30.42 |
| Robin_Watts | (i.e. when we break mupdf.h into public/internal levels, the fitz level ones are all internal ones. | 12:30.52 |
| tor8 | yeah | 12:31.03 |
| | let's go with that approach | 12:35.13 |
| sebras | tor8: or mupdf, muxps, mucbz calls the central registry and tells it what extensions it knows about. | 13:28.57 |
| | tor8: so if you link with either the centry registry queried by fz_open_document() will know how to handle the registered ones... | 13:29.34 |
| | tor8: yey! object orientation and registries and queries! :) | 13:29.55 |
| tor8 | indeed :( | 13:30.49 |
| Robin_Watts | It's almost like it's a grown up piece of software. :) | 13:39.28 |
| sebras | Robin_watts: yeah, and with age comes worse eyesight -- which explains why the code is so hard to read nowadays... ;) | 13:41.39 |
| Robin_Watts | thanks henrys for the informative commit message on 01c26a7. | 15:30.45 |
| kens | ping henrys | 15:48.48 |
| Robin_Watts | He's going to be late today, if memory serves. | 15:50.34 |
| kens | Oh yes. | 15:50.39 |
| Robin_Watts | kens: Do you understand Color Clues ? | 15:50.40 |
| kens | I'll send him an email then | 15:50.45 |
| | Sorry, RObin, not at all | 15:50.54 |
| Robin_Watts | Fair enough. | 15:51.06 |
| | Ray pointed out something earlier, and I've made a change in the light of it, and it seems to test out OK on the cluster, but I'd really like someone else who understands clues to look at it and agree with me. | 15:51.52 |
| kens | I can look at it, but I won't understand it probably ;-) | 15:52.09 |
| Robin_Watts | Let me stare at it for a bit and see if I can come up with a coherent explaination of what i think is going on. | 15:52.50 |
| kens | OK, willing to be cardboard programmer :-) | 15:53.05 |
| Robin_Watts | ACtually, I may have a simple explanation. | 15:53.59 |
| | Look at image_render_mono, if you would. | 15:54.07 |
| kens | One second, which file ? | 15:54.16 |
| Robin_Watts | gximono.c | 15:54.24 |
| | Aha! A Ray. | 15:54.36 |
| | ray_laptop: Based on what you said earlier, I've done some experiments. | 15:54.48 |
| kens | OK I have the code | 15:55.01 |
| Robin_Watts | and I was just about to run them past kens to see if he could spot any obvious flaws in my logic. | 15:55.18 |
| | So image_render_mono in gximono.c | 15:55.32 |
| | Fairly close to the top of that function, there is a call to image_init_clues | 15:56.02 |
| kens | yes, under DEVICEN comment | 15:56.19 |
| Robin_Watts | It's protected by if (pis != 0 || !gx_check....) | 15:56.27 |
| kens | yes | 15:56.32 |
| Robin_Watts | Which always works out to be true. | 15:56.38 |
| kens | Hmm, null imager state, or tile cache is not current. | 15:57.04 |
| | Presumably if tile cache is current we don't need (or want) to init the clues. | 15:57.23 |
| | Not sure what a null imager state represents though | 15:57.47 |
| Robin_Watts | Except, since 2002, that function has always returned false. | 15:57.47 |
| kens | Ah. | 15:57.54 |
| | Sounds like a performance hole | 15:58.04 |
| Robin_Watts | So essentially it's if (true) | 15:58.06 |
| kens | The comment does say the routine is bogus | 15:58.15 |
| Robin_Watts | indeed. | 15:58.19 |
| | So, on every call to image_render_mono we blow away our 'cache' of halftone colors. | 15:58.42 |
| kens | That sounds like a very bad thing indeed | 15:58.54 |
| Robin_Watts | Why not just blow away the cache once per image? | 15:59.01 |
| | The colours are never going to be invalidated between scanlines, right? | 15:59.16 |
| kens | Hmmm. | 15:59.28 |
| | Not from the colour space certainly | 15:59.38 |
| Robin_Watts | I clusterpushed a test earlier where I removed that line entirely (so we never call image_init_clues from this function) and the cluster showed no differences. | 16:00.38 |
| chrisl | Do we render DeviceN *output* as N mono-planes? | 16:01.05 |
| kens | Well that sounds promising | 16:01.06 |
| | I don't think we have a composite DeviceN output. | 16:01.28 |
| | SO I imagine its planes | 16:01.39 |
| | Ah, we can't have more than 8 bpp, I see. | 16:02.34 |
| | Presumably we downgrade 12 bpp images, or upgrade them to 16 or something | 16:02.55 |
| | So I can't see any reason why the clues would ever change once they are assigned | 16:03.17 |
| | We only ever need 256 of them | 16:03.25 |
| Robin_Watts | Well, the fix I have here, is to call image_init_clues() from gs_image_class_3_mono (the routine that returns &image_render_mono). | 16:04.20 |
| | so it's called once per image rather than once per line. | 16:04.37 |
| kens | Yes that looks reasonable to me. | 16:04.46 |
| | Once per line doesn't seem to make any sense | 16:04.59 |
| chrisl | Where is gs_image_class_3_mono called from? | 16:05.01 |
| Robin_Watts | That's one of the "I have a luverlly image, who'll handle my luverlly image?" functions. | 16:05.33 |
| chrisl | So it's "top" of the graphics libs levels? | 16:06.06 |
| Robin_Watts | (trying to find out where it's called from now) | 16:07.38 |
| kens | That's a bit hard to tell. | 16:07.49 |
| Robin_Watts | but yes, I believe it's when the gs lib is first told to handle an image, that it calls around all the different 'handlers' to find one that copes with this particular format. | 16:08.24 |
| kens | It seems to be generated at build time. | 16:08.25 |
| | 12 bit images go through image_calass_2_fracs | 16:08.52 |
| | class 4 handles colour | 16:09.13 |
| chrisl | My only thought was if image_render_mono could end up being called once per plane per scanline, I could why the clues might need to change for each invocation - that's all...... | 16:09.20 |
| kens | I think that would involve going through a colour image routine | 16:09.46 |
| chrisl | Even if it were a single color image? | 16:10.22 |
| kens | class 0 seems to be interpolated and class 1 is 'fast' monochrome, can't find class2 | 16:10.33 |
| Robin_Watts | one class (whichever handles image/mask ones) can call 2 sub image class providers. Might be 3. | 16:10.42 |
| kens | chrisl if its a single colour image, how can it have more than one plane ? | 16:10.55 |
| Robin_Watts | gx_image_enum_begin - found it. | 16:11.20 |
| kens | But I confess to not knowing anything about this stuff | 16:11.24 |
| chrisl | kens: I was thinking planes in the output device | 16:11.25 |
| Robin_Watts | But... worryingly, the current version of gs doesn't hit this route through the code :( | 16:11.54 |
| kens | chrisl then presumably we don't need a cahce because it will not mark the plabe. | 16:12.05 |
| Robin_Watts | So my cluster tests probably count for little :( | 16:12.10 |
| kens | Ah ;-) | 16:12.15 |
| | I be the ICC code has stopped that route. | 16:12.40 |
| chrisl | But (as I keep trying to type...) this appears to be at a higher level than such knowledge of the device would be known | 16:12.45 |
| kens | Its certainly high level yes. | 16:13.05 |
| chrisl | Or the switch to threshold based image halftoning? | 16:13.17 |
| kens | Maybe, though I thought this was higher level than that, but I don't know | 16:13.43 |
| chrisl | Just below is routine called: image_render_mono_ht | 16:14.41 |
| Robin_Watts | Oh, wait.... I am getting called through here in the new code - just I was hitting a different breakpoint first. | 16:15.11 |
| kens | You probably do need to check this with Ray, but it looks OK to me. | 16:16.32 |
| chrisl | Robin_Watts: are the clues not being setup already in image_init_colors? | 16:19.38 |
| Robin_Watts | chrisl: Quite possibly. | 16:19.54 |
| | I can't guarantee (through my own ignorance) that that will be the case in all possible calling paths. | 16:20.09 |
| chrisl | The only reason I mention it is because it says: "/* Clues are only used with image_mono_render */" | 16:20.54 |
| | Ignoring the typo, it is suggestive..... | 16:21.40 |
| Robin_Watts | Yes. | 16:21.59 |
| | kens: Can you look at my latest bmpcmp please? | 16:23.22 |
| | My last test threw up 4 differences; all in pdfwritten stuff. | 16:23.46 |
| kens | One second | 16:23.53 |
| Robin_Watts | Do those look like "known" problems, or should I be worried? | 16:24.00 |
| kens | Looks like a problem to me. | 16:24.34 |
| Robin_Watts | ok. | 16:24.39 |
| kens | I recognise the file and I'm middling sure that it sued to be OK | 16:25.07 |
| | Especially the skull | 16:25.37 |
| chrisl | Robin_Watts: you may want to check this with mvrhel: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=c41740 | 16:25.42 |
| kens | 12-07b.ps is not one to worry about | 16:26.38 |
| Robin_Watts | chrisl: How did I miss that? git blame took me right past that back to 2002! | 16:29.15 |
| chrisl | Probably because it was putting code back that had been removed? | 16:29.54 |
| Robin_Watts | maybe. | 16:31.06 |
| chrisl | Robin_Watts: Did you git blame on the comment, rather than the code? | 16:33.42 |
| Robin_Watts | the code. | 16:34.53 |
| | Using the web portal. | 16:34.58 |
| chrisl | Hmm, weird.... | 16:35.20 |
| mvrhel_laptop | good morning | 16:52.46 |
| kens | hi mvrhel_laptop | 16:53.00 |
| Robin_Watts | Morning. | 16:53.19 |
| | ray_laptop: Ping? | 17:10.07 |
| mvrhel_laptop | looks like you guys are keeping busy with cust 532 | 17:13.33 |
| | Do they have an aim point or does it seem a bit open ended | 17:14.16 |
| | Or are they comparing against some target? | 17:14.31 |
| Robin_Watts | Their aim point is, as far as I can tell, "have the 6th gen be as fast as the 5th gen". | 17:14.40 |
| mvrhel_laptop | and the 5th gen did not have ghostscript? | 17:14.57 |
| Robin_Watts | I think there are just a few files where we are slower. | 17:15.00 |
| | AIUI, no. | 17:15.03 |
| | It's quite possible that if they were using 9.0x they would be as fast. | 17:15.21 |
| mvrhel_laptop | ok. anything particular about these files? | 17:15.56 |
| | patterns transparency CIE color? | 17:16.06 |
| Robin_Watts | bitmaps. | 17:16.19 |
| | halftoned bitmaps | 17:16.29 |
| mvrhel_laptop | ok | 17:16.54 |
| Robin_Watts | Their worst file has lots of calls to plot a 1xH bitmap in landscape mode. | 17:17.26 |
| mvrhel_laptop | ugh | 17:17.37 |
| ray_laptop | Robin_Watts: Sorry for the head fake earlier -- I fired up to load emails and IRC connected. | 17:17.40 |
| | Robin_Watts: I'm here now and have reviewed the logs | 17:17.50 |
| Robin_Watts | So because we deal with that in scanlines, results in H calls to the underlying renderer. | 17:17.59 |
| | ray_laptop: Ah, ok. | 17:18.05 |
| | I *think* it's my clipping optimisation that's causing the 4 differences. | 17:18.18 |
| | I'm testing the image_init_clues move now. | 17:18.31 |
| ray_laptop | Robin_Watts: right -- I also noticed the H calls to image_render_* | 17:18.33 |
| mvrhel_laptop | Robin_Watts: gotcha. | 17:18.37 |
| Robin_Watts | I did wonder about spotting the 1xH case; if w == 1 and posture == image_landscape then use a special unpacker to go from landscape to portrait. | 17:19.32 |
| ray_laptop | Robin_Watts: you removed the image_init_clues from image_render_mono, right ? (just do it once per image_enum_init) ? | 17:19.41 |
| mvrhel_laptop | yes. | 17:19.43 |
| Robin_Watts | ray_laptop: Yes. | 17:19.52 |
| | but 'faking an enum' scares me. | 17:20.23 |
| ray_laptop | I couldn't tell from the logs -- did you add in a call to image_init_clues anywhere else ? | 17:20.32 |
| Robin_Watts | ray_laptop: Yes. I put a call to image_init_clues in the same file, just before "return &image_render_mono;" | 17:21.13 |
| | in gs_image_class_3_mono | 17:21.33 |
| | But even that may be overkill. | 17:21.49 |
| | ray_laptop: The clipping change I sent them the other day; it shows up wierdnesses with their profile. | 17:22.28 |
| | the clipping functions don't show up in the profile, even though they must be there. | 17:22.53 |
| | And (by their measurements) it saved 6% on one file, and 8% on another. | 17:23.18 |
| ray_laptop | Robin_Watts: right, on the WW files, but on the PW files, the image code swamps clipping (if any is used) | 17:25.07 |
| Robin_Watts | ray_laptop: Right. The thing is, for the files I was looking at, the images *are* clipped. | 17:25.37 |
| ray_laptop | Robin_Watts: which files are those ? | 17:25.54 |
| Robin_Watts | The WW ones at least. The PW ones too. | 17:26.08 |
| | Sorry. | 17:26.14 |
| | The PW ones too, *maybe*. | 17:26.19 |
| | Everything was breaking down to a plot call, that at some stage had to go through the clip device. | 17:26.55 |
| ray_laptop | Robin_Watts: well, the WW files show the performance improvement so that makes sense, but their profile of the PW files shows that the image_render_ functions are dominant and there may not be much clipping | 17:27.20 |
| Robin_Watts | and the clip device was ending up very low in the stack (i.e. at the pixels level rather than the scanlines level) | 17:27.23 |
| | ray_laptop: Right, but the same thing could be happening in the PW files, and we wouldn't know from their profiles, cos their profiles don't show the clipping functions :) | 17:28.02 |
| ray_laptop | Robin_Watts: "low in the stack" ? | 17:28.11 |
| Robin_Watts | 'low in the device chain' (i.e. just above the actual memory device) | 17:28.33 |
| | so rather than clipping the mask, we were clipping the runs of pixels generated by halftone filling that mask. | 17:29.16 |
| | ray_laptop: Right. I just cluster tested the image clues stuff and it came up clean. Let me push that. | 17:30.54 |
| ray_laptop | Robin_Watts: OK, I understand. You are applying the clipping on the larger objects, thus less checks | 17:32.05 |
| Robin_Watts | ray_laptop: Right. | 17:32.12 |
| | I couldn't measure a difference on my version of gs, but it seemed to help for them. | 17:32.25 |
| ray_laptop | Robin_Watts: but I thought we got rid of clues in 9.0x | 17:32.46 |
| Robin_Watts | Unfortunately, it looks like it's causing 4 diffs in the cluster today (don't know why I didn't see that before). | 17:32.51 |
| | ray_laptop: We use clues for halftoned mono rendering, AIUI. | 17:33.13 |
| | mvrhel_laptop added the code back in. | 17:33.23 |
| | http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=c41740 <- chrisl pointed this out earlier. | 17:33.56 |
| ray_laptop | Robin_Watts: I'm testing performance of the image_init_clues change on the simulator so I'll have some numbers. I am set up for 'do_no_output = 1' so I get affected by writing to disk | 17:34.22 |
| Robin_Watts | I'm going to try to understand what my clipping change breaks. | 17:35.00 |
| ray_laptop | Robin_Watts: OK, on the simulator I see about a 10% improvement (3 different runs of PWTTQ1CC old and new) | 17:46.23 |
| Robin_Watts | Disappointing :( | 17:46.51 |
| | (I mean, it's more than my change managed, but I'd hoped for more!) | 17:47.19 |
| ray_laptop | Robin_Watts: oops -- I hadn't switched over to a non-DEBUG simulator build since switching to _030 | 17:50.14 |
| Robin_Watts | non DEBUG builds won't work for me. | 17:50.36 |
| ray_laptop | Robin_Watts: see my email to Eric on 1/16 "Re: Building a non-debug Ghostscript for profiling on the simulator" | 17:51.01 |
| Robin_Watts | Hmm. The clipping path appears to be lying. | 18:01.33 |
| | Either this is a bug in gs, or a bug in my understanding of gs. | 18:01.45 |
| ray_laptop | Robin_Watts: Sorry I was away -- my laptop crashed right after my last IRC statement -- it took until now to get up and cleaned up (went down _really_ dirty since I had a lot crunching) | 18:25.36 |
| ray_laptop | hates when that happens :-( | 18:26.46 |
| Robin_Watts | urgh. | 18:28.10 |
| | ray_laptop: Well, I don't propose to worry about building release builds unless I have to. | 18:28.43 |
| | That's... annoying. | 18:29.29 |
| | My understanding of ghostscript clippaths was that the innerbox was the maximum bbox, s.t. any point within it, was definitely included in the clipped region. | 18:30.10 |
| ray_laptop | Robin_Watts: that is my understanding as well, but I haven't dug into clipping much. | 18:35.08 |
| Robin_Watts | This is very strange. | 18:35.26 |
| | I have a path that lies entirely within the clipping path. | 18:35.43 |
| | So I don't bother creating the clipping device. | 18:35.51 |
| | and NOTHING appears on screen. | 18:35.57 |
| | So NOT creating the clipping device means nothing is drawn. | 18:36.08 |
| ray_laptop | Robin_Watts: that doesn't make sense to me | 18:36.31 |
| Robin_Watts | i.e. the clipping device INCREASES the amount that is drawn. | 18:36.37 |
| | Me either! | 18:36.39 |
| ray_laptop | Robin_Watts: OK, with a non-DEBUG gs build, we still save 1 second on the PWTT file, but it amounts to 14% | 19:09.12 |
| | Robin_Watts: note, I do _not_ have your clipping patch in my build. | 19:09.43 |
| | Robin_Watts: I hope you don't mind if I send the image_init_clues to Eric (I'll make sure to mention that you and I collaborated on it) | 19:10.53 |
| kens | 14% sounds useful | 19:11.13 |
| ray_laptop | kens: yep. | 19:11.20 |
| Robin_Watts | ray_laptop: Sure. I was expecting you to send it - you found it after all. | 19:12.05 |
| ray_laptop | I only see about 8% improvement on EXTT71DC (startup time is a bigger percentage since it only takes 2.5 seconds instead of 7.5) | 19:22.48 |
| mvrhel_laptop | bbiaw | 19:32.09 |
| ray_laptop | Robin_Watts: next I'm going to look at pulling in the color cache I used with WTS into image_render_color to see how much it'll help. On EXTT71DC, even though there are (only) 7,989 image_render_color calls, we call remap_concrete_color 99,702 times. Might help :-/ | 19:34.16 |
| | on the PWTT file, there are 404,096 calls to remap_concrete_color (much more significant) | 19:47.18 |
| kens | seems liek a lot | 19:50.07 |
| Robin_Watts | I think I've fixed the clipping problem. | 19:54.52 |
| | It's actually an unrelated thing; we were calling a fill with w=0, h=0. | 19:55.32 |
| | and the clipping device copes with that, the underlying device throws an error, and we never flush the image. | 19:55.57 |
| kens | err, which clipping problem is this ? | 19:56.55 |
| Robin_Watts | I came up with a clipping optimisation, but it caused 4 pdfwrite/pswrite files to fail. the ones in the bmpcmp earlier. | 19:59.41 |
| kens | 2 of those weren't pdfwrite I think | 19:59.57 |
| Robin_Watts | 2 pdfwrite, 2 pswrite,I believe. | 20:00.12 |
| kens | I thought 2 were regular rendering, I could be wrong | 20:00.26 |
| Robin_Watts | I believe not. But anyway, we'll see in an hour or so. | 20:00.46 |
| ray_laptop | Robin_Watts: usually the 'fit_fill' macro returns 0 if the clipped size is empty | 20:00.54 |
| | Robin_Watts: I've seen some devices that miss that | 20:01.17 |
| | Robin_Watts: I sent the update to Eric -- let's hope for better performance diff on the target than on the simulator :-) | 20:02.19 |
| | Robin_Watts: are you going to send them an updated patch for the clipping ? | 20:03.04 |
| Robin_Watts | ray_laptop (for the logs): Yes, when the tests complete. | 20:09.55 |
| ray_laptop | Robin_Watts: i saw your comment. Thanks. | 20:34.07 |
| | I'm running errands (lunch, other), so I'll check logs whenever I'm connected.... | 20:34.49 |
| | Forward 1 day (to 2012/02/07)>>> | |
IRC Logs