| | <<<Back 1 day (to 2020/11/29) | Fwd 1 day (to 2020/12/01)>>> | 20201130 |
| artifexirc-bot | <Robin_Watts> @ator So, commits on robin/master updated. | 12:30.55 |
| | <Robin_Watts> There is 1 problem that none of this stuff addresses; namely that when the app gets put into the background, we need to be able to 'dump' the state in case the app gets killed, and then 'scoop' it back up again later. | 12:31.39 |
| | <Robin_Watts> At the moment they are doing this by saving the document and then reloading it, but that has problems whereby the document grows by 1 incremental section each time. | 12:32.18 |
| | <Robin_Watts> Paul suggested that we could actually do it by saving the file and then reloading it, but 'reopening' the last incremental update. | 12:33.01 |
| sebras | @ator @Robin_Watts does it make sense for fz_draw_clip_path() to set pixels in state[1].mask, but not set the corresponding pixels in state[1].dest? it sounds to me like it might be drawing in the mask, but forgetting to set the actual pixels. | 12:33.31 |
| artifexirc-bot | <Robin_Watts> That seems pretty neat to me, but it means we lose undo/redo over such a dump/scoop. | 12:33.32 |
| | <Robin_Watts> If the mask is set to 0, no need to set the actual pixels? | 12:34.11 |
| | <Robin_Watts> @sebras If the mask is set to 0, no need to set the actual pixels? Dunno if that's what you're seeing. | 12:34.30 |
| sebras | fz_convert_rasterizer() set the mask value to non-zero values though! | 12:35.00 |
| artifexirc-bot | <Robin_Watts> @sebras I can't explain that off the top of my head then. | 12:35.39 |
| sebras | I'm seeing that the mask is 15, but the sample is left uninitialized. | 12:35.45 |
| artifexirc-bot | <Robin_Watts> I believe we should hit the same pixels in each branch of the rasterizer. | 12:35.52 |
| | <Robin_Watts> Oh, unless the mask is drawn first and an error is thrown mid-draw, so the actual content draw never happens? | 12:37.19 |
| sebras | this becomes a problem later then popping the clip, since template_span_with_mask_3_general() then tries to read an uninited value. | 12:37.23 |
| artifexirc-bot | <Robin_Watts> @sebras If you want to throw the bug at me, feel free. | 12:37.44 |
| | <Robin_Watts> @ator So, current cunning idea... | 12:38.03 |
| sebras | @Robin_Watts there is no bug, just an oss-fuzz issue. | 12:38.07 |
| artifexirc-bot | <Robin_Watts> @sebras Open a bug, throw it at me 🙂 | 12:38.18 |
| | <Robin_Watts> Presumably you can see the problem with valgrind? | 12:38.32 |
| sebras | I can, or with clang ASAN with special compilation options. | 12:38.50 |
| artifexirc-bot | <Robin_Watts> I can cope with valgrind 🙂 | 12:39.04 |
| sebras | sure? you tend to pacify it... ;) | 12:39.19 |
| | @Robin_Watts I'll give this another try, if I can't find anything I'll open a bug | 12:40.11 |
| artifexirc-bot | <Robin_Watts> @ator Let's add an option to 'save', whereby we save the current file incrementally to a new file, and then append the 'undo/redo' data at the end with a new marker at the end of the file. | 12:40.21 |
| | <Robin_Watts> When we come to reload the file, we can spot the marker, load the undo/redo data, load the file, and reopen the last increment. | 12:40.52 |
| | <Robin_Watts> What do you think? | 12:41.01 |
| | <ator> a %%JOURNAL kind of marker, or a magic /MuPDF:UNDO key in the trailer for the xref sections? | 13:45.18 |
| | <ator> with a "[ ] Preserve undo history." to mupdf-gl's options so we can test it | 13:45.56 |
| | <ator> these are just variants of incremental xref sections, right? | 13:46.33 |
| | <Robin_Watts> Yes. | 14:30.00 |
| | <Robin_Watts> A %%JOURNAL, I was thinking. | 14:48.19 |
| | <Robin_Watts> I'm going to update mupdf-gl so it can undo/redo. | 14:53.55 |
| | <Robin_Watts> @ator I don't understand the layout packing stuff. | 16:00.07 |
| | <Robin_Watts> I'm arranging an undo pane that works in the same position as the outline pane. | 16:00.35 |
| | <Robin_Watts> I want to start with "Undo history:" at the top, and then have a list under that. | 16:01.01 |
| | <Robin_Watts> What options to ui_layout do I want? 🙂 | 16:01.14 |
| | <ator> Here's the 100 mile overview of the ui_layout packing: | 16:19.34 |
| | <ator> | 16:19.35 |
| | <ator> We start with a cavity which covers the entire window. Each time we make a new widget, we allocate space by taking some away from the cavity. We always take a full vertical or horizontal slice off of the side of the cavity. | 16:19.36 |
| | <ator> | 16:19.37 |
| | <ator> The 'side' argument says which side of the cavity to take away space from. This is T, B, L, or R. | 16:19.39 |
| | <ator> | 16:19.40 |
| | <ator> The 'fill' argument says how to use the space we carved away for the widget itself, so this is how the widget will be sized inside of the slice. If this is X, Y, or BOTH the widget will stretch to take up the available space. | 16:19.41 |
| | <ator> | 16:19.42 |
| | <ator> If we don't fill up the entire carved out space, the 'anchor' argument says how to align the widget within the space carved out for it. | 16:19.44 |
| | <ator> The layout can be nested, by making the last slice we took be the new cavity. The ui_panel_begin stuff does the push/pop of the sub-cavity. | 16:20.25 |
| | <Robin_Watts> do_outline doesn't use ui_panel_begin, maybe because it's only putting a single thing in? | 16:21.04 |
| | <ator> Yeah. The do_redact_panel and do_annotate_panel may be better examples to look at. | 16:21.39 |
| | <Robin_Watts> Thanks. | 16:22.06 |
| | <ator> the do_annotate_panel call is wrapped in a ui_panel_begin/end in do_main | 16:22.11 |
| | <ator> do_outline just carves out its section from the L side and is only a single widget so doesn't need the panel nesting | 16:22.49 |
| | <Robin_Watts> Ok, I have that sorted. | 16:44.09 |
| | <Robin_Watts> Now I have to sort out why undo/redo isn't changing the document... I suspect I need to get it to reload the annotations or something. | 16:44.33 |
| | <ator> @Robin_Watts you should call render_page() and set selected_annot to NULL | 17:02.52 |
| | <Robin_Watts> I think the problem is on my end. | 17:03.22 |
| | <ator> oh... does the undo/redo reload the page->annots linked list? | 17:04.26 |
| | <ator> or at least run through it again and remove/add mismatches | 17:05.02 |
| | <Robin_Watts> So close. | 17:17.35 |
| | <Robin_Watts> Load the document. Click the tickbox for "Mr" | 17:18.02 |
| | <Robin_Watts> Enter "Robin" | 17:18.05 |
| | <Robin_Watts> Enter "Watts" | 17:18.11 |
| | <Robin_Watts> I correctly see the history listing "Original Document" "Tickbox" "Text Entry" "Text Entry". | 17:18.30 |
| | <Robin_Watts> If I undo 1 step, Watts changes from Sans serif to serif. | 17:18.45 |
| | <Robin_Watts> If I undo another step, Robin vanishes. | 17:18.56 |
| | <Robin_Watts> If I redo, it reappears. Redo again, and Watts changes back to sans-serif. | 17:19.15 |
| | <Robin_Watts> So there is something odd about the last change maybe? | 17:19.29 |
| | <Robin_Watts> Debug makes it look like I'm changing the right thing in the document. | 17:19.48 |
| | <Robin_Watts> If I undo just the last step, and then click in that field, it correctly offers me the empty string initially. | 17:22.18 |
| | <Robin_Watts> Oh, crap. I see the problem. | 18:45.43 |
| | <Robin_Watts> streams aren't part of the object 😦 | 18:45.51 |
| | <Robin_Watts> Muhahaha! Now it works. | 19:03.19 |
| vtorri | ator hello | 19:21.34 |
| artifexirc-bot | <Robin_Watts> vtorri: I suspect you've missed ator for the night. | 19:22.25 |
| vtorri | ator i have a question. I've seen an old message from you in the cairo ML : https://lists.cairographics.org/archives/cairo/2007-August/011136.html | 19:22.36 |
| | Robin_Watts maybe he'll see the message tomorrow | 19:22.58 |
| | ator you said that it would be interesting to test Kiia Kallios ideas | 19:23.48 |
| | ator did you actualy try his ideas with fitz ? | 19:24.09 |
| | <<<Back 1 day (to 2020/11/29) | Forward 1 day (to 2020/12/01)>>> | |
Log of #mupdf at irc.freenode.net.