| | <<<Back 1 day (to 2018/06/27) | 20180628 |
| paulgardiner | tor8: thanks | 08:24.56 |
| tor8 | Bug693664 has another file. | 08:32.56 |
| | paulgardiner: ^ | 08:33.01 |
| paulgardiner | Ta | 08:33.37 |
| tor8 | paulgardiner: I put http://ix.io/1fgc in a file rot.txt and used 'mutool create -o rot.pdf rot.txt' to create the first sample file | 08:35.00 |
| | moolc: I draw a quad for each contiguous area of the selection. the rects are merged if they are adjoining. | 08:36.20 |
| moolc | tor8: gotcha, makes sense, i just union the rects (lazy and all that) | 08:37.31 |
| tor8 | moolc: that doesn't work too well when the selection is on multiple lines | 08:37.56 |
| moolc | tor8: you are doing it wrong then ;) | 08:45.42 |
| | or at least not the way i do it | 08:45.48 |
| tor8 | moolc: then I take issue with your claim that you "just union the rects"... | 08:46.31 |
| moolc | tor8: let me check | 08:46.57 |
| | tor8: i union the rects - https://github.com/moosotc/llpp/blob/master/link.c#L1807 | 08:48.36 |
| | tor8: FWIW cloning the thing and following BUILDING would get you a nice shiny application (plus a mega cool build system)... (no prereqs, it will fetch ocaml automagically so should work out of the box even on your retrograde/luddite debian) | 08:51.14 |
| paulgardiner | tor8: I'm seeing a few problems now I've tested with a wider range of forms. Should I raise bugs? | 09:29.11 |
| tor8 | paulgardiner: what kind of problems? appearance synthesis related? | 09:35.10 |
| paulgardiner | Not sure. Choice widgets now display as though all the options are stacked on top of each other. Also I'm not able to detect changes for some cases with check boxes. Particularly radio buttons: I can't detect the newly checked button, although I can detect the one becoming unchecked. | 09:39.19 |
| | I have another case where a choice widget just goes blank when I attempt to change it. | 09:39.51 |
| tor8 | I haven't changed anything which should affect the 'logic' of forms | 09:42.26 |
| | not yet, at any rate | 09:42.52 |
| paulgardiner | Some of these I didn't see before your ui branch | 10:02.03 |
| tor8 | the checked buttons, could they be missing the AP for the other states and that's why you're not seeing changes? | 10:03.12 |
| | send me the files in an email, it's less likely I'll miss them than if you open a bug report :) | 10:03.28 |
| paulgardiner | They update when I force a redraw by zooming | 10:03.41 |
| tor8 | does mupdf-gl detect the changes? | 10:04.13 |
| | Robin_Watts: do you still have the beagleboard (or some other arm-based linux machine you can run mutool on?) | 10:05.18 |
| Robin_Watts | tor8: I do. | 10:05.36 |
| | I have a pi2. | 10:05.39 |
| tor8 | Robin_Watts: the internet was down yesterday, so I spent a few hours bashing on an idea you're going to hate | 10:05.51 |
| paulgardiner | tor8: does mupdf-gl work that way? I thought it just redrew the entire page on each change. | 10:06.01 |
| Robin_Watts | o.....k..... | 10:06.09 |
| tor8 | and I'd like to see how much of a slowdown it causes on an arm machine--benchmarking on my intel's show nothing | 10:06.15 |
| | Robin_Watts: the tor/nostar branch | 10:06.42 |
| | paulgardiner: we redraw the whole page, but first it has to detect that things have changed and need redrawing | 10:08.10 |
| | paulgardiner: however, I did note that the mechanism for flagging a widget as changed is ... fragile | 10:08.34 |
| paulgardiner | tor8: how do you mean fragile? I believe it used to work in call cases. | 10:09.26 |
| tor5 | ugh, internet's still glitching | 10:10.50 |
| | paulgardiner: it uses a single 'dirty' flag for all purposes | 10:11.03 |
| paulgardiner | I meant "in all cases" | 10:11.10 |
| Robin_Watts | tor8: Of couse, I have to remember my raspberry pi's password... | 10:11.22 |
| tor5 | not the dual-style flagging for annotations: contents changed, need new AP; AP changed, need repaint. | 10:11.31 |
| | Robin_Watts: I'm a bit worried. taking on the change means a lot of churn for customers with custom code... but it does lead to a lot nicer code in several places. | 10:12.19 |
| | Robin_Watts: anyway, I am curious about the performance. | 10:12.39 |
| | and I'm hoping a low powered arm device will show that a lot better than super-hyperthreaded optimized intel CPUs | 10:12.59 |
| Robin_Watts | tor5: As you predicted, I dislike it :) | 10:13.27 |
| paulgardiner | tor5: I don't altogether get that. In the app I just need to know that it needs repainting... assuming there's not an obligation to make explicit calls for appearance stream updates for the sake of the other flags. | 10:14.04 |
| tor5 | Robin_Watts: I got fed up with "local_ctm = *ctm;" everywhere, and bbox1, bbox2, bbox3 temporary variables | 10:14.05 |
| | paulgardiner: in the case where the app is the only user of updates, that works. but appearance synthesis in programmatic environments like doing stuff from javascript etc also need to work and having a single flag that the user must set/clear is ... not good. | 10:15.19 |
| | communicating "things have changed, but we don't know just what" with a single boolean wasn't enough | 10:15.59 |
| | because that flag was looked at by multiple users, but when/who should clear it? | 10:16.18 |
| | we can't clear it when creating an AP, because the viewer still needs to know | 10:16.29 |
| | but if there is no viewer to clear it, then we'll keep recreating it forever | 10:16.37 |
| | hence the two separate flags | 10:16.52 |
| | and I still need to do something similar for forms. I suspect that's where it falls down, communicating the changes from the form field value to the appearance stream | 10:17.24 |
| paulgardiner | Well it used to work. :-) | 10:19.05 |
| tor5 | paulgardiner: see the TODO at the top of pdf_update_annot for my quick and dirty hack to make it almost work :) | 10:19.42 |
| Robin_Watts | tor5: I'm downloading a more up to date raspbian image now, I'll stick that on the SD card and get you access to the pi. | 10:22.26 |
| paulgardiner | tor5: I've just confirmed that: back with mupdf at commit 4d473e7f6a, I'm getting the updates and not seeing any extraneous ones. | 10:25.51 |
| | Ah, also seeing a choice field disappear when altered. Just checked the old version and there is javascript in the file that changes the text color to white and the background to red. We are now losing the red background. | 10:31.02 |
| | I'm struggling a little to get how the fragility of the old version is making the new version fail. | 10:34.50 |
| tor5 | paulgardiner: ah, but we're applying the white text color? | 10:42.06 |
| Robin_Watts | tor5: Try ssh tor@rjw.ghostscript.com:5555 ? | 10:42.23 |
| moolc | tor5: 9181fa7617c9a3c481636a68c8206dafd0ebb400 what about irect? quad? tack though | 10:43.04 |
| paulgardiner | tor5: yeah, not sure why we apply one but not the other. Both got applied back at 4d473e7f6a | 10:43.12 |
| tor5 | Robin_Watts: ssh: Could not resolve hostname rjw.ghostscript.com:5555: Temporary failure in name resolution | 10:43.13 |
| Robin_Watts | tor5: Try ssh tor@rjw.ghostscript.com -p 5555 ? :) | 10:43.31 |
| tor5 | Robin_Watts: d'oh. still, No route to host. | 10:43.58 |
| paulgardiner | tor5: it's to do with focus. If I click in another field, that one changes to white on red and the previously selected one goes back to black on white. | 10:44.18 |
| Robin_Watts | Does ping rjw.ghostscript.com work? | 10:44.21 |
| tor5 | traceroute times out at 86.54.135.73 | 10:44.32 |
| | oddly enough, ping works | 10:45.17 |
| paulgardiner | tor5: on a plus note, combed text is working well. :-) | 10:47.08 |
| Robin_Watts | tor5: Can you reach http://rjw.ghostscript.com:911/ in a browser? | 10:47.41 |
| tor5 | Robin_Watts: yes. but I can't reach it thourgh ssh from neither my home machine nor via casper | 10:48.43 |
| Robin_Watts | Maybe it's failing at the NAS forwarding bit? | 10:49.07 |
| tor5 | Robin_Watts: I suspect it may be, yes | 10:49.45 |
| | port 911 gets through, but not port 5555 | 10:49.52 |
| Robin_Watts | Try port 22 now ? | 10:51.14 |
| tor5 | Robin_Watts: I'm in! | 10:51.36 |
| Robin_Watts | ok, but I'm not happy with port 22 being open :) | 10:51.53 |
| | let me try changing it to something else. | 10:51.59 |
| tor5 | Robin_Watts: understandable, considering how often that gets hammered by port scanners | 10:52.14 |
| Robin_Watts | Try 3457 | 10:52.16 |
| tor5 | Robin_Watts: that worked too | 10:52.29 |
| Robin_Watts | sorted then. | 10:52.33 |
| | That's an aged version of raspbian, but should be OK. | 10:52.55 |
| | I can update it if required, but should be enough for timings. | 10:53.15 |
| tor5 | Robin_Watts: thanks. I'll prod a bit and see if I can get some useful timings out. | 10:54.30 |
| | paulgardiner: try top commit of tor/master for the red background thing | 10:54.39 |
| paulgardiner | ta. will do | 10:55.02 |
| moolc | Robin_Watts: what Pi version is that? Pi3B+? | 11:28.17 |
| sebras | moolc: pi2. | 11:28.48 |
| moolc | sebras: tack | 11:29.05 |
| sebras | moolc: it might be a pi2b, though. I'm not sure. | 11:29.16 |
| moolc | sebras: being dissatisfied with odroid i've ordered a pi3b+ and sent an ex-coworker to the states to fetch me one | 11:30.37 |
| paulgardiner | tor5: thinking back, I don't believe that one flag was being used for multiple purposes. I have some recollection of the annot struct holding both a reference to the current appearance stream plus a version number. Comparing that with the state of the widget object allowed you to tell if either a different appearance stream had been selected or if the same one was in use, but it had changed form. | 11:38.51 |
| | tor5: that new commit doesn't seem to fix the red background problem. :-( | 11:42.47 |
| tor5 | paulgardiner: yeah, there was a version number way back when, but that hasn't been there for quite a number of months. | 11:43.01 |
| | paulgardiner: send me the file, I'll take a look. | 11:43.06 |
| | not much I can do without it | 11:43.11 |
| paulgardiner | Okay ta | 11:43.13 |
| | I didn't like the version number when I put it in, but it is a mechanism that allows multiple observers to monitor change. | 11:45.37 |
| Robin_Watts | moolc: Ray has a pi3 which is faster. | 12:20.01 |
| | The 3+ is better when multithreading. | 12:20.13 |
| | (but takes LOTS more power to do so, apparently. This is only a problem when clustering them). | 12:20.35 |
| moolc | Robin_Watts: faster than what? | 12:20.38 |
| Robin_Watts | pi3 is much faster than pi2. | 12:20.51 |
| moolc | Robin_Watts: ok | 12:20.57 |
| tor5 | paulgardiner: looking at the file you sent... with mupdf-gl the checkboxes redraw whenever you click, and the text fields update when I change the Value using the annotation editing panel | 12:21.01 |
| moolc | Robin_Watts: how do you quantify "LOTS more power"? | 12:21.11 |
| | how do you measure it? | 12:21.15 |
| Robin_Watts | like 50% more or something. | 12:21.27 |
| tor5 | paulgardiner: I trigger a redraw when pdf_pass_event returns true | 12:21.41 |
| Robin_Watts | It's a big peak power usage increase for a moderate increase in actual performance. | 12:21.47 |
| tor5 | paulgardiner: maybe at that time, the widgets don't have the dirty flag set correctly? | 12:21.59 |
| Robin_Watts | Like I say, it's not a problem if you have just one of them, but if you have a bunch of them in an array, it can be a problem. | 12:22.17 |
| moolc | Robin_Watts: but how do you measure it? | 12:22.57 |
| Robin_Watts | We were looking at an array of pis to replace/augment our cluster, and that's what the people that made the enclosures told me. | 12:23.16 |
| moolc | thinks that it might have been good idea to stick with Cavium and work on ThunderX... oh well | 12:23.26 |
| Robin_Watts | moolc: A meter I guess :) | 12:23.32 |
| tor5 | paulgardiner: I'm also seeing that has_new_ap is set to true for the checkbox annotation when I click it | 12:23.46 |
| moolc | Robin_Watts: use a watt meter myself to measure stuff.. | 12:24.25 |
| | just today i measured how much one of our soviet made fridge consumes... | 12:24.50 |
| paulgardiner | tor5: I assume it's just some of the dirty flags aren't set correctly. I see updates for radio buttons that are being cleared, but not those being set | 12:27.33 |
| tor5 | paulgardiner: are you looking at annot->has_new_ap? | 12:29.43 |
| | I'm seeing the radio checkboxes clearing and setting the has_new_ap as expected | 12:30.01 |
| | (a bit drowned out by the "cannot create appearance stream for Btn widgets" errors though) | 12:30.24 |
| paulgardiner | Yeah, I'm looking at has_new_ap | 12:32.18 |
| tor5 | oops. looks like I'm never resetting it. | 12:32.40 |
| | okay, if I clear it properly I still see the expected behaviour | 12:35.29 |
| | paulgardiner: are you setting has_new_ap = 0 when you've reacted to the change? | 12:36.00 |
| | (though that should only cause you to see more updates than necessary, not missing out on them) | 12:36.16 |
| paulgardiner | Yep. I am resetting it. | 12:38.23 |
| tor5 | and clicking on checkbox 1 followed by checkbox 2 does NOT tell you this: http://ix.io/1fhv | 12:40.34 |
| | that's what I get for each event (where I print the dirty status when adding log calls inside pdf_update_page) | 12:41.23 |
| | inside pdf_update_annot I mean, which is called in a loop by pdf_update_page, which I call after having processed the event in my event handler in do_forms() | 12:42.25 |
| paulgardiner | Is this f1040.pdf? | 12:45.24 |
| tor5 | yes. the file you emailed em. | 12:46.25 |
| | paulgardiner: just looking at the checkboxes/radioboxes | 12:47.08 |
| | haven't investigated changing the text fields yet | 12:47.19 |
| paulgardiner | I don't monitor after press, only after release, but I guess that shouldn't make a difference. | 12:47.41 |
| tor5 | paulgardiner: yeah. if you miss some pdf_update_page you should still be seing the latest changes | 12:48.06 |
| | once you do get around to calling it | 12:48.16 |
| | paulgardiner: tor/master has mupdf-gl with added logging | 12:53.34 |
| paulgardiner | My linux box is headless. Not sure I can do much with mupdf-gl | 12:54.25 |
| tor5 | paulgardiner: install an X server on your main machine? :) | 12:54.50 |
| | glx is a thing... | 12:54.54 |
| | or just do a small debian virtualbox VM | 12:55.08 |
| Robin_Watts | mupdf-gl builds on windows, right? | 12:55.54 |
| tor5 | I can't reproduce what you're claiming to see... I've got code that works, and I think the easiest way to help is if you look at that and see where it differs. | 12:56.00 |
| paulgardiner | Okay, but in any case, I'm not sure messing with mupdf-gl will help | 12:56.00 |
| tor5 | it does. | 12:56.03 |
| paulgardiner | I mean "my messing with it" | 12:56.22 |
| tor5 | add the same kind of logging and see where things diverge | 12:56.22 |
| paulgardiner | Yeah, I'm doing that anyway | 12:57.12 |
| | tor5: which check boxes? | 13:27.45 |
| | If I click on the checkbox next to "Single", I see 1583, 1588, 1596, 1600, 1605, 1610, 1614, 1618, 1626, 1633, 1640, 1647, 1651 and 1675 dirty. | 13:38.43 |
| | Then click on the one next to "Married" and I see the same set accept 1596 is replaced with 1592. | 13:40.10 |
| | s/accept/except/ | 13:40.34 |
| | I cycle fzpages more than in mupdf-gl. That tweaked a bug before, but I thought you'd fixed it. | 13:42.43 |
| tor5 | paulgardiner: "cycle fzpages"? | 14:01.49 |
| paulgardiner | destroy and recreate... not between an event and the corresponding update obviously., | 14:02.32 |
| tor5 | if you load/reload a page, all bets with tracking annotation dirty states are off. | 14:02.36 |
| | paulgardiner: though I expect we can initialize the 'has_new_ap' state to true | 14:03.20 |
| paulgardiner | That will force a load of updates on the first check, though. | 14:04.06 |
| | Surely, it should be clean when created and then show the updates since creation or last test when tested. | 14:05.03 |
| tor5 | paulgardiner: line 101 in source/pdf/pdf-annot.c | 14:05.08 |
| | my tracking expects the annot to stay alive once loaded | 14:06.17 |
| | not to be unloaded and recreated. | 14:06.26 |
| | if we create new ones with the has_new_ap=1 instead of 0 that *ought* to fix your problem, I believe | 14:06.44 |
| paulgardiner | But it'll give me unnecessary ones too. | 14:07.09 |
| tor5 | because then if you unload and reload you'll always be told that it's new (as is to be expected, since it is a new annot) | 14:07.10 |
| | then don't free the pdf_annot! | 14:07.20 |
| | if you throw away the struct that keeps track of these things for you, what did you expect would happen? :) | 14:07.42 |
| paulgardiner | That sounds like it makes sense but doesn't. We just need to know about changes between creation and a test, and between tests. | 14:09.04 |
| | It all worked just fine before. | 14:09.11 |
| tor5 | define creation and test, please. | 14:09.38 |
| paulgardiner | creation being creation of an fzpage. test being a class to update followed by a enumerating the annotations to see which has changed and resetting the flag | 14:11.18 |
| tor5 | the pdf_annot struct keeps track of transient state that your app cares about, and to delay creating a new AP until a batch of edits to the underlying pdf objects have all gone through (so we don't create one when you set the border, the recreate it when you set the color, then recreate it when you set the date, etc.) | 14:11.34 |
| paulgardiner | Yep. The old method used to do that too. | 14:12.20 |
| tor5 | if you throw away the pdf_annot struct mid-transaction (such as doing some edits, freeing the pdf_annot, then loading the annot again, we won't know that the AP needs updating) | 14:12.23 |
| paulgardiner | I'm not going to throw it away without calling the update method. | 14:12.50 |
| tor5 | likewise, if you do some edits, the pdf_annot struct keeps track of *both* knowing to create a new AP, and letting the UI know that the AP has changed | 14:13.07 |
| | the AP can change for two reasons: either the contents changed and we recreated it, or the button state changed and it points to a different AP | 14:13.31 |
| | now, calling the update method syncs the backing pdf_obj, AP, and pdf_annot state. | 14:14.14 |
| paulgardiner | Yeah. Have you read the last few comments I've made? | 14:14.31 |
| tor5 | yes. | 14:15.02 |
| paulgardiner | I know that. And I'm not throwing away between an event that changes something and a call to update. | 14:15.03 |
| tor5 | so that part should be safe. | 14:15.05 |
| | now, if you load a pdf_annot, do some edits and it flags itself as dirty, and you call update to sync the AP with the new edits. then you free it and load it, we've forgotten the flag that should let the UI know that the AP for this annotation is new. | 14:16.16 |
| | that flag needs to live somewhere. previously you stowed it into the pdf_obj 'dirty' flag. | 14:16.38 |
| paulgardiner | But I do all that in one go. | 14:16.41 |
| tor5 | I've moved it into the pdf_annot struct. | 14:16.49 |
| paulgardiner | I do the change. I call the update function. I set the UI redrawing. I don't throw away within that sequence | 14:17.29 |
| tor5 | paulgardiner: then I don't understand your comment "But it'll give me unnecessary ones too." | 14:19.33 |
| | if you unload a page, and reload it, then everything will be fresh and that should tell you all annotations are new (since they are, they were just loaded) | 14:20.07 |
| | paulgardiner: does your problem persist if you annot->has_new_ap = 0 to 1 in pdf_load_annots? | 14:21.04 |
| | paulgardiner: and for clicking the checkboxes, just to make sure we're speaking the same language: | 14:22.50 |
| paulgardiner | Seems like we have different concepts of what the flags should do. I don't see the need for knowing something is "fresh" in that sense. I just need to know when something has changed. I don't need to know that I just loaded it. | 14:23.16 |
| tor5 | you a) call pdf_pass_event, b) call pdf_update_page, c) loop through the annots looking for ones with has_new_ap to rerender? | 14:23.19 |
| paulgardiner | Yep. Same concept there. | 14:24.02 |
| tor5 | so you do an unconditional render of all annots when you load a page? | 14:25.49 |
| | and then on a pdf_pass_event you pdf_update and re-render the changed ones | 14:26.09 |
| paulgardiner | I haven't been looking at this in terms of PDF, just what an app needs from a render engine. So, I was just thinking I load a page and render it. After that I just need a way to find out what rectangles to rerender when the document changes. | 14:26.13 |
| tor5 | and then on an edit, you pdf_update_page and re-render th changed ones | 14:26.21 |
| | paulgardiner: should be the same basic concept :) | 14:27.18 |
| | paulgardiner: though, when an annot is edited and updated, its bbox will likely change | 14:27.47 |
| | so you have to remember the old area it used to cover as well as the new one | 14:28.02 |
| | can your UI framework do multiply alpha blends? | 14:28.21 |
| | if so, then you can render each annotation to a separate texture, and just plain alpha blend on top for most, and multiply blend for highlights. | 14:28.43 |
| | texture/pixmap/image/what have you | 14:28.52 |
| | or do the blending using mupdf's fz_pixmaps, I can add the few functions you need | 14:29.13 |
| | or do the blending yourself to compose a final ui framework texture | 14:29.41 |
| paulgardiner | I'm still trying to work out what your asking in "so you do an unconditional render..." | 14:29.54 |
| tor5 | that will definitely be faster when editing pages, since you don't need to rerender the whole backdrop | 14:30.02 |
| | "you render all annots (ignoring any dirty flag) when you load a page" | 14:30.26 |
| | I thought you were rendering to separate display lists or something like that | 14:30.40 |
| | which is what the previous code you wrote for android did :) | 14:30.55 |
| | one display list for the page, and a separate display list for each annot, and you recreated the display list when the annot was updated | 14:31.10 |
| paulgardiner | I'd hope all that was irrelevant to the main point. | 14:31.35 |
| | I don't unconditionally render when I load a page. I might be loading a page without any intent to render it. But when I first render a page, to create the first bitmap version of it, I do render it and it's annotations without checking flags. I'd have thought I'd have to because otherwise I'd have annotations completely missing. | 14:33.31 |
| | I had also expected to see all the flags clear on loading because no changes have yet been made w.r.t the page I've just loaded | 14:34.30 |
| | w.r.t the version of the page I've just loaded. | 14:35.04 |
| | I don't see the flag as meaning "you should render this". I see it as meaning "this may be different to how it looked when you first obtained it" | 14:37.09 |
| | ... the difference being relevant when you first create a bitmap for a page, or combination of bitmaps to be blended. Then you know to render the lot, without having flags telling you to. | 14:39.03 |
| | Does mupdf-gl go through the update and enumerate annotations step when first creating the visuals for a page? | 14:40.50 |
| tor5 | paulgardiner: yes, that is how the has_new_ap flag is intended. let you know that things have changed since the last time you saw it and it was clear. | 14:41.20 |
| | paulgardiner: two questions for you. | 14:41.54 |
| | 1) how do you track dirty rectangles | 14:42.00 |
| | 2) regardless of how you answer number 1, how can this possibly affect the handling of has_new_ap? | 14:42.28 |
| | I would have assumed that you would need to have some auxiliary list of 'this annot was at this rect before' that you check against when you decide to re-render | 14:43.06 |
| paulgardiner | What is "this" in Q2? | 14:43.16 |
| tor5 | since you need to make sure the pixels it used to touch, and the pixels it now touches, are all updated. | 14:43.19 |
| | this=tracking dirty rectangles | 14:43.29 |
| paulgardiner | Then why ask 1? | 14:43.46 |
| tor5 | curiousity :) | 14:43.54 |
| | (sic) | 14:44.06 |
| | in mupdf-gl I rerender the whole page (ran into trouble with highlight annotations and my old approach, that I haven't solved yet) | 14:45.09 |
| | are you mistracking the dirty regions and that's why you're not seeing the checkboxes clear? that doesn't sound likely, given the list of annots you saw being flagged earlier. | 14:46.17 |
| | when I click "Married" I see both 1592 and 1596 with has_new_ap set. | 14:46.33 |
| paulgardiner | I still don't get your has_new_ap meaning. When you first load a page, you have never seen it before. And there have been no changes since you loaded the page, since you have just loaded it. | 14:46.43 |
| tor5 | I set has_new_ap to 1 anytime the AP changes, for any reason. this is the cue to the UI to redraw the annotation. | 14:47.22 |
| paulgardiner | If you look at the list of dirty annotations I posted above, you'll see that there are missing ones... exactly the ones that would cause the visual problem I see | 14:47.32 |
| tor5 | and I expect you to clear it when you've done whatever you want to do with it. | 14:47.58 |
| | mupdf only ever sets it to 1 | 14:48.03 |
| paulgardiner | I do. | 14:48.13 |
| tor5 | mupdf-gl does not see that whole list of has_new_ap annots | 14:48.45 |
| paulgardiner | Yes. When I click Married I don't get both those. See above. | 14:48.50 |
| tor5 | with tor/master (and without the change I asked you to test in pdf_load_annots, forget about that one) | 14:49.01 |
| paulgardiner | Yeah. I haven't tried that change | 14:49.33 |
| tor5 | I load the document, render the page, *none* of the annots have has_new_ap set. | 14:49.39 |
| | I click "Single", and I rerender, and it says 1592 has a new ap | 14:49.56 |
| | I click "Married", and I rerender, and it says 1592 and 1596 have new aps | 14:50.09 |
| | nothing else is dirty. | 14:50.15 |
| | ever. | 14:50.17 |
| | this is with the code on tor/master now | 14:50.47 |
| paulgardiner | I thought you said you set the flag when you first load the page. | 14:51.12 |
| tor5 | the penultimate commit might be what's causing you to see the others as being dirty (having failed to create a new ap the flag is set anyway) | 14:51.12 |
| | I don't. I asked you to test if that was the problem, when you worried me about saying that you cycle pages. | 14:51.31 |
| | the change I asked you to do was to *set the flag when you first load the page* :) | 14:51.57 |
| | in case that was the problem. since you talked about cycling pages. | 14:52.07 |
| paulgardiner | Bah! About my last half hour of comments have been arguing against setting the flag when you first load an annot. | 14:52.25 |
| tor5 | Sorry. Did I slip on the keyboard and omit a "not" somewhere? :) | 14:54.52 |
| paulgardiner | I may have misread. | 14:55.07 |
| | Okay, so the intended behaviour is exactly what I want. | 14:55.30 |
| tor5 | Good. Now to figure out why you're not seeing the same behaviour as mupdf-gl. | 14:57.45 |
| paulgardiner | So presumably you must unconditionally render all the annots on very first render too? | 14:58.15 |
| tor5 | paulgardiner: I render everything all the time; but I did add logging to check which annots were dirty in the top commit on tor/master | 14:58.43 |
| paulgardiner | I've put the same logging in my loop, but my loop isn't responsible for rendering: it just creates a set of rectangles of which to request rerender, and my loop gets called only after some operation that may change the document. | 15:01.11 |
| | tor5: presumably mupdf-gl has javascript enabled? | 15:05.03 |
| tor5 | paulgardiner: yes. and it can fill in text widgets using the annotation editing panel as well. | 15:05.39 |
| paulgardiner | I'm looking forward to playing with editing panel. | 15:06.05 |
| tor5 | paulgardiner: it builds and works on windows, if you have that. | 15:06.21 |
| | anyway, I've got to go away for a couple of hours. | 15:06.45 |
| paulgardiner | By playing, I more meant using it within muso | 15:06.47 |
| tor5 | will check back | 15:06.52 |
| | paulgardiner: ah, right. | 15:06.59 |
| paulgardiner | tor5: okay thanks. catch you later. | 15:07.06 |
| | Forward 1 day (to 2018/06/29)>>> | |
Log of #mupdf at irc.freenode.net.