| | <<<Back 1 day (to 2011/10/02) | 2011/10/03 |
| sebras | good night! | 00:56.43 |
| tkamppeter | Got a report of a failing print job in Oneiric: https://bugs.launchpad.net/gs-gpl/+bug/864509 | 11:43.34 |
| | It is not a segfault, but most probably a PDF interpreter failure. | 11:44.13 |
| kens | THat's a clist problem. | 11:46.20 |
| | I believe the PDF file is fully interpreted at this point, and the display list is being run multiple times to render the full output. | 11:46.59 |
| | Unfortunately I don't know much about the clist, so can't really tell you what the error means. | 11:47.25 |
| | Running at lower resolution should stop the clist activating and work OK. | 11:47.54 |
| tkamppeter | kens, seems for me too, especially one can eliminate the problem by not specifyin resolution, which means on 100 dpi. With a such small bitmap it seems to switch to full-page mode. | 11:47.56 |
| kens | Yes, I expect the problem is something to do with the funny colour space not being properly stored in the clist. | 11:48.26 |
| | Its 'probably' one for Michael to look at | 11:48.40 |
| | I've moved the assignemnt to Michael as its likely to be a colour problem. | 11:51.20 |
| Robin_Watts | kens: So, ordered a second monitor yet? :) | 13:45.53 |
| kens | Not yet | 13:53.14 |
| Robin_Watts | But your machine is coping OK? | 13:56.20 |
| kens | So far, yes | 13:56.58 |
| henrys | tkampetter:I wonder if we shouldn't specify a large bitmap on the linux desktop and avoid banding in most cases. | 14:25.06 |
| | tkamppeter | 14:26.02 |
| LaoLang_cool | tor8, where can I post my feature request? I want a cmd to show pdf's bookmark with the format like: section 1: page 1 | 14:32.34 |
| | show the bookmark to the std out | 14:32.56 |
| tkamppeter | henrys, this could be a possibility as modern desktop PCs usually have enough memory (also servers based on similar hardware and netbooks), banding is perhaps only needed on embedded (printer, cell phone, ...). | 14:42.23 |
| | henrys, is there a simple command line option to block banding/force full-page? | 14:44.31 |
| Robin_Watts | -dMaxBitmap=10000 will force banding on. | 14:46.03 |
| | (well, it sets a low maximum bitmap, which effectively forces it on). | 14:46.23 |
| | -dMaxBitmap=100000000 will set a large one, and so pretty much forces it off. | 14:46.43 |
| tkamppeter | Robin_Watts, I want to avoid banding. I want to force full-page. | 14:46.49 |
| Robin_Watts | So the latter one is what you want. I need to type faster :) | 14:47.16 |
| tkamppeter | Robin_Watts, thanks. | 14:47.32 |
| Robin_Watts | np. | 14:47.37 |
| henrys | thanks Robin_Watts I stepped away. | 14:57.23 |
| Robin_Watts | np. | 14:57.40 |
| tkamppeter | Robin_Watts, henrys, Oneiric has RIP_MAX_CACHE=128m when CUPS calls Ghostscript. Perhaps we should set it to 1/4 of the computer's memory as we did in former times, this would make reasonably modern PCs work in full-page mode. | 15:14.33 |
| | Robin_Watts, henrys, I do not know, would RIP_MAX_CACHE=auto (no fixed memory size imposed by the CUPS Raster driver assure full-page mode on modern PCs? | 15:15.56 |
| Robin_Watts | I have no idea what RIP_MAX_CACHE does. | 15:16.15 |
| henrys | I don't about RIP_MAX_CACHE either - just the documented gs options. | 15:16.30 |
| Robin_Watts | Looks to me like RIP_MAX_CACHE only affects cups. | 15:17.13 |
| chrisl | RIP_MAX_CACHE is a (hacky, IMHO) "backdoor" for the cups device to set the maximum raster size. | 15:19.40 |
| tkamppeter | RIP_MAX_CACHE is an option of the CUPS driver and it sets the sizes of space_params->MaxBitmap and space_params->BufferSpace to the given value. If it is set to an invalid value (like "auto") the usual automatic mechanisms of Ghostscript are used. | 15:23.35 |
| | henrys, Robin_Watts ^^ | 15:23.47 |
| henrys | well that should be fine ... | 15:27.14 |
| chrisl | RIP_MAX_CACHE isn't an option, as we would define it (set by -sRIP_MAX_CACHE), it's an env variable that the cups device interrogates. | 15:28.20 |
| tkamppeter | RIP_MAX_CACHE=auto and RIP_MAX_CACHE=XXX up to 512m gives the error RIP_MAX_CACHE=1024m works. | 15:32.22 |
| | Robin_Watts, henrys, so this file requires a lot of memory for GS switching into full-page mode. And with Ghostscript's own memoery management it seems to stay in banding mode. | 15:33.54 |
| henrys | the difference in memory used between banding and full page mode shouldn't vary between different files. The memory coost of full frame is a fixed and a function of resolution, page size and depth. | 15:37.37 |
| | /vary/vary much | 15:38.19 |
| Robin_Watts | henrys: Not sure if I agree about that statement. | 15:40.19 |
| | The difference in memory used for full page mode won't vary much between files. As you say, it's fixed and a function of res/size/depth. | 15:40.52 |
| | The memory used for banding mode depends on the complexity of the page contents. | 15:41.05 |
| ray_laptop | I saw discussion about the "full page mode" | 15:41.12 |
| | with a given MaxBitmap, if the file has transparency, gs allows for transparency buffers, so it is NOT just the final page | 15:41.56 |
| Robin_Watts | oh yes, I'd forgotten transparency. | 15:42.32 |
| henrys | Robin_Watts:yes but are exploring the downside to full page not banding. | 15:42.48 |
| ray_laptop | current toolbin/pdf_info.ps reports if a page uses transparency: gs -- toolbin/pdf_info.pdf ___.pdf | 15:42.50 |
| | the downside to full page ??? | 15:43.27 |
| | the memory cost of full page with transparency can be extensive, depending on file contents | 15:44.17 |
| | the other 'hog' that we have is jasper (if there is a large JPX image) | 15:45.00 |
| henrys | we are simply discussing a good compromise for when to band on the linux desktop. I would think we would rarely want to band. | 15:46.18 |
| ray_laptop | setting a big number for MaxBitmap (and MaxPatternBitmap) will help performance, and if there is transparency it may still band, but I assume you don't want gs to gobble up memory past about 50% of the real RAM | 15:48.05 |
| henrys | and the current threshold for banding is too low, but ray_laptop please advise tkamppeter since you're the banding expert. | 15:48.07 |
| | Robin_Watts:my redoing of pcl color spaces is probably going to take longer than the planar project, so take your time. | 15:49.32 |
| ray_laptop | if it is linux running on a desktop (with pretty much a single user), then a large RIP_MAX_CACHE will help performance -- even if we band, there will be fewer bands (fewer bands also helps) | 15:49.36 |
| Robin_Watts | henrys: ? | 15:49.54 |
| | I'm *hoping* that I've got the planar stuff to the stage where it's not giving any differences. | 15:50.31 |
| | Just waiting for a cluster test. | 15:50.39 |
| ray_laptop | but if it is linux on a "server" (converting pages for delivery to a multitude of users on the cloud), then having them all trying to allocate lots of RAM will lead to thrashing | 15:50.54 |
| henrys | then you are way ahead of me, the entire project needs my changes to pcl also - before customer presentation, so the schedule just fell behind. | 15:52.08 |
| | I guess I could hack a workaround into pcl, but I've been meaning to redo the color spaces for quite some time. | 15:53.22 |
| Robin_Watts | There is still ample scope for their to be another yawning pitfall that will only be revealed when marcosw tests again. | 15:53.49 |
| henrys | and performance? | 15:54.07 |
| Robin_Watts | Last time I checked, we averaged out at the same. | 15:54.26 |
| | but varied beween 1/2 and twice as fast. | 15:54.39 |
| | That's without michaels new halftoning stuff enabled. | 15:55.29 |
| henrys | it really is worth understanding those differences if they are simple. | 15:55.42 |
| Robin_Watts | I'll get marcosw to run another set of tests for me, and then look again at the slowest ones. | 15:57.20 |
| ray_laptop | tkamppeter: I think running RIP_MAX_CACHE at 250M would be reasonable on modern machines. That's enough for an RGBW A4 page at 720 dpi (slightly larger than 'letter'). The next 'bump' would be 550M (for a 1200 dpi page in full color) | 15:57.42 |
| | tkamppeter: even if it has transparency, that'll cut the number of bands down. | 15:58.46 |
| kens | Night all. | 16:01.32 |
| Robin_Watts | Night kens | 16:01.41 |
| henrys | so far the killer git feature for me has been git add -p | 16:04.15 |
| Robin_Watts | tor8: ping ? | 16:05.28 |
| tor8 | Robin_Watts: pong. | 16:05.44 |
| Robin_Watts | I can't look at any more rop/clist code. | 16:06.02 |
| | I need a break; so I thought I might do some mupdf stuff. | 16:06.14 |
| | how's the exception handling going? | 16:06.22 |
| tor8 | no news since last you asked | 16:06.46 |
| Robin_Watts | tor8: So if I pick up and carry on from failing_allocs is that going to conflict with stuff you've done ? | 16:07.09 |
| tor8 | I put the stuff I was toying with to understand all your changes on my repo | 16:07.11 |
| | as a continuation on your failing_allocs | 16:07.28 |
| Robin_Watts | I'll pull that in before continuing then. | 16:07.38 |
| tor8 | it's mostly reorganizing the files, some function renaming and threading the context through a few more places | 16:08.05 |
| ray_laptop | what's the schedule for our race team -- anybody know ? (usually Miles sends out an email in advance -- did I miss it) | 16:11.46 |
| Robin_Watts | Inicia del 21 al 27 de Octubre | 16:13.45 |
| ray_laptop | Robin_Watts: Gracias | 16:14.08 |
| Robin_Watts | My spanish is poor, but I reckon that's "Taking place between..." | 16:14.18 |
| | Morning mvrhel2 | 16:15.16 |
| mvrhel2 | Good morning Robin_Watts: Thanks for tracking down that one issue. I think your fix is correct. I was not expecting negative indexing into there | 16:15.46 |
| Robin_Watts | mvrhel2: Cool. | 16:15.55 |
| mvrhel2 | and doing the period offset is correct | 16:16.01 |
| Robin_Watts | Want to commit that, or should I ? | 16:16.01 |
| mvrhel2 | you can go ahead | 16:16.06 |
| Robin_Watts | OK. | 16:16.09 |
| ray_laptop | mvrhel2: Robin_Watts: what if dy is < -thresh_height ? | 16:18.41 |
| mvrhel2 | that is a good point | 16:18.56 |
| Robin_Watts | ray_laptop: % is broken in C, but it's not that broken. | 16:18.59 |
| mvrhel2 | ah | 16:19.12 |
| | so that was the source of the negative input | 16:19.24 |
| tkamppeter | ray_laptop, for the example of the bug I have to set 1024M as a minimum. 512M and lower gives the error. | 16:19.53 |
| ray_laptop | tkamppeter: for 720 dpi, A4, to prevent banding when you have transparency you need MaxBitmap of 950M or so | 16:21.00 |
| | (assuming RGBW) | 16:21.14 |
| Robin_Watts | tkamppeter: The correct fix is of course for us(*) to fix the bug with the banding code. (* where us = a set of people not including me :) ) | 16:21.53 |
| ray_laptop | tkamppeter: the 'heuristic' for pages with transparency adds 15 bytes per pixel | 16:22.02 |
| | tkamppeter: which bug is it ? | 16:22.22 |
| tkamppeter | ray_laptop: http://bugs.ghostscript.com/show_bug.cgi?id=692568 | 16:22.45 |
| ray_laptop | tkamppeter: thanks | 16:22.53 |
| Robin_Watts | tor8: Urm... | 16:23.21 |
| | Did you rename the branch 'context' ? | 16:23.31 |
| tkamppeter | ray_laptop, this means that RGBW being 4 bytes per pixel we go up to 19 bytes per pixel for adding transparency, having a factor of 5 in memory consumption. | 16:24.08 |
| ray_laptop | tkamppeter: correct, so for this page at 600 dpi (assuming transparency) we would need MaxBitmap=700000000 | 16:26.04 |
| tkamppeter | ray_laptop, what would be a quick workaround then to make full-page mode the usually used one, so that Oneiric users get the best "printing just works" experience. Ghostscript errors and crashes are rare already, but minimizing them is always a good idea. | 16:30.47 |
| ray_laptop | tkamppeter: mvrhel2: I can reproduce the error on Windows with: gswin32c -r600 -sDEVICE=cups -o nul: -dcupsColorSpace=17 Bug692568.pdf | 16:31.23 |
| mvrhel2 | can you add that to the bug report ray_laptop | 16:34.27 |
| ray_laptop | mvrhel2: just did. It's another instance of the clist not having the correct color space (depth) when reading a set_color so it doesn't consume the correct number of bytes when reading | 16:36.51 |
| mvrhel2 | ok. I would have thought we would have all those fixed by now. but probably this RGBW color space and its odd properties are making an odd situation | 16:38.55 |
| | thanks for looking into the bug ray_laptop. | 16:40.16 |
| henrys | mvrhel2:when do you leave? | 16:41.18 |
| mvrhel2 | I am already here. arrived this weekend | 16:41.38 |
| henrys | oh okay. | 16:42.27 |
| | mvrhel2:don't forget to have a vacation ;-) | 16:43.06 |
| mvrhel2 | yes. I will take a few days off. going to work on this xps bug now. 692507 is a color/scaling issue in the image interpolation code | 16:45.14 |
| | turns out to occur with the interpolation of 16 bit images in pdf files too | 16:45.35 |
| | not sure how that got by the regression testing | 16:45.51 |
| | probably was me who broke it though | 16:46.00 |
| ray_laptop | mvrhel2: we probably don't have interpolation on many 16-bit images | 16:46.16 |
| | mvrhel2: I know we don't have that many 16-bit images. But I would think the PDF FTS would have some -- just maybe not interpolated | 16:47.00 |
| mvrhel2 | right. in the xps test files there are some 16 bit images and we are set up to interpolate always in xps | 16:47.21 |
| | so those diffs should have caught it | 16:47.31 |
| Robin_Watts | tor8: So you want to go the volatile route, rather than the fz_var route? | 16:54.43 |
| | What do you propose to do about the warnings that throws up? | 16:54.55 |
| | tor8: And given that you've renamed calloc to malloc_array to more accurately reflect what it does, can I have an fz_calloc please? | 17:01.59 |
| ray_laptop | this screwy cupsColorSpace=17 is 1-bit per component RGBW !!! yuk ! | 17:39.44 |
| tkamppeter | ray_laptop, the HP drivers usua;;y use RGBW with -dcupsBitsPerColor=8 which leads to 8 bit for each of the three color channels. The 4th channel takes also a byte of memory then, but there are either all bits set or all bits not set. All bits not set marks a black pixel to be printed with black ink or toner, like for example text. | 17:51.48 |
| ray_laptop | tkamppeter: I missed the -dcupsBitsPerColor=8 parameter in my test (but that fails, too) | 17:53.35 |
| tkamppeter | ray_laptop, I have also found in my tests that the bit-depth has no influence. | 18:14.14 |
| tor3 | Robin_Watts: yes, renamed it context because that was the focus of my changes | 18:31.16 |
| Robin_Watts | That's fine. makes sense now I found it :) | 18:31.31 |
| tor3 | Robin_Watts: volatile, but what was that about warnings? | 18:31.34 |
| Robin_Watts | Suppose you have a volatile fz_obj *obj; | 18:31.50 |
| tor3 | fz_obj * volatile obj; I know it's ugly | 18:32.02 |
| Robin_Watts | Then when you pass &obj to a subroutine, you get a warning that you're losing a qualifier. | 18:32.22 |
| tor3 | volatize fz_obj *obj means the data pointed to is volatile, not the pointer | 18:32.44 |
| | same rules as const | 18:32.57 |
| Robin_Watts | I'll try with the volatile in the other place; maybe that'll solve it. | 18:33.07 |
| | Please can I have a fz_calloc? Pretty please? | 18:33.20 |
| tor3 | if it doesn't solve the issue with warnings, I guess we can try a macro | 18:33.42 |
| | fz_calloc? don't really care about the issue, so go ahead | 18:33.52 |
| Robin_Watts | I saw that you'd taken the allocator out of the context. | 18:34.15 |
| tor3 | I'm assuming you just want a shorter malloc+memset? | 18:34.17 |
| | oh yeah, temporarily taken it out so I didn't have to mess with it to rename the malloc/resize_array stuff | 18:34.46 |
| Robin_Watts | tor3: I want the option of calling a function that allocates and clears, yes. | 18:34.50 |
| | Ah, ok, that makes sense. | 18:35.05 |
| | I also noted you'd taken the fz_resolve_indirection out of the context. | 18:35.29 |
| tor3 | meant to put it back in the next commit, but never got around to it | 18:35.31 |
| Robin_Watts | but I understand why now. | 18:35.35 |
| | It's something that's only ever set once, so it's not a threading problem, hence doesn't need to be in the context. | 18:35.56 |
| tor3 | yup | 18:36.08 |
| Robin_Watts | Wish I'd twigged that, as it would have stopped me having to add (and then have you remove) all the ctx's to the fz_is_int( etc. | 18:36.19 |
| tor3 | don't you used sed for that? | 18:36.43 |
| Robin_Watts | Search and replace in an editor, mostly. | 18:37.13 |
| tor3 | ow. I use sed scripts for that sort of stuff. | 18:37.38 |
| | the go language has a nifty tool I'd love to see for C | 18:37.51 |
| Robin_Watts | tor8: Still getting warnings about the volatile stuff. | 23:38.36 |
| tor8 | :( | 23:38.54 |
| | Forward 1 day (to 2011/10/04)>>> | |
IRC Logs