| | <<<Back 1 day (to 2011/07/31) | 2011/08/01 |
| LaoLang_cool | hello, a mupdf question, does it support bookmark? | 01:34.26 |
| | I don't know how to see a pdf's bookmark in mupdf | 01:34.41 |
| tkamppeter | chrisl, henrys, Robin_Watts, I want to thank you for the quick fixes for the most important bugs relevant for printing, especially with Ubuntu. The printing in the upcoming Ubuntu release with GS 9.04 will work great. | 10:08.46 |
| Robin_Watts | tkamppeter: You're welcome. | 10:08.58 |
| | One of our primary goals with this release was to get ourselves back into the linux printing pipeline, so we're glad it's worked out. | 10:09.29 |
| tkamppeter | chrisl, henrys, Robin_Watts, but there still one problem, it is worked around in Ubuntu, but most probably a problem for other distributions. It is bug 691586. Is there perhaps a way to fix it? | 10:10.00 |
| Robin_Watts | tkamppeter: I think I skimmed that bug before... AIUI, if you don't touch RIP_MAX_CACHE, it works fine. | 10:11.11 |
| | If you set RIP_MAX_CACHE, then sometimes it falls over ? | 10:11.23 |
| tkamppeter | Robin_Watts, the thing is that GS works reliably if no RIP_MAX_CACHE is given (or an invalid one) so that GS decides automatically. | 10:12.33 |
| | Robin_Watts, with an unpatched standard CUPS (as in all distros which are not Debian or Ubuntu) CUPS supplies a fixed numeric value and this makes Ghostscript crash with some file, which files work and which files crash depends on the value supplied by CUPS. | 10:14.00 |
| Robin_Watts | OK, so it's a dev cups only thing. | 10:15.31 |
| kens | Suggestion: disable the parameter in GS :-) | 10:15.44 |
| tkamppeter | Yes, it only affects the cups output device. | 10:15.53 |
| Robin_Watts | It's used in 2 places in cups. | 10:16.02 |
| tkamppeter | kens, I also came to this idea this moment, simply ignore the RIP_MAX_CACHE env variable, as this hard limit does not work out. | 10:16.51 |
| Robin_Watts | cupsImageSetMaxTiles (where it sets the maximum number of tiles to use) and cups_get_space_params (where it sets MaxBitmap and BufferSpace) | 10:17.02 |
| kens | Great minds think alike :-) | 10:17.03 |
| Robin_Watts | It would be interesting to know if just nobbling one of those places is enough. | 10:17.27 |
| tkamppeter | kens, Robin_Watts, and many CUPS queues already used GS without respecting that limit, simply all which use drivers like pxlmono, ljet4, ... | 10:17.45 |
| kens | We should fix it in the long term, if we wan tto keep the paramerter. But maybe a quick hack woudl be possible in the release (it would have to be done really quickly now though) | 10:18.14 |
| tkamppeter | Robin_Watts, cupsImageSetMaxTiles is not in GS, am I right? So in GS remain MaxBitmap and BufferSpace. Do you mean not setting one of these two? | 10:21.25 |
| kens | There's a use of RIP_MAX_CACHE in image.c | 10:21.44 |
| Robin_Watts | tkamppetergs/cups/libs/filter/image.c | 10:21.56 |
| | but you may be right that it's not used. | 10:22.06 |
| | I just grepped for it. | 10:22.11 |
| kens | Me too | 10:22.15 |
| Robin_Watts | It does appear to be built in. | 10:23.14 |
| kens | But it doesn't seem to do anything with GS, unlike hte other one which stes GS parameters | 10:24.05 |
| Robin_Watts | kens: Indeed, but I don't profess to understand how devscups works internally. | 10:27.16 |
| kens | Me neither :-) | 10:27.30 |
| tkamppeter | Robin_Watts, cups/libs/filter/image.c is only a library shipped to make GS build under Windows. gdevcups.c uses libcupsimage as dynamic library on a Linux system, but I doubt that it uses the part with RIP_MAX_CACHE. | 10:28.01 |
| kens | The bug report says the effect can be reproduced by setting the buffers manually though. Which is exactly what the first invocation does. | 10:28.05 |
| Robin_Watts | If we set those params manually, that happens before gs decides to band or not. | 10:29.09 |
| | and gs decides to band or not based on what those values are, right ? | 10:29.26 |
| kens | That and media size | 10:29.45 |
| Robin_Watts | I wonder if with devcups, the setting happens after gs has made that decision? | 10:29.46 |
| kens | And resolutionj | 10:29.51 |
| tkamppeter | Robin_Watts, this is how I understand it. | 10:30.01 |
| Robin_Watts | Right, so cups might be setting the values to an untenable level. | 10:30.22 |
| tkamppeter | Robin_Watts, the quickest workaround would be to ignore the env var by putting a return to the beginning of cups_get_space_params(), right after the debug message. | 10:31.12 |
| Robin_Watts | tkamppeter: Yes. | 10:31.20 |
| kens | Quick fix: remove the setting from gdevcups.c. Very safe for release. Later we can try and figure out why. | 10:31.26 |
| Robin_Watts | And as that's a change within gdevcups, it shouldn't affect any of the tests that marcosw is running. | 10:31.46 |
| kens | regression tests cups. | 10:32.06 |
| | But almost certainly not by setting that parameter | 10:32.26 |
| tkamppeter | Robin_Watts, and having applied this workaround it can easily happen that never ever someone will complain. GS will simply work. If GS fails, people will complain immediately. | 10:33.07 |
| | kens, Robin_Watts, so I will add the mentioned return and a comment. Should I also close the bug then? | 10:34.12 |
| Robin_Watts | tkamppeter: I'd leave the bug open personally, until we have something in there to explain why it was a problem. | 10:34.38 |
| kens | I think that too | 10:34.56 |
| Robin_Watts | i.e. if we've just masked the symptom, but an underlying problem remains, we should have a reminder somewhere for us to solve it. | 10:35.11 |
| tkamppeter | tkamppeter, OK. I will leave the bug open but tell there that a workaround is applied for the time being. | 10:40.53 |
| | Robin_Watts, kens, chrisl, henrys: Workaround commited to master as 16c410fc29575. Can merge it into 9.04, thanks. | 11:09.01 |
| kens | One for chrisl to deal with | 11:09.25 |
| Robin_Watts | I can imagine that giving warnings on lots of platforms. | 11:11.03 |
| | 'Unreachable code' and all that. | 11:11.28 |
| tkamppeter | Robin_Watts, so better to comment out the original code? | 11:12.40 |
| Robin_Watts | tkamppeter: Let me try a modified version. | 11:12.52 |
| tkamppeter | OK. | 11:14.25 |
| Robin_Watts | I'd personally prefer: http://www.ghostscript.com/~robin/test.txt | 11:14.43 |
| | Any comments from people before I commit that? | 11:15.14 |
| | kens: This shouldn't invalidate marcosw's testing, as he'll never have RIP_MAX_CACHE set, and so this code won't be doing anything anyway. | 11:16.02 |
| kens | Yes, that's what I was saying | 11:16.16 |
| Robin_Watts | tkamppeter: Can you confirm that this genuinely fixes the problem with an unpatched printing system? | 11:17.19 |
| | This only patches 1 of the two places in the source where RIP_MAX_CACHE is read. | 11:17.40 |
| | I know we don't *think* the other one matters, but it would be good to double check. | 11:17.56 |
| | no objections to me committing... speak now... | 11:18.42 |
| tkamppeter | Robin_Watts, I have reviewed it now and this is correct. please commit it. | 11:19.02 |
| Robin_Watts | tkamppeter: Thanks. | 11:19.18 |
| tkamppeter | Robin_Watts, thanks. GS works for me also with the variable set now. | 11:24.23 |
| Robin_Watts | tkamppeter: Excellent stuff. | 11:24.44 |
| tkamppeter | chrisl, can you please pass my and Robin_Watts' commits over to 9.04, thanks. | 11:24.57 |
| Robin_Watts | Hey tor8 | 11:46.28 |
| | There is a mupdf commit on casper for you. | 11:46.43 |
| | tor8: At some point, I'd like to have a chat about some small but wide ranging changes I'd like to make to mupdf. | 11:47.31 |
| sebras | Robin_Watts: I'm curious too... | 11:55.50 |
| Robin_Watts | sebras: I want to introduce a 'context' to mupdf. | 11:56.14 |
| tor8 | Robin_Watts: now's as good a time as any :) | 11:56.16 |
| sebras | what should go into the context? | 11:56.50 |
| Robin_Watts | The context is a pointer to a structure where we can have lots of different things. | 11:57.14 |
| | Initially, I'd like there to be a 'allocator' section of the context, so that calls to malloc/free etc all go via it. | 11:57.42 |
| | Thus people can replace which malloc/free etc are used by fiddling with the context. | 11:58.14 |
| | It means we can add a 'cache' for decoded/scaled images etc easily. | 11:58.42 |
| | without impacting on the core of mupdf. | 11:58.53 |
| tor8 | Robin_Watts: mupdf had a context at one point in time. that was before 2004 though. | 11:59.40 |
| Robin_Watts | The change is wideranging in that everywhere that calls fz_malloc/fz_free etc will have to now pass in the context, and hence the context will have to be passed through the code. | 11:59.43 |
| tor8 | passing it around everywhere as an extra argument drove me nuts | 12:00.04 |
| kens | Robin_Watts : the regression report shows differences in 99-01.ps. Its a Quality Logic file, so it may be benign, but I think it shuld be checked. | 12:00.05 |
| Robin_Watts | It's not quite as big a change as it might be because we can put a context pointer in the device structure, and hence pass it for free. | 12:00.33 |
| tor8 | Robin_Watts: a context passed around everywhere is a global in all but name | 12:00.41 |
| Robin_Watts | tor8: absolutely not. | 12:00.49 |
| | multiple instances are impossible with a global, but no problem at all for a context. | 12:01.17 |
| tor8 | Robin_Watts: the pdf_xref struct is the 'context' for the pdf interpreter | 12:01.24 |
| Robin_Watts | tor8: Not really. That's the handle for an open file, right? | 12:01.50 |
| tor8 | it's what we pass around to everything in the pdf interpreter | 12:02.07 |
| Robin_Watts | Suppose I want one instance of mupdf to handle several open pdf files at once. | 12:02.07 |
| | Then I want one context, but multiple pdf_xrefs. | 12:02.26 |
| | The pdf_xref can contain a pointer to the context, and so if we are passing a pdf_xref, no need to pass a context too. | 12:02.49 |
| | but we'd be foolish to assume one pdf_xref per context. | 12:03.24 |
| tor8 | if you want a special data structure for a given use, add it explicitly rather than hiding it in a vague catch-all context | 12:03.48 |
| Robin_Watts | tor8: Then you can easily end up plumbing many things through layers. | 12:04.33 |
| tor8 | http://git.ghostscript.com/?p=mupdf.git;a=blob;f=base/memory.c;h=88102d003b6df04545085cd88b446ea1ba2e4070;hb=6ddde92a3a45e970b05770633dc6a337d5d013c5 at one point we had a fz_memorycontext for replacing malloc with whatever you want. it's overkill, and nobody used it. if you want to replace malloc in mupdf, replace fitz/base_memory.c and the three functions in there instead. | 12:04.39 |
| Robin_Watts | where a single context pointer is much less of an impact. | 12:04.45 |
| | tor8: There is a reason for me wanting this... | 12:05.07 |
| tor8 | and a much muddier design, slippery slope and all that | 12:05.13 |
| Robin_Watts | The biggest single drawback with mupdf is, IMHO, it's lack of handling for out of memory errors. | 12:05.37 |
| | I'd consider that a showstopper for deploying it as a viewer for embedded devices. | 12:06.38 |
| tor8 | Robin_Watts: lack of manpower for testing all out of memory error handling (and bloating the code size by twice, thanks to not having sane cleanup functionality in C) is what made us do what we do now | 12:06.46 |
| Robin_Watts | I'm amazed we've gotten away with it for so long. | 12:06.51 |
| tor8 | what're you going to do when you get an out of memory? it's not like you can continue... | 12:07.08 |
| Robin_Watts | tor8: Well, testing can be achieved with Memento :) | 12:07.08 |
| | tor8: You absolutely can! | 12:07.18 |
| tor8 | â¦in any meaningful way, without a lot of special handling | 12:07.38 |
| Robin_Watts | You can choose to drop parts of the rendering, or render in strips or... | 12:07.53 |
| tor8 | yeah, then there's the lack of time and manpower to implement it all⦠:) | 12:08.16 |
| Robin_Watts | the choice of what you do is a policy decision that can be deferred. | 12:08.20 |
| | The fact that we can't cope is unacceptable in my view. | 12:08.37 |
| | If we move to a) trapping such errors, and b) having a context, I think we open ourselves up nicely to being able to implement different approaches. | 12:10.13 |
| tor8 | I'm not opposed to the general idea of not coping; but adding error detection, propagation and cleanup without bugs at all allocation sites is not trivial | 12:10.15 |
| Robin_Watts | tor8: Right, but mementos memory squeezing code can ensure we're still safe. | 12:10.38 |
| tor8 | Robin_Watts: TLS, or global context that you set before calling (as per opengl) for a memory manager | 12:10.57 |
| Robin_Watts | It allows us to check every exit route through the code with practically no effort. | 12:11.08 |
| | tor8: That scales poorly with threads. | 12:11.22 |
| | sorry, TLS, yes. | 12:11.27 |
| | TLS would be acceptable, but TLS is often slow. | 12:11.39 |
| tor8 | errno is TLS :) | 12:11.47 |
| Robin_Watts | I really don't think that a context would adversely affect mupdf that much. | 12:11.58 |
| | I'd like to try it on a branch. | 12:12.34 |
| tor8 | I'm more inclined to implement fz_try_malloc and handle the 90% use cases where you run out of memory for big resources and images | 12:12.51 |
| | and only in places where we can reasonably do "something else" with it other than just propagate up to the top and say "sorry" | 12:13.23 |
| Robin_Watts | tor8: I'd like to do context, because plumbing the context down to the mallocs means I'm touching exactly the sites that I need to touch to cope with error returns from mallocs. | 12:14.11 |
| | Then with the context in place, I can do a simple cache manager. | 12:14.37 |
| tor8 | running out of memory in the middle of loading an object is not easily recoverable | 12:14.39 |
| Robin_Watts | tor8: Indeed. | 12:14.46 |
| | Where the cache manager bins things from the cache when mallocs fail. | 12:15.01 |
| tor8 | Robin_Watts: you can do that right now, but you'll have to implement a cache manager and memory allocator that knows about said cache manager first. how about trying that using a TLS context? | 12:15.50 |
| | i.e. the malloc call will clear the cache, or did you imagine the caller noticing something failed, clear out some space, and retry? | 12:16.27 |
| Robin_Watts | tor8: The malloc call with selectively bin from the cache. | 12:16.45 |
| | s/with/will/ | 12:16.50 |
| | it doesn't just bin everything. | 12:17.02 |
| | Doing a cache manager before sorting fz_malloc failures is pointless, IMHO. | 12:17.46 |
| tor8 | how so? now you have soft malloc failures which can be recovered automatically by binning cached stuff, and hard failures when you've really gone and run out of memory | 12:18.31 |
| | none of the callers need know or care about the first case | 12:18.45 |
| Robin_Watts | Right, but a hard failure that takes the whole app out is a much larger problem, and that deserves solving first. | 12:19.06 |
| tor8 | change abort() to longjmp() and let the app handle it. not that it will change much on linux, where I believe the process will just be terminated rather than get an out of memory if the kernel has overcommitted | 12:20.01 |
| Robin_Watts | also, I'd be deeply unhappy with a fz_try_malloc that can fail, where a fz_malloc can't. | 12:20.25 |
| | Principle of Least Surprise says that fz_malloc should behave like malloc :) | 12:20.50 |
| chrisl | tkamppeter: I've pulled the two commits in to 9.04 | 12:21.17 |
| Robin_Watts | chrisl: Did you pull in 951dee0 ? | 12:21.40 |
| | That's the VS2003/VS6 fix? | 12:21.52 |
| chrisl | No | 12:21.57 |
| tor8 | Robin_Watts: hmm, yeah, I've violated that principle a lot with the fz_*alloc functions | 12:22.07 |
| Robin_Watts | I suspect that should be pulled in | 12:22.18 |
| tor8 | like fz_calloc being counted-alloc not clear-alloc as well | 12:22.20 |
| chrisl | Robin_Watts: okay, done, too. | 12:23.27 |
| tor8 | fz_try_alloc, fz_alloc, fz_alloc_array, fz_resize_array, would probably be better names | 12:23.41 |
| chrisl | wonders why bother with a release candidate....... :-( | 12:23.47 |
| Robin_Watts | tor8: I might try some of this while I'm on holiday. | 12:23.47 |
| | chrisl: Thanks/Sorry. | 12:24.01 |
| chrisl | Robin_Watts: to honest, I thought that change had gone in to master when sags's other changes were done. | 12:24.35 |
| Robin_Watts | chrisl: nothing you've pulled in should affect the tests that have been done on the rc. | 12:24.44 |
| chrisl | s/to/to be | 12:24.44 |
| tor8 | Robin_Watts: I doubt you'll be able to convince me of checking all malloc errors, and introducing a context passed around everywhere will make the code any nicer to read and/or maintain. if you want me to rename the alloc functions to be less surprising, I'd be more than happy to indulge you though :) | 12:25.32 |
| chrisl | Robin_Watts: it's still not really a valid release candidate - I really ought to do another one, but I can't be bothered, right now. | 12:25.56 |
| tkamppeter | chrisl, thanks for putting in my last changes. | 12:26.19 |
| Robin_Watts | tor8: Well, I feel strongly enough about the first 2, that I feel it needs to be tried. Certainly some sort of solution needs to be found because it's a showstopper for producing a usuable viewer on (say) android. | 12:26.49 |
| | And longjmping all the way back to the app isn't a good solution. | 12:27.04 |
| | It leads to leaks etc. | 12:27.19 |
| | I object to TLS because my previous experience with it has found it to be either horrendously slow, or plain unavailable on some platforms. | 12:28.04 |
| tor8 | Robin_Watts: we have tested all mallocs in the past, but there were an embarrassing number of hidden bugs that lurked underneath it all in untested recovery code | 12:28.21 |
| chrisl | tkamppeter: no problem. I'm wondering if more extensive cups device testing might be good, but I doubt we have the resource to do it properly. | 12:28.23 |
| Robin_Watts | tor8:Right, but memento specifically memory squeezes. | 12:28.43 |
| | so we can catch such bugs easily. | 12:28.55 |
| tor8 | not to mention the chore of writing new code and/or changing algorithms when you have to write and debug twice as much code. memento would come in handy in the first case, but not everybody can/will run that now and in the future. | 12:29.32 |
| Robin_Watts | tor8: Adding memento runs to sane (or something like it) is easy enough. | 12:29.56 |
| tor8 | I had to patch up and fix the malloc cleanup of *all* bug fixes and contributions we got | 12:29.57 |
| Robin_Watts | and how many of those are we getting at the moment? | 12:30.19 |
| tor8 | I don't think I ever got a single contribution that did malloc cleanups right. just look at the stuff in ghostxps, where we do check malloc returns. I know a couple of places where mvrhel (not to name and shame) didn't check malloc returns in some contributions. | 12:31.02 |
| | Robin_Watts: quite a few, from sumatrapdf | 12:31.15 |
| | I'm just saying it's a lot of extra work, even with help from memento to check the correctness | 12:32.04 |
| Robin_Watts | I thought most of the sumatrapdf things were in the form of small bugfixes? | 12:32.13 |
| tor8 | and it's not like we haven't got stuff to do... | 12:32.25 |
| Robin_Watts | It's work that we can't avoid doing, IMHO, if we want mupdf to be more than a toy. | 12:32.47 |
| tor8 | bug fixes, and every single one that touches a malloc or sits between a malloc and an error cleanup, needs to be fixed | 12:32.56 |
| | saying "sorry, out of memory" in one place or another doesn't change the fact that you ran out and can't continue. if you can continue by clearing out cached memory and retrying the malloc can be fixed without testing every malloc call site. | 12:34.43 |
| Robin_Watts | I spent 10+ years working on a product that views PDFs (and other formats) on a huge range of devices that shipped millions of copies. I'm aware how much work it is. I'm also aware of just how vital it is. | 12:35.07 |
| | (and that ran on devices with much smaller amounts of memory than we'd ever consider running in today) | 12:35.28 |
| tor8 | 7 years ago I agreed with you :) | 12:36.16 |
| Robin_Watts | http://bugs.ghostscript.com/show_bug.cgi?id=692377 oh ass. | 12:37.28 |
| tor8 | we checked every malloc obsessively until about two years ago when the benefits weren't showing they outweighed the cost of development | 12:37.29 |
| Robin_Watts | Anyhow... lunchtime. | 12:39.39 |
| tor8 | Robin_Watts: s/fz_catch(-1, /fz_warn(/ | 13:01.08 |
| Bheam | i'm running 8.70 off centos yum repo, and i had a problem converting a document, where an image got tiled all over the page and 10% of the supposed size (not even supposed to be tiled) | 13:02.36 |
| Robin_Watts | tor8: Ah! | 13:07.49 |
| | Have you changed that, or should I? | 13:08.02 |
| tor8 | I haven't | 13:08.09 |
| Robin_Watts | (I am happy to, obviously) | 13:08.10 |
| | I will change that now and republish. | 13:08.21 |
| tor8 | alright | 13:08.27 |
| Robin_Watts | Bheam: Have you tried 9.0x ? | 13:09.58 |
| | tor8: Fixed. | 13:12.41 |
| tor8 | Robin_Watts: pushed. | 13:15.42 |
| Robin_Watts | Ta. | 13:15.51 |
| Bheam | Robin_Watts: no, compiling from source is a hassle so thought i'd ask first | 13:21.06 |
| Robin_Watts | Bheam: Well, if you can make the file available, I can try it in 9.0x for you. | 13:22.42 |
| | oh, gawd. | 14:03.29 |
| kens | ? | 14:03.33 |
| Robin_Watts | I think I've figured out the cause of http://bugs.ghostscript.com/show_bug.cgi?id=692377 | 14:03.53 |
| kens | Ah... | 14:04.08 |
| Robin_Watts | tor8: I think it's to do with the way that constant alpha is done. | 14:05.49 |
| tor8 | uh oh... | 14:06.05 |
| Robin_Watts | If I'm understanding this right, we ignore constant alpha until we come to blend the pixmap back. | 14:06.21 |
| | at which point we scale the pixmap by the alpha, and blend back. | 14:06.43 |
| | That works for isolated things, but not non-isolated things. | 14:06.56 |
| | because the scaling should 'scale up' the background. | 14:07.13 |
| tor8 | we do pass constant alpha to drawing primitives, but we handle it in a few different ways in the draw device. you're referring to the fz_draw_end_group call where it blends with the alpha parameter? | 14:08.36 |
| Robin_Watts | I'm referring to the "TODO: fix this hack" in fz_blend_pixmap | 14:09.04 |
| | which is called from fz_draw_end_group, yes. | 14:09.17 |
| tor8 | ah, that one! :) | 14:09.34 |
| Robin_Watts | hmm. Maybe I can solve it by (in non isolated cases), multiplying the shape by the alpha. | 14:11.06 |
| | actually, that's going to be wrong for some blending modes I suspect. | 14:12.08 |
| | No, actually, it might be alright. | 14:19.57 |
| tkamppeter | chrisl, I have got two patches for trivial bugs on the gstoraster CUPS filter from Tim Waugh from Red Hat, bug 692384 and bug 692385. I have applied them to the GIT. Can you pass them over to 9.04? Thanks in advance. | 14:32.54 |
| chrisl | tkamppeter: are these regressions in the 9.04 code? | 14:38.32 |
| tkamppeter | chrisl, yes, as these problems do not occur with the predecessors of the new gstoraster filter, pdftoraster and pstoraster. | 14:40.53 |
| | chrisl, thanks for passing the patches over. | 14:41.29 |
| chrisl | tkamppeter: okay, thanks. | 14:41.45 |
| henrys | Robin_Watts:I think Alex's fix should be backed out unless he has another fix for the introduced issue - in which case the log messages should be changed. | 15:09.26 |
| Robin_Watts | henrys: We can't easily change the log messages. | 15:09.50 |
| | But I can certainly back it out with an apology. | 15:10.07 |
| henrys | if we changed it everyone would have to clone a new tree right? | 15:18.53 |
| Robin_Watts | No, they would just have changes overridden next time they pulled. | 15:19.41 |
| | (or could clone a new tree) | 15:19.56 |
| kens | Another muppet request on the support list :-( | 15:22.28 |
| henrys | well let's just back it out for now. | 15:22.50 |
| Robin_Watts | I already have :) | 15:23.12 |
| | tor8: I have 7 out of the 8 images in l16.pdf looking right. | 15:23.47 |
| | http://ghostscript.com/~robin/out.png | 15:25.12 |
| | It's the last one of the top 4 that's wrong. | 15:25.31 |
| | and I think that might be to do with the fact it uses HardLight blending. | 15:26.58 |
| | tor8: alive ? | 15:52.26 |
| tor8 | Robin_Watts: was out grocery shopping | 16:00.21 |
| Robin_Watts | tor8: np. | 16:00.32 |
| | http://ghostscript.com/~robin/dump.zip | 16:01.05 |
| | A set of pngs. | 16:01.22 |
| | Each group of 6 corresponds to the end of one group. | 16:01.43 |
| | Where we have to blend what has been rendered (0) onto the background (1) where the render has shape (2) and the background has shape (3). | 16:02.27 |
| | And that gives (4) with shape (5) | 16:02.36 |
| tor8 | Robin_Watts: I'll take a closer look after I've been fed. back in a few :) | 16:02.50 |
| Robin_Watts | The first 3 blends have constant alpha = 0.5 | 16:03.04 |
| | The next one has the hardlight blend mode. | 16:03.30 |
| | np. | 16:03.32 |
| kens | I'm off, night all. | 16:25.21 |
| Robin_Watts | Gottit. | 16:41.57 |
| tor8 | Robin_Watts: i'm back, what do you want me to look at? | 16:47.35 |
| Robin_Watts | tor8: Let me update stuff. | 16:47.51 |
| | Everything appears to be working except for the hardlight stuff. | 16:48.10 |
| | http://ghostscript.com/~robin/non-iso.png is l16.png rendered with the page as being a non-isolated group. | 16:49.02 |
| | http://ghostscript.com/~robin/iso.png is l16.png rendered with the page as being a isolated group. | 16:49.43 |
| | http://ghostscript.com/~robin/dump.zip are debugging pngs output from the blending code. | 16:52.54 |
| | Specifically the step I'm having problems with is 34 + 35 to give 37 | 16:56.33 |
| tor8 | hm, looks like apple preview has started doing some of the blending operations! | 16:56.59 |
| | is it only hard light blend modes that don't work? | 16:58.05 |
| Robin_Watts | tor8: I don't know. | 16:59.01 |
| | If we have a white background, and we hardlight blue onto it, we should get blue, right ? | 17:06.59 |
| | Maybe it's to do with the order of operations? | 17:11.15 |
| | If we draw the blue circle onto a white background, we get (.5, .5, 1) for the pixels. If we then hardlight white + that, we should get white I think. | 17:12.10 |
| tor8 | hardlight with white source will yield white regardless of backdrop (since it does screen if the source > 0.5) | 17:21.25 |
| Robin_Watts | I'm trying to figure out what we SHOULD be hardlighting. | 17:22.25 |
| | Consider just the blue circle. | 17:22.30 |
| | Either we've got a solid blue circle, or we've got a 1/2 intensity one, depending on when the alpha scaling is done. | 17:23.04 |
| | And we are hardlighting that onto... what ? | 17:23.27 |
| | If we treat the page as solid white, then we are hardlighting blue onto white. | 17:24.08 |
| | If we treat the page as transparent... god knows. | 17:24.20 |
| tor8 | Iâ¦have no idea | 17:28.10 |
| Robin_Watts | I have a cut down file here. | 17:29.03 |
| | THe contents do: /GS0 gs /Fm0 Do | 17:29.17 |
| | The graphics state there has nothing of interest, except that it sets the blend mode. | 17:29.31 |
| | But it's only the Do that makes us start a group. | 17:30.00 |
| | Given that we only ever blend at the end of a group, shouldn't we start a group before executing anything after the gs ? | 17:30.44 |
| | Like, if I was to do: /GS0 gs (paint a path) /GS1 gs | 17:32.15 |
| | wouldn't we need a group around the path painting to get the blending mode stuff working ? | 17:32.45 |
| tor8 | Robin_Watts: we do create groups for each path painting if needed | 17:33.28 |
| Robin_Watts | tor8: do we? | 17:33.39 |
| tor8 | pdf_begin_group() | 17:34.06 |
| | is called from pdf_show_path | 17:34.18 |
| Robin_Watts | Right. | 17:34.31 |
| tor8 | that one checks if we have a softmask and/or blendmode | 17:34.38 |
| | and pushes the implicit transparency group per primitive | 17:34.51 |
| Robin_Watts | But the group we form here has the blendmode from before the xobject rolled into the same group as the isolated and knockout flags from the xobject. | 17:35.40 |
| | I'm wondering if that's right. | 17:36.13 |
| | Maybe all blendmode groups should be isolated or something? | 17:36.33 |
| tor8 | the start of an xobject resets the blend mode for the contents | 17:36.43 |
| | oh, right, you may be on to something there | 17:37.28 |
| Robin_Watts | tor8: Yes. | 17:37.28 |
| tor8 | you stuck the isolated/knockout flags onto the blendmode word right? | 17:38.07 |
| Robin_Watts | I did. | 17:39.05 |
| | Oh. My. God. This file contains more than one /GS0 | 17:42.51 |
| | It's designed to send me mad. | 17:42.57 |
| alexcher | gs_cet.ps is included in %rom% file system twice. | 17:44.08 |
| Robin_Watts | tor8: Right. Forcing isolated off if blendmode is set does look better, but that's just a quick hack to test it. | 17:49.11 |
| | I'll walk the dogs then think about doing it better. | 17:49.22 |
| henrys | alexcher:I see it is in the mkromfs list twice - but when you enumerate thedirectory in the interpreter is it listed 2x? | 17:51.06 |
| alexcher | henrys: yes, that's how I've discovered this. | 17:55.46 |
| henrys | alexcher:well report it as a bug to ray or fix it. | 18:03.49 |
| Robin_Watts | tor8: Right. PDF has the concept of groups. We abuse that idea in order to avoid having to have every plotting method know how to do every blending method. | 18:39.29 |
| | We rely on the fact that rendering to an isolated group and then blending that back gives the same results as plotting direct with a funky blendmode would. | 18:40.11 |
| | So whenever we push a new group because of a change in blendmode, that should be a non-isolated one. | 18:40.32 |
| tor8 | non-isolated, or isolated? | 18:41.01 |
| Robin_Watts | isolated, sorry. | 18:41.10 |
| | The potential problem this leaves us with is when we have a blendmode in force, but we then get a group that specifically requests a non-isolated group. | 18:41.47 |
| | We could push an isolated group for the blend mode, then another non-isolated one for the group contents. | 18:42.54 |
| | We should get away with that, because the group contents have a blendmode of 0. | 18:44.03 |
| | If they then change the blendmode again, they'll push new groups inside that as required. | 18:44.32 |
| | The problem may be ensuring that groups pushed for the sake of blendmodes don't interfere with proper inheritance of backgrounds. | 18:45.08 |
| tor8 | we save the blendmode in used when pushing the group, for applying when we pop the results | 19:03.10 |
| | but that's not what you're talking about? | 19:03.21 |
| Robin_Watts | indeed not. | 19:03.42 |
| | Really, we should have versions of every single plotting function that knows how to plot with a given blendmode. | 19:04.16 |
| | But, that's too horrendous to think about. | 19:04.25 |
| tor8 | indeed! | 19:04.30 |
| Robin_Watts | so we use a trick; we render to an isolated group and then blend the results of that back according to the blendmode. | 19:04.53 |
| | But that trick only works if it's an isolated group. | 19:05.12 |
| tor8 | pdf_run_xobject calls pdf_begin_group as well, for creating the explicit transparency groups | 19:05.21 |
| Robin_Watts | That's the call that's the problem. | 19:06.16 |
| | That call can attempt to make isolated groups with a non zero blend mode. | 19:06.48 |
| | pizza, brb. | 19:06.52 |
| tor8 | ah, you mean you need to communicate which type of group it is with that function (implicit, force isolated, or explicit with isolated/knockout flags) | 19:07.23 |
| Robin_Watts | I think the problem is more that we just can't allow non-isolated groups with a non zero blendmode. | 19:13.48 |
| tor8 | not sure I follow your reasoning there | 19:36.49 |
| | or maybe just not parse properly, too many negations :) | 19:37.10 |
| Robin_Watts | We use isolated groups to 'fudge' funky blendmodes. | 19:41.14 |
| | and to fudge constant alpha. | 19:41.19 |
| | Right? | 19:41.45 |
| tor8 | yes. | 19:43.02 |
| Robin_Watts | i.e. writing to an isolated group with 'Normal mode' then blending the results back in mode X, gives the same results as just initially writing in mode X. | 19:43.08 |
| tor8 | correct. | 19:43.17 |
| Robin_Watts | Sadly, the same cannot be said for non-isolated groups. | 19:43.22 |
| tor8 | so, for primitives it works, but not for groups of several primitives wrapped in an xobject? | 19:44.25 |
| Robin_Watts | So whenever we try to create a non-isolated group with a funky blendmode, we know we're going to get the wrong results. | 19:44.26 |
| | IF the Xobject that wraps those primitives requests non-isolated mode, yes. It will fail. | 19:45.24 |
| tor8 | hm, what did you implement in the patch "Non-isolated group support, and fix Bug 692336." then? | 19:46.59 |
| | I'm feeling rather dense here; that always happens when I think about PDF 1.4 blending | 19:47.27 |
| Robin_Watts | I implemented something that would only work for normal blending modes. | 19:48.33 |
| tor8 | ahhh! | 19:48.47 |
| Robin_Watts | I think. | 19:49.24 |
| | http://ghostscript.com/~robin/out.png | 19:51.47 |
| | Certainly, that looks MUCH better. | 19:51.58 |
| | tor8: Aaargh. | 20:29.30 |
| | After convincing myself that was the problem, I found a bug in the shape alpha handling, and it seems to now be working again... | 20:29.55 |
| tor8 | d'oh! | 20:33.58 |
| Robin_Watts | tor8: OK, I've minimised the diffs and pushed. | 21:28.56 |
| | I'll check it with sane tomorrow. | 21:29.16 |
| | Forward 1 day (to 2011/08/02)>>> | |
IRC Logs
