| | <<<Back 1 day (to 2012/10/19) | 2012/10/20 |
| Ch3rryC0ke | Hey there-- I'm wondering if folks have had success builiding mupdf for ARM through the Visual Studio projects? | 00:20.29 |
| | I'm trying to build libmupdf for Win8 on ARM (WinRT).. and running into some issues. | 00:22.28 |
| Hausas | Are you guys mIRC scripters? | 01:30.51 |
| Robin_Watts | Hausas: No. | 09:21.57 |
| sebras | Robin_Watts: robin/pg_android and robin/header-split look like they're redundant nowadays... | 13:42.13 |
| | the same is of course true fro paul/pg_android, and most probably paul/forms-api... | 13:42.55 |
| Robin_Watts | sebras: yeah. I should probably clean those up at some point. | 13:43.11 |
| sebras | oh, and paul/sumatra is probably not a good idea to keep around... | 13:43.28 |
| | Robin_Watts: btw, I have a local branch where I made a first stab at having pdfshow pretty print the hints stream. | 13:44.28 |
| | do you think being able to do so would be valuable? | 13:44.48 |
| | I'm not sure whether to throw it or keep it atm. | 13:45.06 |
| Robin_Watts | Can't hurt. | 13:46.06 |
| | I mean, it can't hurt to keep it. | 13:46.14 |
| | I am unaware of any other tools that even attempt to read the hint stream, so to have something that dumps it sounds worthwhile to me. | 13:46.38 |
| sebras | Robin_Watts: alright, maybe I should polish it and put it on sebras/master proper. | 13:48.15 |
| | thanks for merging my patches btw. | 13:48.22 |
| | Robin_Watts: scummvm!? | 13:50.13 |
| Robin_Watts | mmm? | 13:51.36 |
| sebras | news to me. :) | 13:51.57 |
| Robin_Watts | I did some stuff for the ARM ports of it a while ago (optimised scalers, costume plotters, sound code etc) | 13:52.19 |
| | No structural stuff, so I can't take credit for supporting new games etc. | 13:53.15 |
| sebras | right. | 13:54.04 |
| | tor8: I see why we can't parse the ioccc hamano entries generated pdfs now. | 17:36.37 |
| | there is no space between the beginning of comments and the first digit of the object number. hence we interpret /*1 as the name '*1' and not as '/*' being bogus characters and 1 being an int. | 17:37.43 |
| ray_laptop | Robin_Watts: I re-opened bug 693166. The clist based image interpolation is definitely a big performance hit, but I don't understand why it's so bad | 18:21.50 |
| Robin_Watts | ray_laptop: Just reviewing the bug now. | 18:23.11 |
| ray_laptop | we can interpolate the entire images (at parse time) in 3.7 seconds, and the images are contained in only 23 bands, but it takes us 159 seconds to render in clist mode. | 18:23.38 |
| Robin_Watts | ok, but each image crosses several of those 23 bands. | 18:24.31 |
| ray_laptop | even rendering/interpolating the entire image 23 times would only be 85 seconds ! | 18:24.31 |
| Robin_Watts | Or is a single image that crosses 23 bands ? | 18:24.45 |
| ray_laptop | Robin_Watts: it is several 256x256 images that get painted onto the area | 18:25.24 |
| Robin_Watts | OK. I'll look into it on monday. | 18:26.14 |
| ray_laptop | Robin_Watts: yeah, that's fine. As far as the customer is concerned, the patch should take care of them. | 18:29.06 |
| | holy cow. I think I see the problem. This customer's file is scaling up a LOT (by 266 in x 1150 in y), so we are calling 'image_render_interpolate' 46,260 times and generating 5,071,226 LINES of interpolated data (with 115 bands). With 57 bands, we only call image_render_interpolate 28.786 times and generate 2,603,385 lines of interpolated data. Interpolating during the parse phase has... | 21:37.44 |
| | ...13,220 calls and generates 622,130 lines | 21:37.46 |
| | so the 'support' is adding resulting in roughly 250 extra 'support' lines per band for the page (among the various images) | 21:37.53 |
| | extrapolating to the 1000 bands with the default BufferSpace I would guess that on my laptop, it would take 15 minutes. I may have given up and killed the job right before it finished. I'll try it on peeves | 21:44.27 |
| | wow. My laptop ran the job in 159 seconds with 32m buffer. It takes 278 seconds on peeves. I'll have to check on the 1000 band job later... | 22:01.05 |
| | BTW, the comment above about the images only being in 23 bands isn't correct. With the extensive scaling the images are covering the whole page -- it's just the visible portion that is in 23/115 bands | 22:27.49 |
| | Forward 1 day (to 2012/10/21)>>> | |
IRC Logs