Eduard, I'm still unable to reproduce the no refresh when dragging fast. There seems to be too many variables involved and lack of consistent test environment.

I think it would help to have an automated way to measure draw throughput and latency.  How about creating a GTest to repeatedly drag an object around? 
But I don't know how GTK test automation works. I see some functions here

https://developer.gnome.org/gtk3/stable/gtk3-Testing.html

but they're deprecated and the reftest that was supposed to replace it also looks out of date.


On Tue, Apr 3, 2018 at 2:26 AM, Yale Zhang <yzhang1985@...400...> wrote:
Sorry everyone for the late response. Hope the Hack fest went well.

Krzysztof, if you're reading this, it's not true that you can't draw to a window any time, outside expose in GTK 3, at least not any more. It's true that gdk_cairo_create() was deprecated, but it was replaced with gdk_window_begin_draw_frame(). So we should still draw directly to the window for minimum latency.

Tim, Krzysztof, a tracing framework would be good for profiling, but LTTng is only for system calls it seems. The latest Visual Studio can show timelines of user space function calls and probably Intel VTune. But I don't know any free profiler that can do that. Plus, it would be good for those functions to be tagged so that a specific sequence of events (mouse event, selection update event, canvas draw, which I did for latency measurement) can be traced.

Tav, Eduard, I think the 1st priority should be to solve the event priority problem that causes the canvas to update slowly or not at all when dragging fast instead of optimizing GTK. According to my earlier benchmarks for GTK_CSD=1, optimizing the GTK windows backend will save only ~3ms / frame. The saving for GTK_CSD=0 will be a lot more though. But the problem is complicated and specific to the Windows back end, so I don't know if the GTK guru is interested.

Earlier, I did pose a more general problem described here, but I didn't discuss it with the GTK folks:
https://stackoverflow.com/questions/48339792/when-drawing-to-a-window-are-the-previous-contents-usually-discarded-and-what


Eduard, I haven't completely digested LRN's findings. It seems consistent with my observations. Let's resume where we left off. On Feb 16, you said my latest patches still caused the canvas to update slowly or not at all when status bar & rulers are on. Generally, I do all my testing with the rendering cache disabled and GTK_CSD=1, so I might've missed that. I tried it again using trunk + my 4 changes, but couldn't reproduce it. This is what I see

https://www.youtube.com/watch?v=voiegK7_YJ0



On Thu, Mar 29, 2018 at 6:26 AM, Tim Mayberry <mojofunk@...400...> wrote:
Hi,

I don't really follow this list closely but I am finding this thread of interest as I have been involved in Ardour(http://ardour.org) development for a while and last year I worked a bit on improving the performance of the canvas Ardour uses and rewrote the multi-threaded waveform image rendering. Ardour currently uses Gtk+2, and will continue do so for some time AFAIK, but I have other projects that use Gtk+3.

I don't know the Inkscape code, and yesterday was the first time I've built it from source (that I can recall). So I'm not in a position to give any advice etc, but over the last few years I've developed an instrumentation/logging library and GUI tool that can be used for performance analysis and execution tracing of multi-threaded code. There are other tools out there but for various reasons I decided to make my own.

I spent a few hours yesterday instrumenting a few classes in the Inkscape code that were mentioned previously and made a little video that may be of interest:


Unfortunately the library/tool doesn't really work on Windows so it wouldn't be helpful there...yet (and I wasn't prepared to spend the time building Inkscape for Windows anyway).

Tim


On Tue, Mar 27, 2018 at 9:11 PM, Tavmjong Bah <tavmjong@...8...> wrote:

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


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...142...ge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel