| | <<<Back 1 day (to 2016/04/10) | 20160411 |
| eypeon | Hey everyone | 00:20.08 |
| sebras | tor8: remember the gif cleanup you asked me to do? there's a patch over at sebras/msater | 10:23.13 |
| | kens: msater? you can have your keyboard back now. ;) | 10:23.42 |
| kens | :-) | 10:25.26 |
| | Reminds me, I still haven't ordered a new one yet | 10:25.36 |
| tor8 | speaking of keyboards, did you order a new one yet, kens? | 10:25.41 |
| kens | LOL ^^ | 10:27.15 |
| tor8 | kens: http://www.keyboardco.com/keyboard/realforce-88ub-45g-key-black-on-black-mini-keyboards.asp that's what you should get, IMO. never mind the sticker shock ;) | 10:27.57 |
| sebras | kens: tor8 convinced me to buy a topre realforce 104ub. I'm not a tenkeyless person. | 10:31.58 |
| | kens: but the keys feel excellent. expensive, but well worth it imho. | 10:32.31 |
| kens | I'd prefer a ergonomic one | 10:32.38 |
| | and I do use numeric keypads | 10:32.57 |
| sebras | kens: ergonomic as in http://www.kinesis-ergo.com/shop/advantage-for-pc-mac/ or as in microsofts natural keyboard? | 10:34.23 |
| kens | Like the old MS or Apple one | 10:34.46 |
| | I don't like the *really* weird shaped ones | 10:35.19 |
| | I'll probably go for this | 10:36.10 |
| | http://www.keyboardco.com/keyboard/ergo-pro-quiet-pc-ergonomic-keyboards.asp | 10:36.10 |
| | Which I htnk tor sugeested before. No numeric kepad which is a shame, but I can live without it | 10:36.29 |
| sebras | kens: that seems like it would fit you needs well. I'd go bananas over the pipe, compose and return keys. :) | 10:39.36 |
| tor8 | kens: I've tried ergonomic split keyboards and never liked them. | 11:04.23 |
| | kens: the realforce does come in light colors and with a numpad, but only in US layout | 11:04.38 |
| kens | I used the original Apple one, and then several MS ones for years, until they collapsed.... | 11:04.53 |
| tor8 | the realforces are built like tanks. I got mine 7 years ago, and it's still like new. | 11:05.04 |
| kens | I think I type hard, I wear keyboards out quite fast | 11:05.42 |
| tor8 | kens: that's why I recommended the realforce :) | 11:05.56 |
| kens | :-) | 11:06.02 |
| tor8 | it's also not as noisy as other mechanical keyboards by half | 11:06.37 |
| sebras | kens: the realforce keyboards are heavy so you won't push the keyboard around too much on your desk. | 11:07.06 |
| kens | I do't find that a problem on the whole | 11:07.26 |
| sebras | tor8: why are people even into these noisy mechanical switches? | 11:07.51 |
| tor8 | http://xahlee.info/kbd/uTRON_keyboard.html hah, someone has actually made a split keyboard with topre switchs | 11:08.37 |
| | but I believe that one falls foul of the "not weird" requirement | 11:09.04 |
| sebras | tor8: but what have they done to tab and enter?! | 11:09.10 |
| kens | I find its not so much the split as the angle, I don't thnk I'd like that one | 11:09.14 |
| tor8 | sebras: moved it away from the weak pinky finger... | 11:09.51 |
| Robin_Watts | But no function keys. wtf? | 11:10.07 |
| sebras | Robin_Watts: Fn + nbr? | 11:10.22 |
| tor8 | used to use a happy hacking keyboard... | 11:10.27 |
| Robin_Watts | sebras: Yeah, but, why? | 11:10.39 |
| sebras | Robin_Watts: twentykeyless? | 11:11.03 |
| | Robin_Watts: but yeah, I don't get it either. :) | 11:11.28 |
| tor8 | but I've come to like the arrow and home/end cluster and function keys... but I will never have a numpad again. not unless I start going lefty with the mouse. | 11:11.34 |
| | why hasn't someone taken the logical step to put the numpad on the left on a keyboard? | 11:12.24 |
| sebras | http://www.dsi-keyboards.com/shop/brands/dsi-left-handed-usb-keyboard-with-cherry-mechanical-red-key-switches-new/ | 11:13.19 |
| tor8 | sebras: that one's just as bad, but in reverse. the arrow keys are *also* on the left. | 11:13.58 |
| sebras | tor8: time to geek out over at geekhack.org again. | 11:14.52 |
| | tor8: I'm rendering a bmp-file with some alpha in it. | 11:41.48 |
| | tor8: any areas fully opaque I ignore (I set alpha == 0). | 11:42.09 |
| | tor8: so in the first image I set alpha to 255 for all these half opaque pixels. then I can se the colors that each pixel really have. | 11:43.24 |
| Robin_Watts | half-opaque? | 11:44.07 |
| sebras | but as soon as I set the alpha from the file (or even a fake one) they all turn gray. | 11:44.07 |
| Robin_Watts | gif is 0-1 alpha, right? | 11:44.22 |
| sebras | Robin_Watts: half-transparen? :) | 11:44.25 |
| | Robin_Watts: this is bmp. | 11:44.28 |
| Robin_Watts | Oh, ok. | 11:44.32 |
| sebras | Robin_Watts: but for gif you're completely right. | 11:44.43 |
| Robin_Watts | So, in a bmp, are the values premultiplied or not ? | 11:44.46 |
| | i.e. is it (r,g,b,a) or (r*a,g*a,b*a,a) ? | 11:45.23 |
| sebras | Robin_Watts: I have no idea. | 11:45.55 |
| | Robin_Watts: I'm assuming it is r,g,b,a right now. | 11:46.25 |
| Robin_Watts | What should the actual bmp look like? | 11:47.21 |
| tor8 | sebras: so what's the problem? | 11:47.47 |
| sebras | tor8: the problem is that that I see this thin cyan line outlining the pixels when rendered in 96 dpi but not in 72 dpi! | 11:48.46 |
| | tor8: is this some kind of sampling phenomenon? | 11:49.11 |
| tor8 | sebras: odd colored outlines is a common artefact of not premultiplying alpha | 11:49.15 |
| | if, in the fz_pixmap, r, g, or b > a then you've got problems | 11:49.36 |
| sebras | tor8: that is indeed true. | 11:49.51 |
| | tor8: so that means i need to multiply each color channel with the alpha channel before storing the sample in the pixmap? | 11:50.10 |
| tor8 | sebras: fz_premultiply_pixmap like you do for gif (and we do for tiff, and png) | 11:50.15 |
| | sebras: ah, didn't see your private message. yes, that looks like non-premultiplied alpha blended as if it were premultiplied | 11:51.33 |
| sebras | tor8: how come I only saw these outlines for 96 dpi and not fo r72 dpi? | 11:51.37 |
| tor8 | sebras: because you only see the certain of the artefacts when you interpolate between the transparent and non-transparent areas | 11:52.29 |
| sebras | tor8: ok, I fixed your comments and theres another one for you to review at sebras/msater | 12:04.29 |
| | tor8: premultiplying did indeed work. | 12:04.56 |
| Robin_Watts | tor8: OK, so commits on robin/master that do the partial bitmap decode. | 12:26.39 |
| | I'm running a new test/bmpcmp now to fix the one problem I could see in the bmpcmps from before. | 12:27.19 |
| | At the moment we only match exact matches in the cache. | 12:28.13 |
| | We have no mechanism for matching a subrectangle of an existing image. | 12:28.51 |
| | And when banding, we'll redecode the image for each band. But that's exactly what gs does. | 12:31.42 |
| chrisl | What do you mean by "decode"? | 12:33.02 |
| Robin_Watts | chrisl: JPEG decode. | 12:34.09 |
| | or flate decode etc. | 12:34.13 |
| chrisl | Well, no GS doesn't do that - the device API (and thus the clist) never sees the original data stream | 12:34.38 |
| Robin_Watts | Yeah, gs decodes at clist writing time, and (AIUI) splits the bitmap data into what is required for each band. | 12:36.30 |
| | I'm not sure if it does that splitting by repeatedly redecoding or not. | 12:36.55 |
| Robin_Watts | foods. | 12:37.16 |
| chrisl | No, you can't repeatedly decode a PS stream - it's a stream | 12:37.30 |
| | I don't know how (and to what extent) it splits the data when doing high level images - or how that interacts with high level images in the clist | 12:39.44 |
| Robin_Watts | back. | 13:40.38 |
| | The clist writer is a device, so it must get called with a gs_bitmap I guess. | 13:41.08 |
| | i.e. the stream must have been decoded. | 13:41.18 |
| | So either the full bitmap gets put into the clist, or sections must be extracted from it and put into the clist. | 13:41.52 |
| chrisl | There is also an "all bands thing" which I'm not sure how it/if works | 13:42.34 |
| Robin_Watts | chrisl: Stuff in the clist can either be put into a single band, or 'all bands'. | 13:43.03 |
| | the page clear is an "all band" thing, for instance. | 13:43.12 |
| | So, with my current changes, we do better than gs in terms of memory (in that we never (for banded stuff) decode the whole image). | 13:44.14 |
| | Hmm. Let me rephrase. | 13:44.37 |
| | So, with my current changes, we do better than gs in terms of memory (in that we never (for banded stuff) hold the whole decoded image in memory at once). | 13:45.00 |
| | But we do decode the image multiple times. | 13:45.17 |
| | which is worse than gs. | 13:45.32 |
| chrisl | It doesn't really matter in this context: there isn't a "right" approach to this, I just didn't want someone to take away the wrong impression of how gs/clist worked for images (ahem - badly, IMHO!) | 13:46.02 |
| | Anyway, I gotta head out for a bit..... | 13:46.29 |
| Robin_Watts | chrisl: Talking about this stuff may point to flaws (or limitations) in the way I'm working, so it is appreciated. | 13:46.38 |
| sebras | Robin_Watts: I think I might have found a bug relating to annotations in 1.9rc1 for android. | 14:13.09 |
| | Robin_Watts: have you also been involved in this, or was it just tor8 and fred? | 14:13.36 |
| Robin_Watts | So, for a random file with a picture in it, at 200dpi, it takes 55Meg peak. When banded at 100 pixels, it takes 8.4 | 14:13.45 |
| | I don't think I've changed anything there, but go on... | 14:14.06 |
| sebras | Robin_Watts: when I edit annotations, e.g. stroke annotation, I draw something and I can see the red stroke. | 14:15.13 |
| | Robin_Watts: then I click on the checkmark | 14:15.18 |
| | Robin_Watts: and the red stroke disappears. Then I click on X twice and then back and I'm asked to save the file (at this point I still do not see any red stroke) | 14:16.05 |
| | Robin_Watts: I then select the file from the filemanager and reopen and the red stroke is now shown. | 14:16.23 |
| | Robin_Watts: looks like we are not refreshing the screen correctly somewher. | 14:16.38 |
| Robin_Watts | sebras: Try it on a file with at least 3 pages. | 14:17.01 |
| | add the annotation to page 1, flip forward 2 pages, then back 2 pages, does it appear? | 14:17.15 |
| sebras | Robin_Watts: this one has 25 pages. | 14:17.19 |
| Robin_Watts | I see the same problem here. | 14:17.44 |
| | if I flip forward 2 pages, it drops out of cache, then I flip back and the annotation appears. | 14:18.03 |
| sebras | exactly. | 14:18.13 |
| Robin_Watts | So, yes, I think your analysis is correct. | 14:18.15 |
| | I'm gonna leave that one until tor8/fred are about. | 14:19.55 |
| | I've got a couple of leaks to look at while we wait for them to arrive. | 14:20.23 |
| tor8 | Robin_Watts: sebras: I have no clue. If I've changed the annotation code, it's purely by accident. | 14:24.45 |
| Robin_Watts | tor8: It sounds like an android specific thing to me. | 14:25.07 |
| jogux | I was going to check that on iOS (as I was looking at mupdf for something else) but seems the iOS build is broken on golden master. | 14:53.28 |
| | for some reason "error: expected 'while' in do/while loop" is amusing me. | 14:53.57 |
| rayjj | I saw discussion earlier about gs image handling to clist. For the record, gs decodes the image only once, and (normally) stores the data in the clist in "high level" mode, which means as source pixel data, uncompressed | 14:54.12 |
| | The data is stored in the bands where it will be needed, which means that extra data from above and below the band is included in the data for the band | 14:55.06 |
| jogux | ah, that error is caused by errant semicolons in the objective C. | 14:55.07 |
| rayjj | And if the image is skewed, the extra data is larger since we store full "lines" of data (not just the data that would be needed for a skewed image) | 14:56.53 |
| HenryStiles | jogux: I think fred is going to handle the ios mupdf release so I'll bug him Tuesday if you don't bring it up. | 14:57.29 |
| rayjj | so we "punt" if the image is skewed by too much and revert to storing pixel runs as rectangles | 14:57.37 |
| mvrhel_laptop | rayjj: thanks for following up on that. That was what I thought happened | 14:57.51 |
| jogux | HenryStiles: Yeah, I'm sure he's fixed some of this, it's probably just not made it to golden yet. | 14:58.09 |
| Robin_Watts | rayjj: Yeah, so gs decodes the entire image to a bitmap at native size before the clist writer is called. | 14:58.44 |
| rayjj | mvrhel_laptop: Just figured more info couldn't hurt. Also for landscape images we split the data by bands | 14:59.03 |
| Robin_Watts | In MuPDF, with my prototype code, we now never need to hold more of an image decoded than is required for a single band. | 15:00.00 |
| rayjj | Robin_Watts: not exactly, it processes images line by line | 15:00.01 |
| Robin_Watts | devices get called with a gs_bitmap don't they? | 15:00.25 |
| rayjj | Robin_Watts: no, images come out of the clist as image_data calls (which is how they went in) | 15:01.00 |
| | gs only uses bitmaps for tiles (pattern cells) and characters | 15:01.50 |
| | and the MaxPatternBitmap limits how big a pattern cell can be | 15:02.25 |
| Robin_Watts | Oh, right. begin_image/image_data/image_end. I'd entirely forgotten that (if I ever knew it) | 15:02.50 |
| rayjj | Robin_Watts: actually, begin_typed_image, but yeah | 15:03.09 |
| Robin_Watts | So the clist writer gets given data line by line. | 15:03.53 |
| rayjj | We've discussed having gs pass the source data (i.e., before decoding) which would help pdfwrite and other high level devices cope with JPEG better | 15:04.20 |
| mvrhel_laptop | right. I remember that | 15:04.32 |
| Robin_Watts | Suppose we have a 200 line image that covers 2 bands. Lines 0-105 are needed for band 0, and lines 95-200 are needed for band 1. | 15:04.44 |
| rayjj | and I have a concept for storing image | 15:04.46 |
| kens | Its on my list of enhancements | 15:04.48 |
| Robin_Watts | 95-199,even. | 15:05.00 |
| rayjj | storing image as seekable objects in the clist | 15:05.09 |
| Robin_Watts | How does the clist handle that? | 15:05.13 |
| | Oh, it serialises the image_data calls and just labels the right subset of the calls for each band ? | 15:05.52 |
| rayjj | if the clist stored image data, in theory, it coud store JPEG data, then extract/decode the blocks it needs for a band | 15:06.07 |
| | Robin_Watts: I didn't understand "how does the clist handle that?" | 15:06.41 |
| | handle what? | 15:06.48 |
| | the 200 line image ? | 15:07.18 |
| Robin_Watts | The clist writer is called with begin_typed_image (telling it it's a 200 line image, with appropriate scale factors), then 200 calls to image_data, then an image_end, right? | 15:07.26 |
| rayjj | that's what the clist writer is called with, yes | 15:07.46 |
| Robin_Watts | So (AIUI) it puts a 'begin_typed_image' call into every band that needs it (with the images appropriately cut down for the band). | 15:08.12 |
| rayjj | and it puts the image_data into the appropriate bands, including "support" data | 15:08.15 |
| Robin_Watts | Right. | 15:08.24 |
| rayjj | Robin_Watts: yes, the begin_image goes into every band that is touched by the image | 15:09.06 |
| Robin_Watts | And the bands that share lines (because of the support) share the underlying entries, right? (The 'c' entries point to the same 'b' entries?) | 15:09.12 |
| | The *same* begin_image goes into every band? Or a modified one? | 15:09.47 |
| rayjj | Robin_Watts: no, the data that is used by more than one band is written in each band (so the clist grows) | 15:10.01 |
| Robin_Watts | ok, but gs is still doing a good job in terms of memory and compute use. Where it loses out is in the ability to regenerate the original. | 15:13.00 |
| | MuPDF doesn't pass bitmap data across the device interface. | 15:13.11 |
| | We pass 'fz_image' objects. Where an fz_image object is something you can ask for a pixmap from (or the source data) | 15:13.57 |
| rayjj | Robin_Watts: so the fz_image object has the entire image source data? | 15:14.49 |
| Robin_Watts | My latest change is to have it so that you can ask for a pixmap of a particular subarea, and to make the draw device be smart enough to just request the bits it needs. | 15:14.49 |
| | rayjj: yes. | 15:14.56 |
| rayjj | Robin_Watts: but in the original form (i.e, compressed) ? | 15:15.26 |
| Robin_Watts | Yes, unless the compressed form is larger than the uncompressed form. | 15:15.40 |
| rayjj | Robin_Watts: I assume that it does filter any "ASCII85" or ASCIIHex" out and stores binary, right ? | 15:16.52 |
| Robin_Watts | Indeed. | 15:17.01 |
| | so stuff will either be raw binary, or flate or dctd or jbig2 or ccitfax or... | 15:17.49 |
| rayjj | Robin_Watts: I haven't looked at your new code, but does the code that pulls an area from the pixmap utilize the "blocks" of JPEG ? | 15:18.24 |
| Robin_Watts | No. | 15:18.37 |
| rayjj | oh, :-( | 15:18.52 |
| Robin_Watts | It calls the usual stream decoders and just skips the data outside the range we are interested in. | 15:19.17 |
| rayjj | Robin_Watts: is this only in the LOW MEMORY mode ? | 15:19.40 |
| Robin_Watts | I dunno how familiar you are with JPEG compression, but it would not be easy to make use of the blocks of JPEG. | 15:20.15 |
| | (in general) | 15:20.19 |
| rayjj | Robin_Watts: right, that's what I was thinking | 15:20.30 |
| Robin_Watts | (JPEGs have optional restart intervals, but no one uses them). | 15:20.46 |
| kens | JPEG2000 can have tiles though | 15:21.04 |
| Robin_Watts | The prototype code I have, uses it everywhere. | 15:21.10 |
| kens | I'm not suggesting you try to use them.... | 15:21.16 |
| rayjj | and one _could_ store ccittG4 with a line prefix to make that faster to skip unwanted data | 15:21.26 |
| Robin_Watts | kens: JPEG2000 always decodes the full thing though, cos of the way the decoder works. | 15:21.28 |
| | rayjj: Yes, there is scope for all sorts of improvements. | 15:21.43 |
| kens | Robin_Watts : just saying :) | 15:21.54 |
| Robin_Watts | At the moment, the (uncommitted) code I have just naively decodes the whole image, and keeps the required bits. | 15:22.33 |
| | The decoded images go into the cache, so if we repeatedly render the same page, it'll find the pixmaps and reuse them. | 15:23.02 |
| rayjj | Robin_Watts: actually, I guess using the same code everywhere is not bad. It really only impacts banded mode, and you were decoding the image anyway for every band | 15:23.16 |
| Robin_Watts | but it's NOT smart enough currently to spot that we just need a subsection of a pixmap we've already got and use that. | 15:23.40 |
| | rayjj: Sadly, no :( | 15:23.48 |
| | In the current code, we'd decode the WHOLE pixmap, and use that. | 15:24.06 |
| | and then each band would find that same pixmap in the cache, and work from that. | 15:24.23 |
| | So (memory permitting) we'd only decode once. | 15:24.42 |
| rayjj | Robin_Watts: right, each band currently decodes the entire image. Your improvement just never stores more than a band needs, right ? | 15:24.49 |
| Robin_Watts | but memory not-permitting it'd die ) | 15:25.08 |
| | rayjj: Yes. | 15:25.18 |
| | rayjj: Well, hold on... | 15:25.32 |
| | "each band currently decodes the entire image" | 15:25.42 |
| | Better to say "each band currently requests a the entire image decoded, but all but the first band might get it from the cache, so not have to do any work" | 15:26.22 |
| | So my new code could definitely be slower than the current code. | 15:26.44 |
| rayjj | Robin_Watts: oh, I mis-read. the image is decoded and stored once currently, and then bands work from that decoded store | 15:27.09 |
| Robin_Watts | rayjj: Yes. | 15:27.20 |
| | The problem being that that image can be <trump>YUUUUUUGE</trump> | 15:27.40 |
| rayjj | so the improvement will decode bands more than once since each band only requests what it needs | 15:28.24 |
| Robin_Watts | rayjj: The improvement will decode once per band, yes. | 15:28.46 |
| | We get knock on benefits though, in that when we're calling the scalers, we'll be scaling a smaller image. | 15:30.52 |
| | Decoders can 'subsample' an image by factors of 2 - those can be cached. The draw device then mitchell scales images to the exact size required - those are never cached, and currently require the complete image to be scaled even if only part of it is painted. | 15:32.32 |
| | (though we only mitchell scale downwards, currently) | 15:33.05 |
| | Possibly we need a way for callers to set the heuristics used here. | 15:35.53 |
| | so a caller can choose when an image should be decoded in it's entirety, and when it should be banded. | 15:36.50 |
| | cos the tradeoffs are different for a viewing app on a desktop computer and for a low memory printer. | 15:37.10 |
| rayjj | Robin_Watts: is the fz_pixmap in the display list always the source data? Is there and option for z | 15:53.01 |
| | darn. keep hitting <enter> | 15:53.15 |
| Robin_Watts | The displaylist doesn't have an fz_pixmap. | 15:53.46 |
| | The displaylist has an fz_image. | 15:53.58 |
| rayjj | Robin_Watts: what is in the fz_image ? | 15:54.09 |
| Robin_Watts | The fz_image is the thing that you can request a decoded pixmap from, OR the original source data. | 15:54.30 |
| | So it's an object that holds the compressed data effectively. | 15:54.56 |
| | Unlike the gs displaylist we don't allow serialisation to file. | 15:55.12 |
| rayjj | so, if you get the original source data from the display list, is it copied? | 15:55.31 |
| Robin_Watts | No. fz_images are reference counted. | 15:55.43 |
| | Oh, wait... possibly if you ask for the original source data it's copied. I can't remember offhand. | 15:56.16 |
| | That's not something that happens much (happens for pdfwrite etc) | 15:56.28 |
| rayjj | Robin_Watts: OK, so if you request the original data, you will just get a pointer to the same data (with it's rc taking that into account) ? | 15:56.46 |
| Robin_Watts | rayjj: OK, I've just checked the code rather than relying on my memory. | 15:57.57 |
| rayjj | if not, when rendering the display list, to a band you would have the source compressed data in memory TWICE (once in the fz_image and once in the fx_pixmap) | 15:58.09 |
| Robin_Watts | Each fz_image has an fz_compressed_buffer * in it, and you currently just look into it and read that. Should wrap that more nicely. | 15:58.44 |
| | rayjj: Urm... no. | 15:58.50 |
| | The displaylist contains an fz_image * :) | 15:59.07 |
| rayjj | I thought you need a fz_pixmap to extract from. how do you get the fz_pixmap from the fz_image ? | 15:59.56 |
| Robin_Watts | When you render a display list, we end up holding 1) the compressed data (within the fz_image), 2) the uncompressed data (in the pixmap), and possibly 3) a scaled version of the pixmap. | 16:00.15 |
| | rayjj: 'extract from' ? You mean "extract the actual area we need for this band from" ? | 16:00.51 |
| rayjj | Robin_Watts: so the fz_image -> fz_pixmap is where you specify a subarea ? | 16:01.19 |
| Robin_Watts | Yes. | 16:01.22 |
| rayjj | OK, I misunderstood. The pixmap is always the decoded (uncompressed) data | 16:02.05 |
| | ? | 16:02.10 |
| Robin_Watts | Yes. | 16:02.14 |
| | pixmaps are basically just width/heigh/res + array of 8bpc uncompressed component values. | 16:02.57 |
| rayjj | Robin_Watts: so you (usually) will have the pixmap for an image area that is for a band AND an image that is scaled to the device res? | 16:04.02 |
| Robin_Watts | rayjj: Yes. | 16:04.27 |
| | To avoid that, we'd have to rewrite the scalers/plotters to work on a line by line basis. | 16:05.04 |
| rayjj | Robin_Watts: so the scaling operation can't go into the band buffer, but needs it's own copy ? | 16:05.06 |
| Robin_Watts | rayjj: We do not scale and plot at the same time, no. | 16:05.33 |
| | We *could* do that, but at the cost of a more complicated render pipeline. | 16:06.36 |
| rayjj | Robin_Watts: I guess when using AA, you need that | 16:06.50 |
| Robin_Watts | The lowest level plotter (or "painter") takes a pixmap and does an affine texture map of that into the output pixmap. | 16:07.41 |
| | So all our image plotting goes through that. | 16:08.05 |
| rayjj | everything is simpler without AA, but you'd need the line stride for the scaled output | 16:08.09 |
| | Oh, that's where the rotation gets done | 16:08.49 |
| Robin_Watts | If our source pixmap is higher res than we need, then we take the pixmap and mitchell scale it to a new pixmap that's 1:1 with the output. | 16:09.12 |
| | Then feed that into the usual plotter. | 16:09.30 |
| | So yes, the last plotter is always responsible for rotations etc. | 16:09.45 |
| | I don't think it's practical to mitchell scale and paint all in 1 hit for rotated things. | 16:12.45 |
| | We could have a special case for the 1:1 scale and paint (except that's not really a single case, there are 8 orthogonal cases) | 16:14.27 |
| | and the worst case memory usage wouldn't improve, so I'm not too fussed about that. | 16:15.09 |
| rayjj | since you need the scaled pixmap, you could go from the fz_image to the scaled sub-area and at least skip the unscaled, uncompressed sub-area pixmap | 16:17.03 |
| Robin_Watts | The scaler goes from an fz_pixmap -> fz_pixmap | 16:17.39 |
| | And each decoder goes from raw data -> fz_pixmap. | 16:18.09 |
| rayjj | Robin_Watts: but that's less of a change than going to line-by-line mode | 16:18.14 |
| Robin_Watts | And there is a fz_pixmap -> fz_pixmap subsample step in there too. | 16:18.28 |
| rayjj | Robin_Watts: sub-sample is for what ? | 16:18.51 |
| Robin_Watts | rayjj: Suppose you have a PDF with a 1600x1200 JPEG image in, and you're viewing it on a 320x240 pixel screen. | 16:19.27 |
| | There is no point in decoding that whole image. | 16:19.38 |
| | So we decode a subsampled version. | 16:19.46 |
| | subsampled = power of 2 decimated, in this context. | 16:20.02 |
| rayjj | Robin_Watts: so a simple case of scaling | 16:20.29 |
| Robin_Watts | So in general when we need an image, we look to see what the largest power of 2 we can decimate it by is, such that it's still larger than we need. | 16:20.45 |
| | That cuts the memory use down considerably, and for some formats (i.e. JPEG) we can get the decoder to do that subsampling for us. | 16:21.19 |
| | instead of doing an 8x8 DCT we can do a 4x4 or a 2x2 etc. | 16:21.34 |
| | And we cache that result (cos for a viewer, we really don't want to redecode on every small zoom) | 16:22.04 |
| rayjj | Robin_Watts: does the sub-sampling take all of the source pixels into account ? | 16:22.05 |
| Robin_Watts | rayjj: We have 2 types of subsampling; the first is done in the decoder (JPEG being the only one that can work like that), the second is done in the image decoder 'core' (i.e. the bit that calls the decoders). | 16:23.13 |
| rayjj | (when it's not DCT) | 16:23.15 |
| Robin_Watts | The JPEG stuff works as you'd expect (no weird dropouts). | 16:23.44 |
| | The second layer of stuff averages (box filter, whatever you want to call it). So all pixels matter. | 16:24.15 |
| rayjj | Robin_Watts: OK, and the sub-sampled image for CCITT in will be gray ? | 16:24.54 |
| Robin_Watts | It will. | 16:25.02 |
| | rayjj: We could in theory have a 'special' subsampler', but... ew. | 16:25.38 |
| rayjj | so pixmaps will never be 1-bit ? | 16:25.45 |
| Robin_Watts | pixmaps are always 8bpc. | 16:25.56 |
| rayjj | OK. | 16:26.01 |
| Robin_Watts | We have talked about the idea of having 1bpp bitmaps, but that's a whole new kettle of monkeys. | 16:26.58 |
| | Need new scalers/painters to go with that. | 16:27.10 |
| rayjj | Robin_Watts: thinking about printers, the printer res will usually be higher res than the data coming in. The exception will be PDF's that came from scanners | 16:27.45 |
| mvrhel_laptop | bbiab | 16:27.51 |
| Robin_Watts | rayjj: So we don't scale (or subsample) in those cases, by default. | 16:28.27 |
| | tor8, sebras, rayjj: I am intrigued by the idea of having a new entry in our lib context, an entry for "heuristics". | 16:29.05 |
| | It would be a list of function pointers, that would all be NULL by default. | 16:29.28 |
| rayjj | heuristics to guide what ? | 16:29.48 |
| Robin_Watts | The caller can then implement any of them that they want. | 16:29.50 |
| | The first example would be that when we go to decode an image we'd call heuristics->image_decode(src_width, src_height, subarea, l2factor) | 16:31.08 |
| | and the heuristic can alter subarea based on whether it would rather we decoded the whole image or just the subarea. | 16:31.59 |
| | So a low memory printer would do nothing. | 16:32.16 |
| | A desktop viewer could say "always decode the whole image" because memory is not a problem. | 16:32.48 |
| rayjj | Robin_Watts: so, you could have a image_decode_scale optional function ? | 16:33.59 |
| | rather than just the l2factor (which I assumed was the subsample power of 2) | 16:34.47 |
| Robin_Watts | rayjj: Yes, the decision as to when we should mitchell scale or not could be offloaded to the caller or not. | 16:34.56 |
| sebras | Robin_Watts: what would the subarea be restricted to in the low memory sceario? the viewport? | 16:35.10 |
| Robin_Watts | sebras: On entry to the call it would be set to the minimum we can get away with. | 16:35.47 |
| rayjj | sebras: I am thinking the part of the area in the band | 16:36.07 |
| Robin_Watts | (which is band size, plus a bit for scaler support, plus rounding to 'block' boundaries) | 16:36.25 |
| | I was reading band == viewport. | 16:36.33 |
| | There are inevitable decisions to be made like "when to mitchell scale", "how much of an image to decompress at once" etc, that will be vary according to environment. | 16:38.52 |
| | and having a mechanism to cheaply pass that out for the integrator to control might be nice. | 16:39.15 |
| | (Should have included fred and mvrhel_laptop in the list of names above as they've probably been our main integrators to date) | 16:40.22 |
| fredross-perry | here. | 17:02.21 |
| Robin_Watts | Sorry/ | 17:05.38 |
| | Right, so sebras spotted a bug in mupdf android 1.9rc1 | 17:05.49 |
| | If you open a pdf file (pick one with > 3 pages). | 17:06.03 |
| fredross-perry | reading... | 17:06.05 |
| Robin_Watts | Then annotate it, by scribbling on it with the ink annotation thing. The red line appears as you'd expect. | 17:06.29 |
| | When you click the 'tick', the line vanishes. | 17:06.40 |
| fredross-perry | I can take a look. | 17:06.48 |
| Robin_Watts | flip forwards 2 pages, flip back, and it appears again. | 17:06.54 |
| | So the caching breaks it. | 17:07.02 |
| fredross-perry | I suspect this is long-standing? | 17:07.21 |
| Robin_Watts | Possibly. | 17:07.28 |
| | Zooming doesn't fix it. | 17:07.35 |
| | Which suggests to me that the display list is not being regenerated until it falls out of cache. | 17:07.52 |
| | Presumably this worked at one stage... | 17:07.59 |
| | Can you think of anything that might have broken this recently? | 17:08.14 |
| | Ah, the displaylist for annotations is a separate beast. | 17:13.17 |
| | And the annotation display list gets dumped whenever we set an annotation. | 17:14.35 |
| fredross-perry | ahh. | 17:16.51 |
| | so we need to re-run the annotations at that time? | 17:17.17 |
| Robin_Watts | yeah, although it looks like we should be doing that. | 17:18.45 |
| | Going to try some debugging. | 17:18.50 |
| | I thought I'd ask in case you had an instant "ah, that'll be..." answer. | 17:19.11 |
| | Thanks. | 17:19.21 |
| fredross-perry | nothing instant, sorry. | 17:20.02 |
| Robin_Watts | I shall just blame <looks for who isn't here> paul. | 17:21.17 |
| | ok, so we're creating the annot. We're ditching the annot list. We're doing a partial update, and that's correctly spotting that the annots_list is NULL, so it's regenerating it. That is spotting that we do now have an annot, and it's running it, but nothing is being put into the display list. | 17:54.14 |
| | which means, I suspect, that it thinks the annotation contents are off screen or something. | 17:54.43 |
| | tor8 made a device change recently that upset various things because annotation matrices were not what was expected. | 17:55.19 |
| | I bet this falls out of that. | 17:55.31 |
| mvrhel_laptop | ok. after the trip to japan and being on vacation for a week I can finally get back to real work. Time to dust off where I was | 18:06.05 |
| | looks like I have a customer bug | 18:07.31 |
| | off for lunch | 19:09.15 |
| rayjj | mvrhel (for the logs): Trying to guess at the colorspace is a problem in general -- I updated bug 696690 with the "gotcha" if the ICCProfle numcompents and N don't match and we pick the wrong one | 20:21.34 |
| | oops. oops. | 20:28.48 |
| tkamppeter | Robin_Watts, hi | 22:44.16 |
| | Forward 1 day (to 2016/04/12)>>> | |
IRC Logs