[go: up one dir, main page]

MT enablement 2/4 : Asynchronous rendering for Export Dialog

PBSrequested to merge
pbs3141/inkscape:drawing-snapshotting into master

Short summary

  • Make the export dialog render its document preview off-main-thread. The preview I'm referring to is this one:

    export-preview

  • This gives a slight improvement in gui responsivity while the export dialog is open.

  • It also provides a robustness check for asynchronous rendering, which you can help test by running with INKSCAPE_DEBUG_EXPORTDIALOG_BUSYLOOP=1.

Description

Rationale

This is the second item in the MT enablement series. Whereas the first one was about doing something off the main thread, this one is about doing rendering off the main thread. Of the four, this is the most important and trickiest one. For these reasons, I thought it was important to push these changes early and get them tested in advance.

Its purpose is to make Inkscape's rendering structures thread-safe - without aggressive mutex-locking as in !169 (closed) or other synchronisation costs - and is the base on which all future planned work is built. It is the evolution of this comment, which has since been through three increasingly-simplified iterations before settling on this one.

The main reason for the trickiness is that the object tree is continually modifying the rendering tree from the main thread, making it hard to do anything with it on a different thread. The solution I picked was simply to put those modifications into a queue for later execution.

Although the goal is to eventually apply this to the canvas, that can't be done just yet, so instead I looked for something else in the gui to apply it to. The Export Dialog, while not particularly slow, still has to render the whole document near-constantly during editing, and ideally that should not be done on the gui thread, so I decided to move it off. The other reason for choosing the Export Dialog is that it's constantly redrawing and refreshing while in use, so provides a good robustness check. Finally, unlike the pattern/marker/symbol editors which do XML churning, here the bottleneck is actually rendering.

How to test and what to watch out for

There should be nearly no observable differences with this MR, outside of some very modest speedups in the export dialog - the main goal is for things to work as they did before.

To test, simply interacting with a complicated document while the export dialog is active would be a great help, especially if those interactions involve adding and deleting lots of elements. Hypothetically, a crash would look like a use-after-free in the render thread. To make it easier to discover errors, I have added the environment variable INKSCAPE_DEBUG_EXPORTDIALOG_BUSYLOOP, which causes the export dialog to render continuously in a loop to make it more likely to trigger an error. You can tell if it's working if Inkscape pegs a core. There should be no memory leaks or crashes. Happy testing!

Merge request reports