| | <<<Back 1 day (to 2017/07/20) | 20170721 |
| mvrhel_laptop | Robin_Watts: Another small fix for you on my blend_color branch | 06:22.55 |
| | Could not figure out why the spot colors seemed faded..... | 06:23.18 |
| | Now I see | 06:23.22 |
| | done until morning | 06:23.54 |
| Robin_Watts | tor8: Morning. | 10:36.13 |
| steve | Hello, Sorry if I do something wrong - is my first time | 10:59.03 |
| | Wnat to report, that mupdf mini does not scale to pagefit. I guess the intention is to show hole page at once | 10:59.42 |
| | mupdf mini is a great idea! | 11:00.16 |
| Robin_Watts | Steve: "scale to pagefit" ? | 11:01.58 |
| tor8 | Robin_Watts: steve: is this bug #698227? | 11:43.18 |
| | Robin_Watts: a handful of commits on tor/master for review (up to and including "allow caching of rendered tiles when using the display list") | 11:46.32 |
| | the gettimeofday commit needs testing on windows | 11:46.47 |
| steve | Use it in portrait mode to read a magazine. To come to next page I have to tap once (than page scrolls up) and than a second time for the page turn. Could you fix this please | 12:12.23 |
| | Sorry offline. Yes may be, but not sure | 12:12.35 |
| | bug description is bit different. I use portrait mode. | 12:13.58 |
| tor8 | steve: I'll need the file, and specs of your device so I can debug the issue. | 12:15.07 |
| | screen size | 12:15.12 |
| | steve: oh, I see what you mean. mupdf-mini does fit width, not fit page. | 12:16.55 |
| steve | I have a 9.7" tablet 2048 x 1536 | 12:17.35 |
| | exactly, in portrait mode I have to scroll down | 12:18.13 |
| | I guess the ecpected behaviour would be a page fit - at least this would be my wish. | 12:18.58 |
| tor8 | it's an intended design choice to fit width (since that's more useful on small screens like phones) | 12:19.33 |
| steve | it is not much to scroll down, but it prevents fast page turns ... | 12:19.35 |
| tor8 | if the page aspect ratio is very similar but slightly taller than the screen you get this somewhat less than ideal behavior | 12:20.04 |
| | steve: are you an android developer, or just an end user? | 12:20.19 |
| steve | you nailed it | 12:20.20 |
| | just a user :( | 12:20.31 |
| tor8 | because changing the behavior to be fitPage rather than fitPageWidth is a trivial one line change | 12:20.35 |
| | but if you can't recompile then it'll be more difficult | 12:20.42 |
| steve | in linux I would solve this with a parameter .. ;) | 12:21.07 |
| tor8 | I'll look into adding a choice menu or something to choose between fitPage and fitWidth | 12:21.09 |
| steve | no idea howto do this in android | 12:21.27 |
| tor8 | I can't give you a time frame though | 12:21.31 |
| steve | sure. already happy you see this use case. | 12:22.04 |
| | are you working on standard mupdf too? | 12:22.23 |
| | Testet a lot of viewer, this is far the best! | 12:22.42 |
| tor8 | yes. I am the lead developer, with a lot of help from Robin_Watts and the other folks here | 12:23.10 |
| sebras | tor8: in the tile caching commit maybe 'Do nothing' could be something like 'Skip caching the time, no harm done' or something along those lines? | 12:23.26 |
| tor8 | steve: the non-mini mupdf viewer has fit page by default, and has better zooming, so you could try that as well | 12:23.55 |
| steve | There is one feature I like un another pdf viewer. In this one I can zoom and move the page and lock the setting. This is useful in full page mode to crop the main content. Think about that some document have a lot of empty stuff around the content. | 12:25.07 |
| tor8 | sebras: that's what the comment at the top of the fz_try says :) | 12:25.10 |
| sebras | tor8: I know, but it might be worth repeating, or moving. just a suggestion. | 12:26.13 |
| steve | You might laught, but do you know why I would use both mini and standard? It is because I can easier switch between 2 documents. Assume one is a magazine, and other a book. I just have to open the one or other app ;) | 12:27.14 |
| | hearbeat | 12:34.39 |
| sebras | tor8: in d03076b018a754923a177c30092ead37ae344f6a, how does the id ever get set? maybe this is what happens in 4c9b58f5ff8f2ea622d629f7244971466d069994? | 12:34.42 |
| | tor8: mudraw still uses gettimeofday, should it be converted to fz_current_time() in tht commit? | 12:38.18 |
| | tor8: I'm guessing for memory.c and x11_main.c we can keep gettimeofday as those are special anyway. | 12:38.56 |
| steve | Just say thanks to @tor8, @Robin_Watts and all the other devs! have a nice day | 12:40.32 |
| sebras | tor8: also your change the implementation of gettimeofday in time.c, but this line: | 12:40.59 |
| | return = (t / 10000 - DELTA_EPOCH_IN_MILLISECS); | 12:41.07 |
| | how did that ever compile? | 12:41.11 |
| | previously the function populated tv, but now it doesn't? I'm confused... then again I am still ill. :-/ | 12:41.39 |
| tor8 | steve (for the logs): mupdf-mini allows opening multiple documents, just use the [] window button to switch back to the library view and open another one | 13:00.18 |
| | sebras: in d03076b018a754923a177c30092ead37ae344f6a id is set in the second hunk | 13:03.27 |
| | eh... yeah, that gettimeofday commit isn't ready yet :( | 13:04.18 |
| Robin_Watts | tor8: tile->id one lgtm | 13:13.44 |
| | The WIP epub one looks... WIP. :) | 13:14.41 |
| tor8 | yeah, ignore the last 3 | 13:15.02 |
| Robin_Watts | If that's intended to fix the bug, can we include the bug number in the commit message? :) | 13:15.05 |
| | oh, crumbs, there are loads more I'd missed :) | 13:15.31 |
| tor8 | I suspect it's better to ignore the image dpi, lots of epub images have funky resolutions and end up too big or small | 13:15.42 |
| Robin_Watts | tor8: I suspect you may be right, but we shouldn't be using // | 13:18.44 |
| tor8 | Robin_Watts: yes, it's a WIP commit :) | 13:18.56 |
| Robin_Watts | yeah :) | 13:19.02 |
| | The time one is WIP too? | 13:19.07 |
| | should the windows version of gettimeofday be static maybe? | 13:19.37 |
| tor8 | Robin_Watts: yeah, ignore the time one for now | 13:19.48 |
| Robin_Watts | ok. | 13:19.53 |
| tor8 | I need to rework some things sebras spotted | 13:19.54 |
| Robin_Watts | tor8: for the "only cache tiles once" one... can we change 'cache' to 'try_cache' or 'encache' please? | 13:22.03 |
| tor8 | Robin_Watts: sure | 13:22.13 |
| Robin_Watts | otherwise I would reach 'cache' as meaning "was found in the cache" | 13:22.18 |
| | s/reach/read/ | 13:22.22 |
| | otherwise, other than the ones I've mentioned lgtm. | 13:23.26 |
| tor8 | Robin_Watts: okay, updated commits on tor/master (minus the last 3) | 13:29.17 |
| sebras | tor8: so the id set in fz_list_begin_tile is the pattern obj num from 465bd872121c86d43d365e6308c4bc0a44571928 ? | 14:11.35 |
| | tor8: that means the node flags are now no longer used, is that important? | 14:12.04 |
| tor8 | sebras: the node flags were set to 0 | 14:12.30 |
| | and it has too few bits (only 6 bit wide bitfield) to hold an ID | 14:12.41 |
| | sebras: yes, the pattern ID was intended to be some unique identifier, but I couldn't find anyplace it was setting one! | 14:13.39 |
| sebras | tor8: right, then i see the connection between the patches. | 14:14.12 |
| tor8 | with this set of commits, we now cache pdf pattern tiles, and the interpreter knows to not repeat the pattern definition | 14:14.15 |
| sebras | tor8: the reason I ask about the flags is that they previously affected the id if they were set, but somehow you determined that these flags are _never_ set? | 14:14.48 |
| | tor8: I'm too daft at the moment to make the same determination, rendering me suspicious and hence asking. :) | 14:15.13 |
| | tor8: if I ever clear this cold and fever I might be back to my normal daft self. ;) | 14:15.36 |
| tor8 | if they were set, they were being used wrong. the n.flags were being passed to the 'id' parameter of begin_tile | 14:15.47 |
| | I expect robin somewhere intended to pack the id into the node flags | 14:16.02 |
| sebras | tor8: most likely. would the flags being set affect the rendering of a tile? | 14:16.23 |
| tor8 | they would be used as the cache id of a tile | 14:16.35 |
| sebras | I know, but if the flags are sett one way it might be rendered one way, and if they are set the other way they are rendered they other way. | 14:17.09 |
| | if that is the case, then we now only cache one of the looks of the tile..? | 14:17.22 |
| tor8 | the 'flags' field is a generic field used differently by different display list nodes | 14:17.36 |
| | it has the 'even_odd' field for filling paths, etc | 14:17.45 |
| | when creating a 'begin_tile' display list node, we are setting the flags to 0 | 14:18.05 |
| sebras | ok, how are these concepts connected to tiles though..? | 14:18.11 |
| tor8 | the fz_begin_tile device call starts the definition of a tiling pattern. if we pass a non-zero ID to that function, we're telling it that it may have seen the same pattern definition before. | 14:19.26 |
| | if the device function returns true, then it lets us know that "yes, I have seen this tile before and you don't need to send me the definition again" | 14:19.46 |
| | and depending on that return value, the interpreter either sends the device calls to draw a pattern tile, or skips right ahead to the fz_end_tile device call | 14:20.29 |
| sebras | ok, and if it draws the pattern tile, this is when the nodes in the list are used, right? | 14:21.03 |
| tor8 | the draw device was intended to cache rendered pattern tiles, so if it sees the same pattern again, with the same transformation matrix, we can just pull it out of the cache and copy the bitmap to the output | 14:21.44 |
| | and not have to re-render the same pattern again | 14:21.49 |
| | the display list doesn't do any caching, so it always returns false in the begin_tile call | 14:22.21 |
| | but when we play back the display list to a draw device that *can* do caching, we want it to forward the original ID so the draw device can benefit from caching | 14:22.54 |
| sebras | mmm, that seems reasonable. | 14:23.10 |
| tor8 | and another commit makes it so that the pdf interpreter can benefit and skip sending the pattern definition | 14:23.14 |
| | these bits of code don't look like they were ever properly hooked up | 14:23.32 |
| | your investigation into the 'overwriting hash slot' led me down this path | 14:23.43 |
| | sebras: so if you could try these commits with the files where you were seeing that warning, and let me know if they've gone away, I'd appreciate it. | 14:24.11 |
| sebras | tor8: simple, that was pdfref17.pdf | 14:24.42 |
| tor8 | page 1143 :) | 14:24.47 |
| sebras | I think so, yes. | 14:24.53 |
| | and now it works without warnings. | 14:25.20 |
| tor8 | we could also improve the display list to remember patterns it has seen before, and store a pointer to the original definition | 14:26.04 |
| | and then handle the repetition in the playback if the underlying device needs it | 14:26.27 |
| | but this is uncommon enough that I'm not too bothered | 14:26.41 |
| sebras | tor8: the reason I'm asking about all of this is that I have the feeling we might cache a tile and reuse it where it really should not be reused (because the flags of the node differed). | 14:26.45 |
| tor8 | as long as we can cache drawing the pattern tile in the draw device we've saved a lot of performance | 14:26.55 |
| | the flags of the node were always set to 0 | 14:27.12 |
| sebras | tor8: you did mention that, but not how you came to know..? | 14:27.26 |
| tor8 | fz_list_begin_tile | 14:27.28 |
| | 0, /* flags */ | 14:27.33 |
| sebras | oh... there's a second flags variable in fz_append_list_node() shadowing the other one. | 14:28.14 |
| | i mixed up the two flags variables. | 14:28.43 |
| tor8 | sebras: ah, right. I see that now. I'll rename the shadowing variable in another commit. | 14:30.47 |
| sebras | tor8: no worries, you didn't introduce it. | 14:31.49 |
| | tor8: but something seems to be awry with the patterns on page 1143. | 14:32.18 |
| | tor8: something to do with lcms or separations or something? the background is now black when it shouldn't be. /me is bisecting. | 14:32.57 |
| tor8 | oh, yeah. the color is also wrong... it's caching a colored tile | 14:33.40 |
| | in the 'uncolored tiling pattern' case | 14:34.48 |
| sebras | tor8: now I can't reproduce the black background..! agh. | 14:37.06 |
| tor8 | sebras: build skew. the makefile had a bad dependency on a header file. | 14:38.30 |
| | one of the source/pdf/*.c files included "../fitz/colorspace-imp.h" file and that dependency wasn't tracked in the makefile | 14:38.53 |
| sebras | ah. | 14:39.01 |
| | tor8: will you fix that in a later commit? | 14:40.39 |
| tor8 | I have fixed the makefile. I will fix the header file dependency later, so it doesn't actually need to include the file. | 14:41.13 |
| sebras | tor8: oh and a pet peeve about the trace tool, no globals? :) | 14:41.22 |
| tor8 | I like globals! | 14:41.33 |
| sebras | tor8: the makefile is a good temporary measure. :) | 14:41.37 |
| | tor8: as long as they are not malloced I guess I'm ok with them, but the css ones are _actually_ only used in the main function. | 14:42.03 |
| | it is only the use-flag that needs to be global. | 14:42.12 |
| | tor8: other than this I have no comments on tor/master so LGTM from me. | 14:45.12 |
| tor8 | sebras: thanks. | 14:46.51 |
| sebras | Robin_Watts: do you mind removing robin/sebras_master? I end up there every now and then when searching my own branches and I think that branch has survived its purposed by now. :) | 14:49.02 |
| Robin_Watts | sebras: Done. | 14:50.13 |
| sebras | Robin_Watts: thank you! | 14:51.32 |
| Robin_Watts | np. | 14:51.41 |
| | tor8: did you add the trace thing to the MSVC project? | 16:13.38 |
| | tor8: The first 4 commits on robin/spots should be good to go. Possibly all but the last 4. | 16:18.06 |
| mvrhel_laptop | Morning Robin_Watts | 17:55.51 |
| | So I will update to your latest spots... | 17:56.01 |
| Robin_Watts | mvrhel_laptop: Hold on... | 17:57.37 |
| mvrhel_laptop | ok | 17:57.43 |
| Robin_Watts | ok, latest version there has all my fixes in. | 17:58.08 |
| mvrhel_laptop | great | 17:58.13 |
| Robin_Watts | As is traditional, I tweaked your patches a bit :) | 17:58.22 |
| mvrhel_laptop | ok. np. I am hoping to have the spot blending done if not today, then this weekend | 17:58.50 |
| Robin_Watts | For the one where you changed [n] to [n-da] in 2 places, da is 0 and 1 always respectively in those 2 places. | 17:58.53 |
| mvrhel_laptop | ah | 17:59.07 |
| Robin_Watts | so I put the hardcoded values in. (That's the point of the optimisation). | 17:59.13 |
| mvrhel_laptop | that makes sense | 17:59.29 |
| Robin_Watts | My image mask stuff was broken, so I've just fixed that. | 17:59.41 |
| mvrhel_laptop | did you find the black background issue? | 17:59.56 |
| Robin_Watts | yes, that's fixed too. | 18:00.04 |
| mvrhel_laptop | cool | 18:00.08 |
| Robin_Watts | Looks like /None and /All are broken in the Altona technical page | 18:05.41 |
| | ok, I've fixed 'all'. | 18:25.21 |
| mvrhel_laptop | ah. ok. Robin_Watts there may be some inline optimizations that you will need/want to do when I am done in draw-blend. I am trying to avoid causing problems. I don't know how smart the compiler is. If I had two parameters in an inline method say (n,m) and I had a for loop that was conditioned on i<n and in the loop I had a test that was i >= m but I called this with parameters (p,p)... | 18:27.08 |
| | ...would the compiler be smart enough to not even have the test? | 18:27.10 |
| Robin_Watts | mvrhel_laptop: I would *hope* so. | 18:27.42 |
| mvrhel_laptop | Do you follow my question? | 18:27.42 |
| | ok | 18:27.44 |
| Robin_Watts | (But of course, Robins rule of compilers applies) | 18:27.54 |
| mvrhel_laptop | ha | 18:28.00 |
| Robin_Watts | ("All compilers suck.") | 18:28.07 |
| | oh, actually, sorry, I think I misread your question. | 18:28.50 |
| mvrhel_laptop | ok. well I will push on and get it working properly with as little impact as I can and we will go from that starting point | 18:28.51 |
| | oh ok | 18:28.57 |
| Robin_Watts | No, I don't think the compiler will be smart enough for that. | 18:29.01 |
| mvrhel_laptop | ok | 18:29.08 |
| | I will have to do something simpler then | 18:29.17 |
| Robin_Watts | If the inline function gets called with (n=p, m=p) then I would reasonably expect the compiler to figure out that (n < m) never happens. | 18:29.48 |
| | but when you're doing a loop from i=0 to n, and testing i > p, I don't think you can reasonably expect the compiler to know that i will always be in the 0..n range. | 18:30.23 |
| | i'd like to be wrong, but... | 18:30.29 |
| | If I was you, I'd just make it work, and we can worry about optimisations later. | 18:30.44 |
| | That's kinda the approach I've been taking. | 18:31.00 |
| | oops. I appear to have 2 "MyRed" separations in this file. Need to fix that. | 18:31.37 |
| mvrhel_laptop | good grief | 18:35.19 |
| | Had not had the happen in a while | 18:35.25 |
| | machine completely froze. | 18:35.30 |
| | Had to power down to get back. | 18:35.47 |
| Robin_Watts | eek. | 18:35.57 |
| mvrhel_laptop | Then windows or the NSA did about a dozen updates | 18:36.01 |
| Robin_Watts | ah, you had pending updated. | 18:36.14 |
| mvrhel_laptop | yes | 18:36.18 |
| Robin_Watts | s/d/s/ | 18:36.19 |
| mvrhel_laptop | Robin_Watts: ok. I read the logs | 18:36.52 |
| | I will push on and maybe make a comment where there may be an issue | 18:37.07 |
| Robin_Watts | mvrhel_laptop: OK, new robin/spots with various fixes. | 18:42.35 |
| | I still have the double colorant thing in there, but None and All seem to be better. | 18:42.53 |
| mvrhel_laptop | Robin_Watts: ok. I will update on that soon. Thanks | 18:42.55 |
| Robin_Watts | I'll try to fix the double colorant thing before I quit for the day. | 18:43.12 |
| mvrhel_laptop | oh I just figured out how to do this | 18:43.56 |
| Robin_Watts | D'Oh. Stupid mistake. | 18:45.21 |
| | mvrhel_laptop: Does out.psd in my homedir look right to you? (Ignoring overprint) | 18:47.05 |
| mvrhel_laptop | let me look | 18:47.13 |
| Robin_Watts | That's tests_private/comparefiles/Altona_Technical_1v1_x3.pdf | 18:48.30 |
| mvrhel_laptop | ah | 18:48.35 |
| | I was hoping the other file | 18:48.43 |
| Robin_Watts | which file? | 18:48.50 |
| mvrhel_laptop | This one takes a little time | 18:48.50 |
| | I was thinking the one with the girl | 18:49.17 |
| | Give me a little time to look this over | 18:49.43 |
| | ok. found the orginal | 18:50.51 |
| | Robin_Watts: ok there are going to be transpareny issues too | 18:51.20 |
| | so A 7-12 are wrong | 18:51.40 |
| | B 10-11 | 18:52.07 |
| Robin_Watts | 1-24 are wrong for all of them, cos no overprint. | 18:52.20 |
| | It's 25-36 that should be correct. | 18:52.27 |
| mvrhel_laptop | ah | 18:52.38 |
| | ok | 18:52.40 |
| Robin_Watts | isn't it? | 18:52.43 |
| | My sole experience of this file is in running away from it. | 18:52.58 |
| mvrhel_laptop | yes. hold on | 18:53.05 |
| | ok you are correct. | 18:53.43 |
| | let me look at the right side. sorry about that | 18:53.52 |
| | So C29 C35, D29 D35 have some weird resolution thing going onn | 18:55.15 |
| Robin_Watts | You mean, the fact that they are interpolated? | 18:55.58 |
| mvrhel_laptop | I guess so. I just see it different than AR | 18:56.39 |
| Robin_Watts | Altona_Technical_v20_x4 page 4 is broken somehow. | 18:57.01 |
| mvrhel_laptop | AR is probably doing a zero based interp | 18:57.01 |
| | looks good Robin_Watts | 18:58.18 |
| Robin_Watts | Altona_Technical_v20_x4 pages 4 and 7 are broken, and 8 seg faults. | 18:59.23 |
| mvrhel_laptop | So AR never seems to interpolate what they call "bitmap image" in the altona file | 19:00.09 |
| | or maybe my interpolation off in my settings | 19:00.22 |
| | hold on | 19:00.24 |
| | hmm can't find anything wrong | 19:02.03 |
| Robin_Watts | mvrhel_laptop: MuPDF chooses to interpolate if we are downscaling. | 19:02.23 |
| | It's a tunable option. | 19:02.37 |
| mvrhel_laptop | ok | 19:02.40 |
| | looks good to me | 19:02.44 |
| Robin_Watts | I suspect if I was running at 200dpi rather than 72dpi, we'd be OK. | 19:02.55 |
| mvrhel_laptop | right | 19:03.03 |
| Robin_Watts | OK, so I think this is a good place to quit for me. | 19:03.05 |
| mvrhel_laptop | yes. good job. things are moving along nicely | 19:03.20 |
| Robin_Watts | We are getting there, but there are some crashy bugs in there :( | 19:03.50 |
| | This one is to do with a pixmap being freed unexpectedly. | 19:04.04 |
| | I don't have the strength to bughunt that now. | 19:04.15 |
| mvrhel_laptop | ok. I am going to push on with the spot blending | 19:04.25 |
| Robin_Watts | go for it. | 19:04.28 |
| mvrhel_laptop | Then I can help with bugs if you still have any | 19:04.35 |
| Robin_Watts | Have a good weekend. | 19:04.38 |
| mvrhel_laptop | you too | 19:04.41 |
| | Forward 1 day (to 2017/07/22)>>> | |
Log of #mupdf at irc.freenode.net.