OK, tested. I have good an bad news:
* When rulers are shown the former issue persists (are we drawing rulers with too high priority?) - no redraws at all. * When rulers are hidden performance increased *a lot* (kudos for that!). I'm actually getting redraws now and at smaller window sizes Inkscape actually becomes usable! * Unfortunately even with rulers disabled performance is still nowhere near where it was with 0.92.x. I'm getting less than 10 redraws per second in the scenario where I move a rect in a 2560x1440 window. * What helps a lot is disabling *all* UI elements (Ctrl+F11) which brings performance to an acceptable level (still feels slower than 0.92.x with all UI elements, though!) but obviously does not make Inkscape any more usable...
Regards, Eduard
Am 04.01.2018 um 11:39 schrieb Eduard Braun:
Cool! I will try it this evening.
Any idea why this only seemed to affect Windows with CSD disabled? From your explanation I gather this could have been an issue on any platform.
Best Regards, Eduard
Am 04.01.2018 um 08:17 schrieb Yale Zhang:
OK, I think I've solved the slow dragging problem. Eduard, can you try my latest commit?
There are 4 events involved for dragging it seems:
- GDKEventMouse
- selection modified
generated in Selection::_scheduled_modified() with priority 101 3. redraw generated in SPCanvas::addIdle() with priority 200 calls SPCanvas::paint() which only redraws to *offscreen* buffer 4. refresh/expose generated in gtk_widget_queue_draw_area() with priority 120 calls SPCanvas::handle_draw() which actually updates the screen
For fast redraw response, you want to execute #2, then #3, then #4 as soon as possible. This requires the priorities for each event to be higher than the previous or else mouse events that come later will get processed before earlier redraw,expose events already in the queue. Since this is real time stuff, the longer an event waits in the queue, the higher its priority should be, so this is a priority inversion.
So all I did was change the event priorities.
On Wed, Jan 3, 2018 at 4:53 AM, Yale Zhang <yzhang1985@...400... mailto:yzhang1985@...400...> wrote:
After digging further, I have some questions about how rendering works. At 1st, it seems the lack of refresh when dragging things is because the refresh priority (for calling idle function) is lower than the mouse event priority. This is consistent with the behavior of refresh working only when you move the mouse slowly. I tried changing UPDATE_PRIORITY in sp-canvas.cpp to high, but it didn't help since idle_handler() & SPCanvas::paint() are being called frequently when when dragging rapidly. But why don't the changes show on the screen? Is it drawing to an off screen buffer? I noticed there's a call to gdk_widget_queue_draw_area() that's not in 0.92. What does that do? The documentation says it will generate an expose event for that invalidated area, but that doesn't make sense because why would you invalidate the region right after drawing it. I just need to know where the screen is actually updated. thanks, -yale On Wed, Jan 3, 2018 at 12:34 AM, Yale Zhang <yzhang1985@...400... <mailto:yzhang1985@...400...>> wrote: Correct, the slow refresh when dragging objects is still there. I'm looking into it next since it also kills my productivity. But for now at least, pen & calligraphy responsiveness matches that in 0.92. I use the Wacom pen all the time and with event compression it simply could not keep up with something like signing your name. I've had lots of experience debugging CPU throughput bottlenecks (I've used Linux perf, gprof, Zoom, VTune), but not *latency* ones. Validating real time & parallel behavior is a lot hard from what I heard. I've approached this rather amateurishly so far with good old printf() debugging :) I just recorded the time stamps of a GdkEvent throughout its life cycle from creation, dispatch, and to when it's handled. You could plot all the events on parallel time lines (like in NVIDIA's CUDA profiler) to get a big picture and spot any anomalies (I've made a web app that generates parallel timelines in SVG) but that will probably take too long to study. On Tue, Jan 2, 2018 at 4:07 PM, Eduard Braun <eduard.braun2@...173... <mailto:eduard.braun2@...173...>> wrote: Hi Yale, great to see somebody looking into this! I was looking into motion event compression before and it certainly sounds like something that could improve responsiveness of certain tools in Inkscape. Unfortunately it does not noticeably improve redraw performance in relation to the cited bug for me - as mentioned in the bug report it becomes extremely noticeable with increasing window size and happens for "simple" tasks like moving a rect on canvas. For a 2560x1440 window redrawing basically stops for me while moving the mouse and only resumes once I stop movement of the mouse pointer... I hope we can figure out the source - you certainly seem to be more experienced with profiling tasks (maybe you can give me some pointers on your workflow?) eventually... Best Regards, Eduard Am 31.12.2017 um 10:52 schrieb Yale Zhang:OK, I got developer access now. That was fast. I've created a merge request https://gitlab.com/inkscape/inkscape/merge_requests/169 <https://gitlab.com/inkscape/inkscape/merge_requests/169> On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang <yzhang1985@...400... <mailto:yzhang1985@...400...>> wrote: Hi, I've identified why drawing is lagging with GTK+3. https://bugs.launchpad.net/inkscape/+bug/1723247 <https://bugs.launchpad.net/inkscape/+bug/1723247> It's because of GTK3's motion event compression: https://bugzilla.gnome.org/show_bug.cgi?id=702392 <https://bugzilla.gnome.org/show_bug.cgi?id=702392> Adding a * gdk_window_set_event_compression (window, FALSE);* in SPCanvas::handle_realize() makes things much smoother. At 1st I thought it was because the events were sitting in the queue for too long. So I added some timing code to measure the latency between when a motion event was generated in GDK to when SPCanvas::paint() is called. Actually, I detect bursts of mouse moves or redraws and only use the 1st for latency measurements since there might not be a 1 to 1 relation between motion events and redraws. I was seeing a 4 to 10ms latency for head (GTK3) but only 0.5 ms for 0.92 (GTK2). I thought I was on to something, but this mislead me for a while. Finally, I saw that the # motion events and redraws were 10x higher for GTK2. I haven't stayed up to date with the GitLab migration. I tried to push a patch to my branch simdgenius_inkscape, migrated from Bazaar, but access is denied. I just requested project access, so appreciate it if someone grants it. -Yale ------------------------------------------------------------------------------ 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@lists.sourceforge.net <mailto:Inkscape-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/inkscape-devel <https://lists.sourceforge.net/lists/listinfo/inkscape-devel>
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel