Hi,
I asked KK about why he made the changes to the rendering code. Here is his response:
-------- Forwarded Message -------- From: Krzysztof Kosiński <tweenk.pl@...400...> To: Tavmjong Bah <tavmjong@...8...> Subject: Re: Inkscape Boston Hackfest Date: Tue, 27 Mar 2018 08:09:07 +0000 X-Proxad-Sc: state=HAM score=0
Before these changes, we would draw directly to the surface exposed by GTK outside the draw signal. This is no longer supported by GTK 3, it is only allowed to draw to the window in the draw signal. To satisfy this requirement, on each draw signal, we blit content that are up to date to the window, then schedule further rendering in the idle callback. The idle callback renders content, then invalidates the window, so that a second draw signal can actually blit the newly rendered content to the GDK window.
If our rendering was fast enough, we could remove the whole system of rendering in the idle callback and render directly in the draw signal. This would have the side effect of removing the visible redrawing in strips, but could increase latency on complex scenes. (On the other hand, the worst files are those with filters with large dependency areas which are rendered over and over for each tile - the overall performance would actually improve for these files.)
In retrospect, the rendering cache is more of a band-aid than an actual solution to rendering performance problems. It might make sense to remove most of it and just keep the offscreen buffer for drawing content, which significantly helps cases like hovering the node tool over a complex drawing, where we just want to draw different controls or path outlines on top.
At one point in the linked thread, Yale mentions the analysis of "parallel timelines" to find performance issues. This is known as a tracing framework and one open source option is LTTng.
[The linked thread was http://inkscape.13.x6.nabble.com/slow-sluggish-drawing-with-pencil-amp- calligraphy-tool-solved-td4981276i20.html ]
Tav
On Tue, 2018-03-27 at 00:07 +0200, Eduard Braun wrote:
Hi Yale, I'm not sure if you've seen my last mail (the one I'm replying to right now) as the sf.net servers were glitchy when I sent it. Regarding the GTK/GDK part of the performance problem there is some movement: LRN did some profiling and I think it matches your observations well and might helpt to investigate this further, see https://bugzilla.gnome.org/show_bug.cgi?id=781153#c14 I'm not sure if you had the chance to talk to GTK devs yet? If not, this might be a good opportunity to exchange the results collected so far and maybe have another shot at resolving the performance issues in GTK itself, which might also make it easier to get consistent results in the Inkscape-specific code. Regards, Eduard