| | <<<Back 1 day (to 2012/02/12) | 2012/02/13 |
| Fandekasp | hi there | 01:44.27 |
| | Is there a way to display 2 pages per screen with mupdf ? | 01:44.44 |
| Robin_Watts | tor8, sebras: Just a thought. | 11:59.05 |
| | We have the 'fitz' layer in mupdf which was originally the rendering lib, but has burgeoned to include other things (fz_obj, document layer etc). | 11:59.41 |
| | I was wondering if maybe we should pull the document stuff out as a separate layer, maybe called 'mu' ? | 12:00.02 |
| | So the document functions would be called 'mu_open_document' etc. | 12:00.55 |
| tor8 | Robin_Watts: the thought has occurred to me as well. | 12:02.00 |
| Robin_Watts | tor8: I need to make all the document functions take a ctx as well as a doc. | 12:02.24 |
| tor8 | why? | 12:02.37 |
| Robin_Watts | (or at least, all the ones that throw anyway - which I think is all of them) | 12:02.40 |
| | because I need to 'redirect' thrown errors from the doc->ctx to the ctx in use in the document layer. | 12:03.12 |
| tor8 | I thought we decided to not mess anymore with the way the threading works yesterday, but rather fix the bugs that make it crash | 12:03.59 |
| sebras | Mmm, that kind of naming fits with the product name. | 12:04.34 |
| Robin_Watts | I thought we'd agreed to fix the bugs that make it crash, and to ensure that the doc always uses the same context. | 12:04.49 |
| | See 14:40 yesterday in the logs. | 12:06.16 |
| tor8 | I remember, but why let them use the doc from different threads? that's just going to make the clients trip up... | 12:07.52 |
| Robin_Watts | I think it's fair to tell them "only use it from a single thread at a time" | 12:08.23 |
| | but not fair to tell them "only use it from one thread EVER" | 12:08.34 |
| tor8 | I'm not sure I agree that the distinction is worth worrying about | 12:10.35 |
| | but this will only work for the fz_document access level, not the pdf_document level, if I understand what you want to do? | 12:11.19 |
| Robin_Watts | Yes. | 12:12.24 |
| | The fz_document layer, the functions will all take a context. | 12:12.40 |
| tor8 | Okay. | 12:12.55 |
| Robin_Watts | they will then call the pdf_document layer exactly as now, but will silently wrap them in an fz_try/fz_catch thing to ensure that any exceptions thrown are passed to the correct calling context. | 12:13.27 |
| tor8 | That's reasonable enough. That way all (public anyway) fz_ functions take a fz_context, minus the fz_stream stuff which is single threaded by nature. the fz_obj are really pdf only, so I should move them into pdf. | 12:15.55 |
| | oh, and the device functions are also single threaded by nature | 12:16.22 |
| Robin_Watts | Right, but it's reasonable to create a device in one thread, use it, and then destroy it. | 12:16.53 |
| | You won't typically create a device then use it in another thread. | 12:17.09 |
| tor8 | quite. the devices are short lived, as opposed to the document. | 12:17.10 |
| Robin_Watts | Indeed. | 12:17.15 |
| tor8 | and the same with most fz_streams | 12:17.29 |
| | open, read it all, close | 12:17.35 |
| Robin_Watts | yeah. | 12:18.45 |
| | I'd like the fz_obj -> pdf_obj renaming I think. | 12:19.27 |
| | That would enable us to remove the fz_resolve_object hernia, right ? | 12:19.52 |
| tor8 | yup! | 12:19.57 |
| | Robin_Watts, sebras: http://pastebin.com/JCPJsSna is this a reasonable explanation of the context/thread use? | 12:24.57 |
| | i.e. have I misunderstood anything | 12:26.08 |
| Robin_Watts | That's fair at the moment. | 12:27.09 |
| sebras | tor8: no, I don't think so. but Robin is the expert. | 12:27.11 |
| Robin_Watts | brb. | 12:27.26 |
| sebras | tor8: though "other objects" should be better defined. | 12:27.32 |
| | tor8: I guess it is too easy to think that a struct belongs in that category when it really doesn't. | 12:28.02 |
| Robin_Watts | back. | 12:38.47 |
| | yes, just rereading tor8's statement, and it seems pretty much spot on. | 12:39.01 |
| | sebras, tor8: Can 'doc->free_page' or 'doc->close' throw ? | 13:05.00 |
| sebras | Robin_Watts: don't know. | 13:06.19 |
| Robin_Watts | I think the answer to both is no, currently. | 13:06.32 |
| | But, I think to be consistent, I'm going to add the context to those document calls too. | 13:06.58 |
| | (Not the lower level call, but the fz_document level ones) | 13:07.27 |
| | tor8, sebras: New patch pushed to my repo with the document level changes. | 13:47.30 |
| pabix | Hello, I have made an addition to pdfdraw code (apps/mupdfdraw.c) that limits the output size in Mpixels; how can I submit it? | 14:29.09 |
| Robin_Watts | pabix: Open a bug. | 14:29.32 |
| | Add a clear description and a patch | 14:29.40 |
| | bugs.ghostscript.com | 14:29.49 |
| Robin_Watts | pops to post office. | 14:30.00 |
| pabix | thanks | 14:30.07 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=692855 | 14:38.02 |
| sebras | I wonder what the usecase is for pabix patch... | 14:49.58 |
| Robin_Watts | Personally, I'd rather see a -@w,h flag to allow specific width/height to be specified. | 14:55.58 |
| | probably in combination with a --aspect to preserve the aspect ratio. | 14:56.24 |
| sebras | mmm, also why would one want to express this in megapixels!? | 14:57.56 |
| Robin_Watts | I have a 'mudraw' here that does what mupdfdraw does, but through the document interface. | 15:10.20 |
| | Hmm. Hit a problem. | 15:25.25 |
| | We hold fz_objs as part of the cached state in the glyph cache. | 15:26.03 |
| | So if the glyph cache is freed *after* the document, the context to which the glyph cache refers is gone already. | 15:27.09 |
| | So when we free those objects, it dies. | 15:27.24 |
| | So when I destroy a document, I need to purge all the objects from the glyph cache that refer to that document. | 15:28.05 |
| zsw | Robin_Watts: Is there an nice way to print from mupdf? | 15:39.34 |
| Robin_Watts | zsw: The simple mupdf viewer has no hooks to any printing system, no. | 15:40.31 |
| zsw | I use mutt w/mailcap and I use mupdf to preview any attached pdf's. Can you think of a nice way to send the file to lpr? | 15:43.38 |
| | maybe I can get mutt to save all tmp files to the same location (eg /tmp/mutt_attach). Then maybe an alias for 'lpr /tmp/mutt_attach' | 15:44.59 |
| Robin_Watts | Sorry, not in an area I know anything about. | 15:45.23 |
| zsw | No worries. Thanks for the direction and listen to my mumbles ;) | 15:45.54 |
| Robin_Watts | good luck. | 15:46.18 |
| henrys | great showing by Adele last night... | 16:12.03 |
| Robin_Watts | ? | 16:12.47 |
| henrys | the grammies | 16:12.58 |
| Robin_Watts | You went to a gig? Or was there an awards thing? | 16:13.00 |
| | Ah, right. | 16:13.01 |
| henrys | I guess I'm completely out of it, I had no idea she was british | 16:13.38 |
| Robin_Watts | I know she's British, and I know Lagerfeld referred to her as being "a bit fat", and I know I've heard at least 1 song, but I couldn't name it. | 16:14.16 |
| henrys | I figured Helen would be following it being into music and all. | 16:15.15 |
| Robin_Watts | Not if it's composed since 1700 :) | 16:15.33 |
| henrys | The grammys have a classical category. | 16:17.29 |
| | so we accidentally sent paul a bill instead of a check, I guess Miles is straightening it out. | 16:20.01 |
| Robin_Watts | ha! :) | 16:20.10 |
| | chrisl: Ping | 17:10.05 |
| chrisl | Robin_Watts: pong | 17:10.12 |
| Robin_Watts | Did you see the mail to support? | 17:10.22 |
| | from cecil? | 17:10.25 |
| chrisl | I've replied to it | 17:10.31 |
| Robin_Watts | Ah, so you have :) | 17:10.53 |
| chrisl | I didn't realise that the release script specified each file and directory explicitly for the top of the gs tree - so I had to add all those new ones individually :-( | 17:11.43 |
| mvrhel | brb. change of venue | 17:18.31 |
| Robin_Watts | tor8: So I need to fix the freetype locking. | 17:51.04 |
| | So, some stupid questions about freetype and our usage of it, if I may. | 17:51.36 |
| | We typically call FT_Set_Char_Size(face, ....) then we do various measuring operations on that face? | 17:52.02 |
| | So we need to have locked from before that call to after that measuring operation ? | 17:52.30 |
| ray_laptop | I just sent an email. I won't be very available today. | 19:23.23 |
| mvrhel_laptop | darn | 19:25.14 |
| | sorry to hear about that ray | 19:25.18 |
| Robin_Watts | ray_laptop: Ouch! | 19:25.57 |
| mvrhel_laptop | if you need anything work wise to ease your load let us know | 19:25.59 |
| Robin_Watts | Send her my best. | 19:26.03 |
| ray_laptop | thanks guys. I'll let you know. I think I have the image rotation close to done -- I'm collecting lists of files that we have the will trip the code so I can test well | 19:30.03 |
| Robin_Watts | ray_laptop: Slightly worrying that they managed to profile a debug build :( | 19:31.35 |
| ray_laptop | we'll have to wait and see, but it will take some local recruiting (family and friends) for me to be able to attend the staff meeting and get the kids to their Sat activities. More on that after things are more defineid. | 19:32.35 |
| Robin_Watts | I was struggling for a polite way of saying "Seriously, make REALLY sure you're not putting a debug build onto the target and then telling us it's slow". | 19:33.00 |
| ray_laptop | Robin_Watts: I saw that -- which file was that profile ? (all of them ?) | 19:33.07 |
| Robin_Watts | All of them. | 19:33.14 |
| | All of the 0036 profiles (the most recent I had from them) | 19:33.37 |
| ray_laptop | If we can get the backchannel logs from the timing runs, then we can look for the -Z: output. That arg is only added #ifdef DEBUG | 19:35.22 |
| | It _does_ seem pointless looking at a DEBUG profile, 'though | 19:36.09 |
| Robin_Watts | If not pointless, certainly potentially misleading. | 19:36.35 |
| ray_laptop | Robin_Watts: that too | 19:36.43 |
| Robin_Watts | The profiles definitely have mismatched function names in. | 19:37.13 |
| | i.e. it systematically says "x" when it means "y" | 19:37.35 |
| ray_laptop | Robin_Watts: gs_debug_c is ALWAYS there and is called a few time | 19:37.38 |
| Robin_Watts | In all the profiles, yes. | 19:37.51 |
| ray_laptop | Robin_Watts: No, I mean that it is ALWAYS there for a debug or release build] | 19:38.10 |
| Robin_Watts | really? | 19:38.18 |
| | Well, in this case it was called a not insignificant number of times. | 19:39.08 |
| ray_laptop | because we call it to access the gs_debug flags which are used for some release runtime options. -Z: is an example -- it prints OutputPage start/end times even on a release build | 19:39.12 |
| | Robin_Watts: how does it compare to the number of times it is called on a DEBUG simulator run of the corresponding file ? | 19:40.01 |
| Robin_Watts | pass. | 19:40.45 |
| ray_laptop | Robin_Watts: Note that I do my simulator builds without the DEBUG=1 set and without DEBUG or _DEBUG defined to the preprocessor, so I can't tell | 19:41.29 |
| Robin_Watts | 25000 calls from clist_fill_mask | 19:41.55 |
| ray_laptop | Robin_Watts: which test file ? | 19:42.08 |
| | (I'll fire my simulator up and do a run with a breakpoint hit count | 19:42.39 |
| Robin_Watts | WWTTN1CT | 19:42.41 |
| ray_laptop | Robin_Watts: OK. Just a few minutes | 19:43.08 |
| Robin_Watts | maybe that's reasonable then. | 19:43.22 |
| | I was expecting it to be #defined away in non debug builds, so maybe this is a wild goose chase. | 19:45.23 |
| | Supposedly 4 seconds in there within WWTM1CT though | 19:46.13 |
| ray_laptop | Robin_Watts: Sorry -- phone call. the clist_fill_mask has the runtime option: gs_debug_c('`') | 19:54.58 |
| Robin_Watts | Yes. | 19:55.26 |
| | I'm sure sure I believe that 4 seconds can be spent in it though (2 from that function) | 19:55.42 |
| ray_laptop | Robin_Watts: if_debug stuff gets #defined away but gs_debug_c is always there, but I also doubt there are 4 seconds from only 50k calls to such a minimal function. | 19:56.17 |
| Robin_Watts | tor8: ping? | 20:01.18 |
| henrys | ray_laptop:please consider handing off the image rotation stuff to mvrhel_laptop and not worrying about any customer stuff for a few days. | 20:10.41 |
| Robin_Watts | ray_laptop: If you have a couple of minutes for a question, that would be great. If not, don't worry! | 20:13.33 |
| ray_laptop | Robin_Watts: go ahead, but if I go silent, it's because someone popped into the room | 20:14.23 |
| Robin_Watts | ray_laptop: Sure, thanks. | 20:14.31 |
| | clist_image_fill_mask (in gxclimg.c) | 20:14.42 |
| | I have that being called with a rectangle that's trivially outside the clipping path. | 20:15.16 |
| | (If I'm reading the values correctly). | 20:15.40 |
| | As far as I can see we go ahead and write it into the clist regardless. | 20:16.03 |
| ray_laptop | Robin_Watts: first, I don't see "clist_image_fill_mask" | 20:16.43 |
| Robin_Watts | clist_fill_mask, sorry. | 20:16.54 |
| | First function in the file. | 20:17.03 |
| | There are various optimisations I could make in here; if the mask is trivially INSIDE the pcpath, then set pcpath = NULL (i.e. don't encode the clipping path) | 20:18.03 |
| | if the region is trivially outside, don't paint anything. | 20:18.15 |
| ray_laptop | Robin_Watts: what do you mean by "trivially outside the clipping path" ? | 20:18.20 |
| mvrhel_laptop | lunch time. bbiab | 20:18.35 |
| Robin_Watts | Clipping paths have an inside and an outside bounding box. | 20:18.38 |
| | If the rectangle is inside the inner bounding box, then none of it is clipped - so no need for the clipping path. | 20:19.05 |
| ray_laptop | Robin_Watts: if it's completely outside the path, I agree that we should just ignore it | 20:19.05 |
| Robin_Watts | If it's outside the outside bounding box, then we can ignore it. | 20:19.17 |
| ray_laptop | Robin_Watts: and I agree that if it's totally inside, then don't encode the pcpath | 20:19.41 |
| Robin_Watts | Another optimisation is to reduce the rectangle by chopping away the parts of it that are outside the outside bbox. | 20:19.50 |
| | (but if I do that, presumably I have to set the id to be gx_no_bitmap_id, which could conceivably be bad. | 20:20.32 |
| ray_laptop | Robin_Watts: but we need to make sure that the clist state (pcls) clip path corresponds (not some stale incorrect one | 20:20.35 |
| Robin_Watts | This function is called with pcpath as an arg - are you saying that might be stale ? | 20:21.03 |
| ray_laptop | Robin_Watts: I don't think the clist playback code ever uses 'id', or even if we write it to the clist | 20:21.19 |
| Robin_Watts | Fair enough - I wondered if you were smart and spotted repeated id's and hence didn't rewrite bitmaps multiple times. | 20:21.49 |
| ray_laptop | Robin_Watts: not that the pcpath is stale, but the state for a particular band (for the "trivially insisde" case) may have some other clipping path set. | 20:22.21 |
| Robin_Watts | I would be doing this by looking at rx, ry, rwidth, rheight and pcpath. | 20:22.58 |
| ray_laptop | Robin_Watts: we _could_ use a trivial (single rect) clipping path in case the pcpath is complex, however | 20:23.48 |
| Robin_Watts | I don't follow. | 20:24.25 |
| ray_laptop | Robin_Watts: it doesn't try and use 'smarts' in the writing of bitmaps. HP tried using that so that a GEU could store character bitmaps and blit them and tripped over this. | 20:25.25 |
| | I think they are there in page mode, however | 20:25.56 |
| Robin_Watts | Ok, so I don't need to worry about breaking things. | 20:26.14 |
| | Excuse the stupid question, but this routine gets called once, and writes commands for each band? | 20:26.39 |
| | Or it gets called once per band ? | 20:26.45 |
| ray_laptop | away for a bit ... sorry | 20:26.53 |
| Robin_Watts | no worries. | 20:26.57 |
| ray_laptop | Robin_Watts: yes, it gets called for the operation (the entire mask) and writes (parts) of the bitmaps to each band (the RECT_STEP macro does loops over the bands) | 20:30.40 |
| Robin_Watts | ray_laptop: Right. So if I was smart, I'd want to do something in the RECT_STEP loop. | 20:31.28 |
| ray_laptop | Robin_Watts: OK, so the 'id' is used by the writer to determine if the data is in the cache | 20:31.30 |
| | Robin_Watts: if (!cls_has_tile_id(cdev, re.pcls, id, offset_temp)) { | 20:31.48 |
| Robin_Watts | right. That's what I was worried about. | 20:31.51 |
| | So, I should probably avoid chopping the bitmap down if the id is set. | 20:32.11 |
| ray_laptop | Robin_Watts: for characters, iirc, the id _is_ set | 20:32.46 |
| Robin_Watts | Ok, so in that case we'll get 2 of the 3 optimisations only. | 20:33.20 |
| ray_laptop | using a simple clip path if the pcpath isn't already simple and if the mask is trivially inside will only rarely help, and probably not on the WWTT files since they just have a page clip rect | 20:38.41 |
| | (afaik) | 20:38.47 |
| Robin_Watts | I was hoping to a) completely drop some characters, b) use NO clip path at all for others. | 20:40.07 |
| | cluster testing now. | 21:05.56 |
| | tor8: ping ? | 21:06.16 |
| tor8 | Robin_Watts: sorry, had visitors. | 21:32.31 |
| Robin_Watts | tor8: still here? | 21:51.00 |
| | I hit a problem. big nasty problem. | 21:51.08 |
| tor8 | Robin_Watts: yes. | 21:51.18 |
| Robin_Watts | When interpreting a page, I had it swapping to an using the document context. | 21:51.38 |
| | s/an/and/ | 21:51.45 |
| | but then it calls into the device, and that starts to use the device context. | 21:52.08 |
| | So, I think I may have to abandon the whole 'internal context' idea. | 21:52.32 |
| tor8 | oh, right. | 21:52.36 |
| Robin_Watts | And just revert to having the document tied to the thread in which it is created. | 21:52.56 |
| tor8 | yeah, that throws a screw in the spanner (is that the right saying?) | 21:53.01 |
| Robin_Watts | A spanner in the works. | 21:53.09 |
| tor8 | that's the one :) | 21:53.24 |
| malc_ | tor8: pdf_fontfile.c takes around 10 minutes to compile when this box was booted to OS X, also the whole idea to use uname to get the arch type a) is rotten b) doesn't work | 21:54.58 |
| tor8 | malc_: ouch. that's a bit long... | 21:55.26 |
| malc_ | tor8: yeah its, it takes an (comparatively) exorbitant amounts of time on core2duo OSX machine i have | 21:55.58 |
| | too | 21:56.01 |
| tor8 | -DNOCJKFONT to the rescue! ;) | 21:56.34 |
| | it's a shame that darwin doesn't support .incbin | 21:56.46 |
| malc_ | tor8: also i think i've fixed the lockup on selection you've seen on windows, so http://boblycat.org/~malc/llpp.zip if you want ;) | 21:56.58 |
| | tor8: (for that matter) as i mentioned in the recent bugreport clang doesn't support it anywhere | 21:57.16 |
| tor8 | odd. new version of clang? | 21:57.32 |
| malc_ | tor8: 3.0 or something | 21:57.39 |
| tor8 | because I do build with clang 2.7 or so where it does work | 21:57.47 |
| malc_ | i just used it to test who will compile my stuff + prereqs faster | 21:58.00 |
| | tor8: they have switched to integrated assembler | 21:58.11 |
| | that's probably the reason | 21:58.17 |
| | anyhow, i don't really care, as long as stuff works here on ppc/linux/gcc - not my problem | 21:58.49 |
| tor8 | clang 3.0 on osx 10.6 works fine | 21:59.02 |
| malc_ | tor8: notice how genfont only does incbin for __linux__ and __FreeBSD__ though | 21:59.28 |
| tor8 | ah! | 21:59.40 |
| | right you are. | 21:59.41 |
| | clang 1.1 (Debian 2.7-3) also works ;) | 21:59.57 |
| | egads, that's ancient | 22:00.05 |
| malc_ | heh | 22:00.23 |
| | i think that make should really use objcopy on platforms that are capable to do that, but yeah that will take a few (tens?) of minutes to add, and some more to test.. but 10 bloody minutes (and i have no clue whether Darwin has objcopy or whether it supports doing this stuff for Mach-O | 22:02.09 |
| | ) | 22:02.14 |
| tor8 | nope. no objcopy for non-elf platforms last I looked. | 22:02.34 |
| malc_ | computing on non gnu supported platforms blows goats | 22:02.59 |
| Robin_Watts | and not in a good way. | 22:03.48 |
| malc_ | there's a good way? | 22:08.38 |
| Robin_Watts | tor8: OK, I've abandoned the internal context. | 22:15.26 |
| | I'll test mudraw tomorrow and commit that. | 22:15.41 |
| tor8 | cool! | 22:15.50 |
| | same options and behavior (and convoluted control flow) as mupdfdraw? | 22:16.14 |
| sebras | Robin_Watts malc_: stay away from my avatar... http://goo.gl/iLiR6 | 22:19.03 |
| malc_ | :) | 22:20.37 |
| Robin_Watts | tor8: It is mupdfdraw, just using fz_document :) | 22:25.49 |
| | Forward 1 day (to 2012/02/14)>>> | |
IRC Logs