slow, sluggish drawing with pencil & calligraphy tool solved

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

slow, sluggish drawing with pencil & calligraphy tool solved

Yale Zhang
Hi, I've identified why drawing is lagging with GTK+3.
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

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

Yale Zhang
OK, I got developer access now. That was fast.

I've created a merge request

On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang <[hidden email]> wrote:
Hi, I've identified why drawing is lagging with GTK+3.
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

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

Eduard Braun

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

On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang <[hidden email]> wrote:
Hi, I've identified why drawing is lagging with GTK+3.
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

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

Yale Zhang
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 <[hidden email]> 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

On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang <[hidden email]> wrote:
Hi, I've identified why drawing is lagging with GTK+3.
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

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

Yale Zhang
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 <[hidden email]> 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 <[hidden email]> 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

On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang <[hidden email]> wrote:
Hi, I've identified why drawing is lagging with GTK+3.
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

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

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:
1. GDKEventMouse
2. 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang <[hidden email]> wrote:
Hi, I've identified why drawing is lagging with GTK+3.
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

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

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:
1. GDKEventMouse
2. 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang <[hidden email]> wrote:
Hi, I've identified why drawing is lagging with GTK+3.
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

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

Eduard Braun

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:
1. GDKEventMouse
2. 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang <[hidden email]> wrote:
Hi, I've identified why drawing is lagging with GTK+3.
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

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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

Yale Zhang
In reply to this post by Eduard Braun
Hurray, I've dug much deeper into the problem and have a very good picture of what's slow.

The biggest cause of lag is bzr r14795 (Hackfest 2016: Fix SPCanvas to comply with GTK3 rendering model). That adds 13.7 ms of latency (maybe less without my changes) because instead of sending the rendered canvas immediately to the screen, it schedules a call to SPCanvas::handle_draw() by invalidating the drawn area. I've changed it back to the original method and it cuts the latency from 20 to 11.5 ms. Benchmark attached.

This is still laggy compared to Inkscape 0.92. See this video https://www.youtube.com/watch?v=1tWWeXbDL4U

Next, 0.92 takes only 1 ms for SPCanvas::paint() vs 3 ms for trunk.

An even bigger culprit is that the GTK3 Windows backend is quite inefficient (gdk_window_begin/end_draw_frame() is slow):
*gratuitous creations and deletions of Cairo surfaces and contexts -  the challenge to caching them is detecting when window size changes

*too many buffer copies (see inkscape_render_buffers.svg) -
    a. There's no need to draw to a separate buffer returned by gdk_window_begin_draw_frame() for eliminating tearing because Inkscape already renders to backing store.
       Or you can render directly to that buffer and not have the separate backing store.

    b. GDK should not have to copy from the temporary surface to the window surface in gdk_window_end_draw_frame(). It should use page flipping like in OpenGL and Direct3D. They should add an OpenGL or Direct2D backend for Windows.

    c. The buffer gdk_window_end_draw_frame() copies to might not be the actual screen (DC for Windows). That's the case for layered Windows. There was a recent change to use layered windows for the Windows backend for transparency:

    I have suspicions that Win2k legacy API will be slower than using DWM functions for transparent windows. 
    Also, the reason why GTK_CSD=0 makes things slow on Windows is because it uses a slightly different rendering path:
      1. GTK_CSD=1 -  uses layered windows. Both Cairo surfaces are memory buffers and not actual GPU memory (DC in GDI terms). UpdateLayeredWindow() is used.
      2. GTK_CSD=0 -  seems both surfaces are actual GPU memory. My guesses to why it's slow are:
               i.  gdk_window_end_draw_frame() slow because it has to read the surface back from GPU to CPU memory, only to copy it back to GPU memory?
               ii.  rendering to a Cairo Win32 surface is slow? Cairo on Windows uses pixman for software rendering in CPU memory, but at what granularity does it upload the pixels to GPU memory?
       
*no need for gdk_window_begin_draw_frame() to clear buffer

We're going to have to seriously work with GTK developers to improve rendering speed for Windows. Or is there also a gap on Linux?


On Thu, Jan 4, 2018 at 2:39 AM, Eduard Braun <[hidden email]> wrote:

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:
1. GDKEventMouse
2. 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang <[hidden email]> wrote:
Hi, I've identified why drawing is lagging with GTK+3.
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

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

inkscape_profile.xlsx (16K) Download Attachment
inkscape_render_buffers.svg (17K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

Eduard Braun
Am 08.01.2018 um 14:41 schrieb Yale Zhang:
Hurray, I've dug much deeper into the problem and have a very good picture of what's slow.
Thank you so much for digging into this! It would probably have taken me weeks to figure out only half of it...


The biggest cause of lag is bzr r14795 (Hackfest 2016: Fix SPCanvas to comply with GTK3 rendering model). That adds 13.7 ms of latency (maybe less without my changes) because instead of sending the rendered canvas immediately to the screen, it schedules a call to SPCanvas::handle_draw() by invalidating the drawn area. I've changed it back to the original method and it cuts the latency from 20 to 11.5 ms. Benchmark attached.
Is there any advantage of scheduling a draw here instead of rendering immediately? (i.e. is there any reason for doing it "the gtk3 way"?)
I know we had performance degradation even in gtk2 which is why this code was eventually reverted in 0.92.x branch restoring performance to the status-quo, see https://gitlab.com/inkscape/inkscape/commit/972b7daf0ea9f73b55e0b9e48503a130aefce9f5

*too many buffer copies (see inkscape_render_buffers.svg) -
    a. There's no need to draw to a separate buffer returned by gdk_window_begin_draw_frame() for eliminating tearing because Inkscape already renders to backing store.
       Or you can render directly to that buffer and not have the separate backing store.
This matches the observations in https://bugzilla.gnome.org/show_bug.cgi?id=781153#c8 and following comments.
From what I understand gtk3 always uses double buffering, so probably we could render directly to the buffer without risk for regressions in other environments?

    b. GDK should not have to copy from the temporary surface to the window surface in gdk_window_end_draw_frame(). It should use page flipping like in OpenGL and Direct3D. They should add an OpenGL or Direct2D backend for Windows.
I'm afraid the Windows backend is not under overly active development, so this might be tough to achieve unless we can motivate upstream sufficiently or can implement it ourselves.


    c. The buffer gdk_window_end_draw_frame() copies to might not be the actual screen (DC for Windows). That's the case for layered Windows. There was a recent change to use layered windows for the Windows backend for transparency:

    I have suspicions that Win2k legacy API will be slower than using DWM functions for transparent windows. 
    Also, the reason why GTK_CSD=0 makes things slow on Windows is because it uses a slightly different rendering path:
      1. GTK_CSD=1 -  uses layered windows. Both Cairo surfaces are memory buffers and not actual GPU memory (DC in GDI terms). UpdateLayeredWindow() is used.
      2. GTK_CSD=0 -  seems both surfaces are actual GPU memory. My guesses to why it's slow are:
               i.  gdk_window_end_draw_frame() slow because it has to read the surface back from GPU to CPU memory, only to copy it back to GPU memory?
               ii.  rendering to a Cairo Win32 surface is slow? Cairo on Windows uses pixman for software rendering in CPU memory, but at what granularity does it upload the pixels to GPU memory?
       
*no need for gdk_window_begin_draw_frame() to clear buffer

We're going to have to seriously work with GTK developers to improve rendering speed for Windows.
The most active (only?) GTK developer working on the win32 backend seems to be LRN (author of the commit you linked) and I assume he's our best bet to get feedback.
I'm not sure how much he's willing to help with the GTK_CSD=0 part as it seems upstream is not overly interested in providing native looking apps and therefore mainly cares for the GTK_CSD=1 case and layered windows. On the other hand I can't imagine they'll put obstacles in our way if we can put in sufficient effort...

Regards,
Eduard


On Thu, Jan 4, 2018 at 2:39 AM, Eduard Braun <[hidden email]> wrote:

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:
1. GDKEventMouse
2. 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang <[hidden email]> wrote:
Hi, I've identified why drawing is lagging with GTK+3.
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

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

Yale Zhang
"Is there any advantage of scheduling a draw here instead of rendering immediately? (i.e. is there any reason for doing it "the gtk3 way"?)"

I can't think of any reason other than concurrency issues. If you used OpenGL with GLUT, you'll know that you can't draw in your own thread because the OpenGL context is bound to the UI thread. I did try calling gtk_widget_queue_draw() in SPCanvas::addIdle() and move rendering from doUpdate() to handle_draw() which should theoretically reduce latency, but in practice it's slow because then it causes every widget to be redrawn (see attached stack trace) since you're telling it to invalidate the whole window.

Krzysztof, do you want to explain your changes from Hackfest 2016? It's causing very noticeable lag. Are you OK with reverting them in trunk? I made some changes (https://gitlab.com/inkscape/inkscape/tree/simdgenius_inkscape) that greatly cut the input to display latency from 20 to 11 ms. But it still keeps the backing store you added. It will probably be faster to render directly to the Cairo context & surface returned by gdk_window_begin_draw_frame().

"so this might be tough to achieve unless we can motivate upstream sufficiently or can implement it ourselves."
Right, I don't think anyone cares about Windows GTK except LRN, you, and I. I'm pretty familiar with low level Windows stuff, so I feel up to the task. I think the best way to proceed is to,

1. restore direct rendering in trunk
2. optimize GDK windows backend by not creating and destroying surfaces for every frame draw. Reduce buffer copying.
    Use DWM for transparency instead of the ancient layered windows. That can be a fallback for Windows < 7

3. (optional) see if any benefits to using DXGI or OpenGL surfaces. Earlier I thought they would be faster since they support page flipping instead of copying. But it seems page flipping is only for full screen apps, while for windowed apps, even when you swap buffers with wglSwapBuffers(), it's actually doing a copy.



On Mon, Jan 8, 2018 at 7:30 AM, Eduard Braun <[hidden email]> wrote:
Am 08.01.2018 um 14:41 schrieb Yale Zhang:
Hurray, I've dug much deeper into the problem and have a very good picture of what's slow.
Thank you so much for digging into this! It would probably have taken me weeks to figure out only half of it...


The biggest cause of lag is bzr r14795 (Hackfest 2016: Fix SPCanvas to comply with GTK3 rendering model). That adds 13.7 ms of latency (maybe less without my changes) because instead of sending the rendered canvas immediately to the screen, it schedules a call to SPCanvas::handle_draw() by invalidating the drawn area. I've changed it back to the original method and it cuts the latency from 20 to 11.5 ms. Benchmark attached.
Is there any advantage of scheduling a draw here instead of rendering immediately? (i.e. is there any reason for doing it "the gtk3 way"?)
I know we had performance degradation even in gtk2 which is why this code was eventually reverted in 0.92.x branch restoring performance to the status-quo, see https://gitlab.com/inkscape/inkscape/commit/972b7daf0ea9f73b55e0b9e48503a130aefce9f5

*too many buffer copies (see inkscape_render_buffers.svg) -
    a. There's no need to draw to a separate buffer returned by gdk_window_begin_draw_frame() for eliminating tearing because Inkscape already renders to backing store.
       Or you can render directly to that buffer and not have the separate backing store.
This matches the observations in https://bugzilla.gnome.org/show_bug.cgi?id=781153#c8 and following comments.
From what I understand gtk3 always uses double buffering, so probably we could render directly to the buffer without risk for regressions in other environments?

    b. GDK should not have to copy from the temporary surface to the window surface in gdk_window_end_draw_frame(). It should use page flipping like in OpenGL and Direct3D. They should add an OpenGL or Direct2D backend for Windows.
I'm afraid the Windows backend is not under overly active development, so this might be tough to achieve unless we can motivate upstream sufficiently or can implement it ourselves.


    c. The buffer gdk_window_end_draw_frame() copies to might not be the actual screen (DC for Windows). That's the case for layered Windows. There was a recent change to use layered windows for the Windows backend for transparency:

    I have suspicions that Win2k legacy API will be slower than using DWM functions for transparent windows. 
    Also, the reason why GTK_CSD=0 makes things slow on Windows is because it uses a slightly different rendering path:
      1. GTK_CSD=1 -  uses layered windows. Both Cairo surfaces are memory buffers and not actual GPU memory (DC in GDI terms). UpdateLayeredWindow() is used.
      2. GTK_CSD=0 -  seems both surfaces are actual GPU memory. My guesses to why it's slow are:
               i.  gdk_window_end_draw_frame() slow because it has to read the surface back from GPU to CPU memory, only to copy it back to GPU memory?
               ii.  rendering to a Cairo Win32 surface is slow? Cairo on Windows uses pixman for software rendering in CPU memory, but at what granularity does it upload the pixels to GPU memory?
       
*no need for gdk_window_begin_draw_frame() to clear buffer

We're going to have to seriously work with GTK developers to improve rendering speed for Windows.
The most active (only?) GTK developer working on the win32 backend seems to be LRN (author of the commit you linked) and I assume he's our best bet to get feedback.
I'm not sure how much he's willing to help with the GTK_CSD=0 part as it seems upstream is not overly interested in providing native looking apps and therefore mainly cares for the GTK_CSD=1 case and layered windows. On the other hand I can't imagine they'll put obstacles in our way if we can put in sufficient effort...

Regards,
Eduard



On Thu, Jan 4, 2018 at 2:39 AM, Eduard Braun <[hidden email]> wrote:

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:
1. GDKEventMouse
2. 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang <[hidden email]> wrote:
Hi, I've identified why drawing is lagging with GTK+3.
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

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

handle_draw_stack_trace.txt (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

Eduard Braun
Am 09.01.2018 um 08:58 schrieb Yale Zhang:
"so this might be tough to achieve unless we can motivate upstream sufficiently or can implement it ourselves."
Right, I don't think anyone cares about Windows GTK except LRN, you, and I. I'm pretty familiar with low level Windows stuff, so I feel up to the task.
That is great to hear! Let me know if I can help in any way down the road (testing, etc.).

I think the best way to proceed is to,

1. restore direct rendering in trunk
2. optimize GDK windows backend by not creating and destroying surfaces for every frame draw. Reduce buffer copying.
    Use DWM for transparency instead of the ancient layered windows. That can be a fallback for Windows < 7

3. (optional) see if any benefits to using DXGI or OpenGL surfaces. Earlier I thought they would be faster since they support page flipping instead of copying. But it seems page flipping is only for full screen apps, while for windowed apps, even when you swap buffers with wglSwapBuffers(), it's actually doing a copy.
This sounds like a good plan. As gtk3 has already dropped support for Windows XP we don't have to care for fallbacks.

Regards,
Eduard




On Mon, Jan 8, 2018 at 7:30 AM, Eduard Braun <[hidden email]> wrote:
Am 08.01.2018 um 14:41 schrieb Yale Zhang:
Hurray, I've dug much deeper into the problem and have a very good picture of what's slow.
Thank you so much for digging into this! It would probably have taken me weeks to figure out only half of it...


The biggest cause of lag is bzr r14795 (Hackfest 2016: Fix SPCanvas to comply with GTK3 rendering model). That adds 13.7 ms of latency (maybe less without my changes) because instead of sending the rendered canvas immediately to the screen, it schedules a call to SPCanvas::handle_draw() by invalidating the drawn area. I've changed it back to the original method and it cuts the latency from 20 to 11.5 ms. Benchmark attached.
Is there any advantage of scheduling a draw here instead of rendering immediately? (i.e. is there any reason for doing it "the gtk3 way"?)
I know we had performance degradation even in gtk2 which is why this code was eventually reverted in 0.92.x branch restoring performance to the status-quo, see https://gitlab.com/inkscape/inkscape/commit/972b7daf0ea9f73b55e0b9e48503a130aefce9f5

*too many buffer copies (see inkscape_render_buffers.svg) -
    a. There's no need to draw to a separate buffer returned by gdk_window_begin_draw_frame() for eliminating tearing because Inkscape already renders to backing store.
       Or you can render directly to that buffer and not have the separate backing store.
This matches the observations in https://bugzilla.gnome.org/show_bug.cgi?id=781153#c8 and following comments.
From what I understand gtk3 always uses double buffering, so probably we could render directly to the buffer without risk for regressions in other environments?

    b. GDK should not have to copy from the temporary surface to the window surface in gdk_window_end_draw_frame(). It should use page flipping like in OpenGL and Direct3D. They should add an OpenGL or Direct2D backend for Windows.
I'm afraid the Windows backend is not under overly active development, so this might be tough to achieve unless we can motivate upstream sufficiently or can implement it ourselves.


    c. The buffer gdk_window_end_draw_frame() copies to might not be the actual screen (DC for Windows). That's the case for layered Windows. There was a recent change to use layered windows for the Windows backend for transparency:

    I have suspicions that Win2k legacy API will be slower than using DWM functions for transparent windows. 
    Also, the reason why GTK_CSD=0 makes things slow on Windows is because it uses a slightly different rendering path:
      1. GTK_CSD=1 -  uses layered windows. Both Cairo surfaces are memory buffers and not actual GPU memory (DC in GDI terms). UpdateLayeredWindow() is used.
      2. GTK_CSD=0 -  seems both surfaces are actual GPU memory. My guesses to why it's slow are:
               i.  gdk_window_end_draw_frame() slow because it has to read the surface back from GPU to CPU memory, only to copy it back to GPU memory?
               ii.  rendering to a Cairo Win32 surface is slow? Cairo on Windows uses pixman for software rendering in CPU memory, but at what granularity does it upload the pixels to GPU memory?
       
*no need for gdk_window_begin_draw_frame() to clear buffer

We're going to have to seriously work with GTK developers to improve rendering speed for Windows.
The most active (only?) GTK developer working on the win32 backend seems to be LRN (author of the commit you linked) and I assume he's our best bet to get feedback.
I'm not sure how much he's willing to help with the GTK_CSD=0 part as it seems upstream is not overly interested in providing native looking apps and therefore mainly cares for the GTK_CSD=1 case and layered windows. On the other hand I can't imagine they'll put obstacles in our way if we can put in sufficient effort...

Regards,
Eduard



On Thu, Jan 4, 2018 at 2:39 AM, Eduard Braun <[hidden email]> wrote:

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:
1. GDKEventMouse
2. 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang <[hidden email]> wrote:
Hi, I've identified why drawing is lagging with GTK+3.
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

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

Yale Zhang
I have an update on my progress. I've made these changes which I'm requesting to be merged from my simdgenius_inkscape branch

1. disable event compression (previously mentioned)

2. fix priority inversion (09f55021, previously mentioned) - without this, dragging objects too fast would cause no redraw.

3. draw immediately (78d47938) this partially reverts Krzysztof's Hack fest 2016 changes like in 0.92.  This reduces latency by ~10ms  (compare cells G22 and E22 in spreadsheet)

I originally wanted to remove backing store and draw directly to the window surface, but I ran into this dilema so I didn't do it.



But there is still way more speedup to be had:

1. rendering cache slows things down 6x!  Compare cells E9 & E10 in the spreadsheet.
     WTH?

2. optimize GDK (maybe it's only slow on Windows) - compare cells J17 and J23 
      I made 2 changes:
      a. disabled layered windows - this is almost the same effect as setting GTK_CSD=0. I'm not clear why it speeds things up. I'm guessing it reduces image copying. Layered windows have to draw to CPU memory (GDI DIB), while non-layered windows draw directly to GPU memory (device dependent bitmap)?

      b. replace surface_content = gdk_window_get_content (window);   in gdk_window_begin_paint_internal()
          with surface_content = CAIRO_CONTENT_COLOR_ALPHA

          why create/delete a surface just to get the type?

3. multithreaded rendering - I've updated it to work with trunk, so you can try it. Very little speed up for simple scenes.


-Yale


On Tue, Jan 9, 2018 at 2:23 AM, Eduard Braun <[hidden email]> wrote:
Am 09.01.2018 um 08:58 schrieb Yale Zhang:
"so this might be tough to achieve unless we can motivate upstream sufficiently or can implement it ourselves."
Right, I don't think anyone cares about Windows GTK except LRN, you, and I. I'm pretty familiar with low level Windows stuff, so I feel up to the task.
That is great to hear! Let me know if I can help in any way down the road (testing, etc.).

I think the best way to proceed is to,

1. restore direct rendering in trunk
2. optimize GDK windows backend by not creating and destroying surfaces for every frame draw. Reduce buffer copying.
    Use DWM for transparency instead of the ancient layered windows. That can be a fallback for Windows < 7

3. (optional) see if any benefits to using DXGI or OpenGL surfaces. Earlier I thought they would be faster since they support page flipping instead of copying. But it seems page flipping is only for full screen apps, while for windowed apps, even when you swap buffers with wglSwapBuffers(), it's actually doing a copy.
This sounds like a good plan. As gtk3 has already dropped support for Windows XP we don't have to care for fallbacks.

Regards,
Eduard





On Mon, Jan 8, 2018 at 7:30 AM, Eduard Braun <[hidden email]> wrote:
Am 08.01.2018 um 14:41 schrieb Yale Zhang:
Hurray, I've dug much deeper into the problem and have a very good picture of what's slow.
Thank you so much for digging into this! It would probably have taken me weeks to figure out only half of it...


The biggest cause of lag is bzr r14795 (Hackfest 2016: Fix SPCanvas to comply with GTK3 rendering model). That adds 13.7 ms of latency (maybe less without my changes) because instead of sending the rendered canvas immediately to the screen, it schedules a call to SPCanvas::handle_draw() by invalidating the drawn area. I've changed it back to the original method and it cuts the latency from 20 to 11.5 ms. Benchmark attached.
Is there any advantage of scheduling a draw here instead of rendering immediately? (i.e. is there any reason for doing it "the gtk3 way"?)
I know we had performance degradation even in gtk2 which is why this code was eventually reverted in 0.92.x branch restoring performance to the status-quo, see https://gitlab.com/inkscape/inkscape/commit/972b7daf0ea9f73b55e0b9e48503a130aefce9f5

*too many buffer copies (see inkscape_render_buffers.svg) -
    a. There's no need to draw to a separate buffer returned by gdk_window_begin_draw_frame() for eliminating tearing because Inkscape already renders to backing store.
       Or you can render directly to that buffer and not have the separate backing store.
This matches the observations in https://bugzilla.gnome.org/show_bug.cgi?id=781153#c8 and following comments.
From what I understand gtk3 always uses double buffering, so probably we could render directly to the buffer without risk for regressions in other environments?

    b. GDK should not have to copy from the temporary surface to the window surface in gdk_window_end_draw_frame(). It should use page flipping like in OpenGL and Direct3D. They should add an OpenGL or Direct2D backend for Windows.
I'm afraid the Windows backend is not under overly active development, so this might be tough to achieve unless we can motivate upstream sufficiently or can implement it ourselves.


    c. The buffer gdk_window_end_draw_frame() copies to might not be the actual screen (DC for Windows). That's the case for layered Windows. There was a recent change to use layered windows for the Windows backend for transparency:

    I have suspicions that Win2k legacy API will be slower than using DWM functions for transparent windows. 
    Also, the reason why GTK_CSD=0 makes things slow on Windows is because it uses a slightly different rendering path:
      1. GTK_CSD=1 -  uses layered windows. Both Cairo surfaces are memory buffers and not actual GPU memory (DC in GDI terms). UpdateLayeredWindow() is used.
      2. GTK_CSD=0 -  seems both surfaces are actual GPU memory. My guesses to why it's slow are:
               i.  gdk_window_end_draw_frame() slow because it has to read the surface back from GPU to CPU memory, only to copy it back to GPU memory?
               ii.  rendering to a Cairo Win32 surface is slow? Cairo on Windows uses pixman for software rendering in CPU memory, but at what granularity does it upload the pixels to GPU memory?
       
*no need for gdk_window_begin_draw_frame() to clear buffer

We're going to have to seriously work with GTK developers to improve rendering speed for Windows.
The most active (only?) GTK developer working on the win32 backend seems to be LRN (author of the commit you linked) and I assume he's our best bet to get feedback.
I'm not sure how much he's willing to help with the GTK_CSD=0 part as it seems upstream is not overly interested in providing native looking apps and therefore mainly cares for the GTK_CSD=1 case and layered windows. On the other hand I can't imagine they'll put obstacles in our way if we can put in sufficient effort...

Regards,
Eduard



On Thu, Jan 4, 2018 at 2:39 AM, Eduard Braun <[hidden email]> wrote:

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:
1. GDKEventMouse
2. 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang <[hidden email]> wrote:
Hi, I've identified why drawing is lagging with GTK+3.
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

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

inkscape_profile2.xlsx (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

Eduard Braun

Hi Yale,

thanks for continuing to investigate this! Some comments:


Am 09.02.2018 um 16:02 schrieb Yale Zhang:
I have an update on my progress. I've made these changes which I'm requesting to be merged from my simdgenius_inkscape branch

1. disable event compression (previously mentioned)

2. fix priority inversion (09f55021, previously mentioned) - without this, dragging objects too fast would cause no redraw.

As noted before, when rulers are shown there still is no redraw with this change


3. draw immediately (78d47938) this partially reverts Krzysztof's Hack fest 2016 changes like in 0.92.  This reduces latency by ~10ms  (compare cells G22 and E22 in spreadsheet)

I originally wanted to remove backing store and draw directly to the window surface, but I ran into this dilema so I didn't do it.


While this change does indeed speed up drawing a lot I'm not sure it's for the reason we hope for:
It seems that the immediate drawing of the canvas basically disables drawing of the rest of the UI (i.e. rulers, coordinates in the lower right, coordinates in inputs, etc). If I hide all UI elements (Ctrl+F11) I get the same perceived performance even without your code change.

While I guess redrawing the canvas is to be preferred over redrawing other UI elements, not redrawing the rest of the UI at all is probably not desirable either.
Also it poses the question: Why did gtk2 manage to redraw the canvas *and* the UI and still yield higher performance than gtk3? So I'm not sure we're not still missing the actual regression. :-/


But there is still way more speedup to be had:

1. rendering cache slows things down 6x!  Compare cells E9 & E10 in the spreadsheet.
     WTH?

Is it always slow? I guess for something simple like a rectangle it might not improve things, but maybe things start to change as soon as filters are involved (or many nodes or anything else that is not easy to render)?
I admit I was not involved when the rendering cache was added and do not know its purpose. I tracked down the commit in which it was added [1] which does not explain anything either, though, so I need to continue digging... If anybody knows where the changes are actually explained some feedback is welcome.

[1] https://gitlab.com/inkscape/inkscape/commit/093f4174abc07b4ea523617fccdd8028f2670fea


2. optimize GDK (maybe it's only slow on Windows) - compare cells J17 and J23 
      I made 2 changes:
      a. disabled layered windows - this is almost the same effect as setting GTK_CSD=0. I'm not clear why it speeds things up. I'm guessing it reduces image copying. Layered windows have to draw to CPU memory (GDI DIB), while non-layered windows draw directly to GPU memory (device dependent bitmap)?

      b. replace surface_content = gdk_window_get_content (window);   in gdk_window_begin_paint_internal()
          with surface_content = CAIRO_CONTENT_COLOR_ALPHA

          why create/delete a surface just to get the type?

Have you published this code anywhere? Also is there any upstream discussion on this yet which I could follow?


3. multithreaded rendering - I've updated it to work with trunk, so you can try it. Very little speed up for simple scenes.

Unfortunately the code does not compile for me, excerpt from the error:
    sp-canvas.cpp:802:22: error: passing 'const boost::shared_mutex' as 'this' argument discards qualifiers [-fpermissive]

Do you want us to compile your code with -fpermissive?



-Yale

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

Yale Zhang
appreciate the feedback

"As noted before, when rulers are shown there still is no redraw with this change"
It works for me on Windows with rulers. Could it be some out of date libraries? I'm still using a custom built cross compiler & libraries (GTK 3.22.26 & glib 2.54.2). I know you're using the MSYS 2 prebuilt libraries. I've been wanting to use those too, but how recent are they?

"It seems that the immediate drawing of the canvas basically disables drawing of the rest of the UI"

You scared me, that would be a most grievous mistake. I just tested it again and don't see any problem. The rulers and status bar still work when dragging an object. Did you build my stream directly or have any other non-trunk changes? Sorry to suggest this but here are binaries you can test. Maybe try copying the GTK & cairo? libs to your build.

I hope you're not suggesting to forget about immediate drawing and just fix the drawing priorities. Using priorities would be easier to break, while drawing immediately is fool proof.

"Have you published [GTK3] code anywhere? "
No, I haven't had time yet. I also want to discuss the problem I posed on StackOverflow and someone suggested IRC, but that I've never used IRC and it sounds very 1990s.

BTW, the optimized GTK also disables clearing the region to be drawn (gdk_window_clear_backing_region()).

"Is [render cache] always slow?"
It's only much slower if drawing a big area AND the scene complexity is low. For small areas and high complexity scenes, the overhead is much less noticeable.

For the multithreaded rendering, it's still a work in progress. AFAIK, I've eliminated all the race conditions with ThreadSanitizer, so it should be stable.
I just pushed some further changes to allow the rendering to be incremental like it always has been. It should have that -fpermissive compile error in sp-canvas.cpp fixed, but you might still need it for other files.





On Sun, Feb 11, 2018 at 8:37 AM, Eduard Braun <[hidden email]> wrote:

Hi Yale,

thanks for continuing to investigate this! Some comments:


Am 09.02.2018 um 16:02 schrieb Yale Zhang:
I have an update on my progress. I've made these changes which I'm requesting to be merged from my simdgenius_inkscape branch

1. disable event compression (previously mentioned)

2. fix priority inversion (09f55021, previously mentioned) - without this, dragging objects too fast would cause no redraw.

As noted before, when rulers are shown there still is no redraw with this change


3. draw immediately (78d47938) this partially reverts Krzysztof's Hack fest 2016 changes like in 0.92.  This reduces latency by ~10ms  (compare cells G22 and E22 in spreadsheet)

I originally wanted to remove backing store and draw directly to the window surface, but I ran into this dilema so I didn't do it.


While this change does indeed speed up drawing a lot I'm not sure it's for the reason we hope for:
It seems that the immediate drawing of the canvas basically disables drawing of the rest of the UI (i.e. rulers, coordinates in the lower right, coordinates in inputs, etc). If I hide all UI elements (Ctrl+F11) I get the same perceived performance even without your code change.

While I guess redrawing the canvas is to be preferred over redrawing other UI elements, not redrawing the rest of the UI at all is probably not desirable either.
Also it poses the question: Why did gtk2 manage to redraw the canvas *and* the UI and still yield higher performance than gtk3? So I'm not sure we're not still missing the actual regression. :-/


But there is still way more speedup to be had:

1. rendering cache slows things down 6x!  Compare cells E9 & E10 in the spreadsheet.
     WTH?

Is it always slow? I guess for something simple like a rectangle it might not improve things, but maybe things start to change as soon as filters are involved (or many nodes or anything else that is not easy to render)?
I admit I was not involved when the rendering cache was added and do not know its purpose. I tracked down the commit in which it was added [1] which does not explain anything either, though, so I need to continue digging... If anybody knows where the changes are actually explained some feedback is welcome.

[1] https://gitlab.com/inkscape/inkscape/commit/093f4174abc07b4ea523617fccdd8028f2670fea


2. optimize GDK (maybe it's only slow on Windows) - compare cells J17 and J23 
      I made 2 changes:
      a. disabled layered windows - this is almost the same effect as setting GTK_CSD=0. I'm not clear why it speeds things up. I'm guessing it reduces image copying. Layered windows have to draw to CPU memory (GDI DIB), while non-layered windows draw directly to GPU memory (device dependent bitmap)?

      b. replace surface_content = gdk_window_get_content (window);   in gdk_window_begin_paint_internal()
          with surface_content = CAIRO_CONTENT_COLOR_ALPHA

          why create/delete a surface just to get the type?

Have you published this code anywhere? Also is there any upstream discussion on this yet which I could follow?


3. multithreaded rendering - I've updated it to work with trunk, so you can try it. Very little speed up for simple scenes.

Unfortunately the code does not compile for me, excerpt from the error:
    sp-canvas.cpp:802:22: error: passing 'const boost::shared_mutex' as 'this' argument discards qualifiers [-fpermissive]

Do you want us to compile your code with -fpermissive?



-Yale

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

Yale Zhang
Also, I confirm that turning off just the status bar (while enabling ruler & everything else) can achieve the same latency reduction my change #3 makes.

I tried to find the code that draws the status bar (with cursor X,Y position), but I couldn't find it.

On Mon, Feb 12, 2018 at 1:15 AM, Yale Zhang <[hidden email]> wrote:
appreciate the feedback

"As noted before, when rulers are shown there still is no redraw with this change"
It works for me on Windows with rulers. Could it be some out of date libraries? I'm still using a custom built cross compiler & libraries (GTK 3.22.26 & glib 2.54.2). I know you're using the MSYS 2 prebuilt libraries. I've been wanting to use those too, but how recent are they?

"It seems that the immediate drawing of the canvas basically disables drawing of the rest of the UI"

You scared me, that would be a most grievous mistake. I just tested it again and don't see any problem. The rulers and status bar still work when dragging an object. Did you build my stream directly or have any other non-trunk changes? Sorry to suggest this but here are binaries you can test. Maybe try copying the GTK & cairo? libs to your build.

I hope you're not suggesting to forget about immediate drawing and just fix the drawing priorities. Using priorities would be easier to break, while drawing immediately is fool proof.

"Have you published [GTK3] code anywhere? "
No, I haven't had time yet. I also want to discuss the problem I posed on StackOverflow and someone suggested IRC, but that I've never used IRC and it sounds very 1990s.

BTW, the optimized GTK also disables clearing the region to be drawn (gdk_window_clear_backing_region()).

"Is [render cache] always slow?"
It's only much slower if drawing a big area AND the scene complexity is low. For small areas and high complexity scenes, the overhead is much less noticeable.

For the multithreaded rendering, it's still a work in progress. AFAIK, I've eliminated all the race conditions with ThreadSanitizer, so it should be stable.
I just pushed some further changes to allow the rendering to be incremental like it always has been. It should have that -fpermissive compile error in sp-canvas.cpp fixed, but you might still need it for other files.





On Sun, Feb 11, 2018 at 8:37 AM, Eduard Braun <[hidden email]> wrote:

Hi Yale,

thanks for continuing to investigate this! Some comments:


Am 09.02.2018 um 16:02 schrieb Yale Zhang:
I have an update on my progress. I've made these changes which I'm requesting to be merged from my simdgenius_inkscape branch

1. disable event compression (previously mentioned)

2. fix priority inversion (09f55021, previously mentioned) - without this, dragging objects too fast would cause no redraw.

As noted before, when rulers are shown there still is no redraw with this change


3. draw immediately (78d47938) this partially reverts Krzysztof's Hack fest 2016 changes like in 0.92.  This reduces latency by ~10ms  (compare cells G22 and E22 in spreadsheet)

I originally wanted to remove backing store and draw directly to the window surface, but I ran into this dilema so I didn't do it.


While this change does indeed speed up drawing a lot I'm not sure it's for the reason we hope for:
It seems that the immediate drawing of the canvas basically disables drawing of the rest of the UI (i.e. rulers, coordinates in the lower right, coordinates in inputs, etc). If I hide all UI elements (Ctrl+F11) I get the same perceived performance even without your code change.

While I guess redrawing the canvas is to be preferred over redrawing other UI elements, not redrawing the rest of the UI at all is probably not desirable either.
Also it poses the question: Why did gtk2 manage to redraw the canvas *and* the UI and still yield higher performance than gtk3? So I'm not sure we're not still missing the actual regression. :-/


But there is still way more speedup to be had:

1. rendering cache slows things down 6x!  Compare cells E9 & E10 in the spreadsheet.
     WTH?

Is it always slow? I guess for something simple like a rectangle it might not improve things, but maybe things start to change as soon as filters are involved (or many nodes or anything else that is not easy to render)?
I admit I was not involved when the rendering cache was added and do not know its purpose. I tracked down the commit in which it was added [1] which does not explain anything either, though, so I need to continue digging... If anybody knows where the changes are actually explained some feedback is welcome.

[1] https://gitlab.com/inkscape/inkscape/commit/093f4174abc07b4ea523617fccdd8028f2670fea


2. optimize GDK (maybe it's only slow on Windows) - compare cells J17 and J23 
      I made 2 changes:
      a. disabled layered windows - this is almost the same effect as setting GTK_CSD=0. I'm not clear why it speeds things up. I'm guessing it reduces image copying. Layered windows have to draw to CPU memory (GDI DIB), while non-layered windows draw directly to GPU memory (device dependent bitmap)?

      b. replace surface_content = gdk_window_get_content (window);   in gdk_window_begin_paint_internal()
          with surface_content = CAIRO_CONTENT_COLOR_ALPHA

          why create/delete a surface just to get the type?

Have you published this code anywhere? Also is there any upstream discussion on this yet which I could follow?


3. multithreaded rendering - I've updated it to work with trunk, so you can try it. Very little speed up for simple scenes.

Unfortunately the code does not compile for me, excerpt from the error:
    sp-canvas.cpp:802:22: error: passing 'const boost::shared_mutex' as 'this' argument discards qualifiers [-fpermissive]

Do you want us to compile your code with -fpermissive?



-Yale

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

Eduard Braun
In reply to this post by Yale Zhang
Am 12.02.2018 um 10:15 schrieb Yale Zhang:
"As noted before, when rulers are shown there still is no redraw with this change"
It works for me on Windows with rulers. Could it be some out of date libraries? I'm still using a custom built cross compiler & libraries (GTK 3.22.26 & glib 2.54.2). I know you're using the MSYS 2 prebuilt libraries. I've been wanting to use those too, but how recent are they?

They are usually the latest available (think of MSYS2's MINGW-packages as arch Linux for Windows), right now gtk 3.22.26 and glib 2.54.3.

Aside from disabling CSD they are unpatched. Just to make sure we're not comparing apples and oranges: Are you using CSD in your builds or not? This switch made a huge difference before, so if you're working with CSD enabled this might be the likely explanation why some things work in your builds that do not work in the stock builds.


"It seems that the immediate drawing of the canvas basically disables drawing of the rest of the UI"

You scared me, that would be a most grievous mistake. I just tested it again and don't see any problem. The rulers and status bar still work when dragging an object. Did you build my stream directly or have any other non-trunk changes? Sorry to suggest this but here are binaries you can test. Maybe try copying the GTK & cairo? libs to your build.

I used https://gitlab.com/inkscape/inkscape/commit/78d47938194fc52ee085387d9a0dc0753f3ed6d9 as the later commits did not compile for me.

I'll check your build this evening.

We also have CI builds with MSYS2 available: https://ci.appveyor.com/project/inkscape/inkscape/history
If you rebase your branch on master your branch will be built, too (as long as there are not more errors/warnings preventing the build)

I hope you're not suggesting to forget about immediate drawing and just fix the drawing priorities. Using priorities would be easier to break, while drawing immediately is fool proof.

I'm just saying that priorities have been tweaked before to make all UI update properly and we should aim to retain this state.
If direct drawing is compatible with this goal (I guess it was in gtk2) that's probably fine.


"Have you published [GTK3] code anywhere? "
No, I haven't had time yet. I also want to discuss the problem I posed on StackOverflow and someone suggested IRC, but that I've never used IRC and it sounds very 1990s.

It's like SMS... it just works (even today)...
A lot easier than all the modern stuff that claims to be easier than IRC.

I've talked to gtk devs on IRC before and it's the easiest way to get some interaction (bug reports usually fall into oblivion sooner rather than later).


BTW, the optimized GTK also disables clearing the region to be drawn (gdk_window_clear_backing_region()).

"Is [render cache] always slow?"
It's only much slower if drawing a big area AND the scene complexity is low. For small areas and high complexity scenes, the overhead is much less noticeable.

I see... I guess before the low complexity scenes were not that important as redraw times were sufficiently fast anyway.
User reports of slow redrawing usually involve blurs (or less frequently other filters).


For the multithreaded rendering, it's still a work in progress. AFAIK, I've eliminated all the race conditions with ThreadSanitizer, so it should be stable.
I just pushed some further changes to allow the rendering to be incremental like it always has been. It should have that -fpermissive compile error in sp-canvas.cpp fixed, but you might still need it for other files.

I'll try to build this evening.
As recommended before you could check the CI to make sure your branch is properly built, which should help with testing.

Regards,
Eduard






On Sun, Feb 11, 2018 at 8:37 AM, Eduard Braun <[hidden email]> wrote:

Hi Yale,

thanks for continuing to investigate this! Some comments:


Am 09.02.2018 um 16:02 schrieb Yale Zhang:
I have an update on my progress. I've made these changes which I'm requesting to be merged from my simdgenius_inkscape branch

1. disable event compression (previously mentioned)

2. fix priority inversion (09f55021, previously mentioned) - without this, dragging objects too fast would cause no redraw.

As noted before, when rulers are shown there still is no redraw with this change


3. draw immediately (78d47938) this partially reverts Krzysztof's Hack fest 2016 changes like in 0.92.  This reduces latency by ~10ms  (compare cells G22 and E22 in spreadsheet)

I originally wanted to remove backing store and draw directly to the window surface, but I ran into this dilema so I didn't do it.


While this change does indeed speed up drawing a lot I'm not sure it's for the reason we hope for:
It seems that the immediate drawing of the canvas basically disables drawing of the rest of the UI (i.e. rulers, coordinates in the lower right, coordinates in inputs, etc). If I hide all UI elements (Ctrl+F11) I get the same perceived performance even without your code change.

While I guess redrawing the canvas is to be preferred over redrawing other UI elements, not redrawing the rest of the UI at all is probably not desirable either.
Also it poses the question: Why did gtk2 manage to redraw the canvas *and* the UI and still yield higher performance than gtk3? So I'm not sure we're not still missing the actual regression. :-/


But there is still way more speedup to be had:

1. rendering cache slows things down 6x!  Compare cells E9 & E10 in the spreadsheet.
     WTH?

Is it always slow? I guess for something simple like a rectangle it might not improve things, but maybe things start to change as soon as filters are involved (or many nodes or anything else that is not easy to render)?
I admit I was not involved when the rendering cache was added and do not know its purpose. I tracked down the commit in which it was added [1] which does not explain anything either, though, so I need to continue digging... If anybody knows where the changes are actually explained some feedback is welcome.

[1] https://gitlab.com/inkscape/inkscape/commit/093f4174abc07b4ea523617fccdd8028f2670fea


2. optimize GDK (maybe it's only slow on Windows) - compare cells J17 and J23 
      I made 2 changes:
      a. disabled layered windows - this is almost the same effect as setting GTK_CSD=0. I'm not clear why it speeds things up. I'm guessing it reduces image copying. Layered windows have to draw to CPU memory (GDI DIB), while non-layered windows draw directly to GPU memory (device dependent bitmap)?

      b. replace surface_content = gdk_window_get_content (window);   in gdk_window_begin_paint_internal()
          with surface_content = CAIRO_CONTENT_COLOR_ALPHA

          why create/delete a surface just to get the type?

Have you published this code anywhere? Also is there any upstream discussion on this yet which I could follow?


3. multithreaded rendering - I've updated it to work with trunk, so you can try it. Very little speed up for simple scenes.

Unfortunately the code does not compile for me, excerpt from the error:
    sp-canvas.cpp:802:22: error: passing 'const boost::shared_mutex' as 'this' argument discards qualifiers [-fpermissive]

Do you want us to compile your code with -fpermissive?



-Yale

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

Yale Zhang
Eduard, please pull change #2 (fix priority inversion) before the immediate rendering changes. Without it, the lack of status bar & ruler updates are expected.

Yes, I am using CSD=1 in my testing (for both optimized & original GTK). But CSD isn't the actual reason for performance difference. It's because of the rendering code path CSD=1 uses (draw to CPU memory buffer, then send to UpdateLayeredWindow()), vs CSD=0  (draw directly to GDI device context - surprisingly this is slower until my optimizations).

I did get an error from the CI build after the multithreaded rendering feature. It doesn't even get past CMake configure stage, so not very useful. That's because the build server doesn't have the Boost libs (which I use, not just the headers).



On Mon, Feb 12, 2018 at 2:41 AM, Eduard Braun <[hidden email]> wrote:
Am 12.02.2018 um 10:15 schrieb Yale Zhang:
"As noted before, when rulers are shown there still is no redraw with this change"
It works for me on Windows with rulers. Could it be some out of date libraries? I'm still using a custom built cross compiler & libraries (GTK 3.22.26 & glib 2.54.2). I know you're using the MSYS 2 prebuilt libraries. I've been wanting to use those too, but how recent are they?

They are usually the latest available (think of MSYS2's MINGW-packages as arch Linux for Windows), right now gtk 3.22.26 and glib 2.54.3.

Aside from disabling CSD they are unpatched. Just to make sure we're not comparing apples and oranges: Are you using CSD in your builds or not? This switch made a huge difference before, so if you're working with CSD enabled this might be the likely explanation why some things work in your builds that do not work in the stock builds.


"It seems that the immediate drawing of the canvas basically disables drawing of the rest of the UI"

You scared me, that would be a most grievous mistake. I just tested it again and don't see any problem. The rulers and status bar still work when dragging an object. Did you build my stream directly or have any other non-trunk changes? Sorry to suggest this but here are binaries you can test. Maybe try copying the GTK & cairo? libs to your build.

I used https://gitlab.com/inkscape/inkscape/commit/78d47938194fc52ee085387d9a0dc0753f3ed6d9 as the later commits did not compile for me.

I'll check your build this evening.

We also have CI builds with MSYS2 available: https://ci.appveyor.com/project/inkscape/inkscape/history
If you rebase your branch on master your branch will be built, too (as long as there are not more errors/warnings preventing the build)

I hope you're not suggesting to forget about immediate drawing and just fix the drawing priorities. Using priorities would be easier to break, while drawing immediately is fool proof.

I'm just saying that priorities have been tweaked before to make all UI update properly and we should aim to retain this state.
If direct drawing is compatible with this goal (I guess it was in gtk2) that's probably fine.


"Have you published [GTK3] code anywhere? "
No, I haven't had time yet. I also want to discuss the problem I posed on StackOverflow and someone suggested IRC, but that I've never used IRC and it sounds very 1990s.

It's like SMS... it just works (even today)...
A lot easier than all the modern stuff that claims to be easier than IRC.

I've talked to gtk devs on IRC before and it's the easiest way to get some interaction (bug reports usually fall into oblivion sooner rather than later).


BTW, the optimized GTK also disables clearing the region to be drawn (gdk_window_clear_backing_region()).

"Is [render cache] always slow?"
It's only much slower if drawing a big area AND the scene complexity is low. For small areas and high complexity scenes, the overhead is much less noticeable.

I see... I guess before the low complexity scenes were not that important as redraw times were sufficiently fast anyway.
User reports of slow redrawing usually involve blurs (or less frequently other filters).


For the multithreaded rendering, it's still a work in progress. AFAIK, I've eliminated all the race conditions with ThreadSanitizer, so it should be stable.
I just pushed some further changes to allow the rendering to be incremental like it always has been. It should have that -fpermissive compile error in sp-canvas.cpp fixed, but you might still need it for other files.

I'll try to build this evening.
As recommended before you could check the CI to make sure your branch is properly built, which should help with testing.

Regards,
Eduard







On Sun, Feb 11, 2018 at 8:37 AM, Eduard Braun <[hidden email]> wrote:

Hi Yale,

thanks for continuing to investigate this! Some comments:


Am 09.02.2018 um 16:02 schrieb Yale Zhang:
I have an update on my progress. I've made these changes which I'm requesting to be merged from my simdgenius_inkscape branch

1. disable event compression (previously mentioned)

2. fix priority inversion (09f55021, previously mentioned) - without this, dragging objects too fast would cause no redraw.

As noted before, when rulers are shown there still is no redraw with this change


3. draw immediately (78d47938) this partially reverts Krzysztof's Hack fest 2016 changes like in 0.92.  This reduces latency by ~10ms  (compare cells G22 and E22 in spreadsheet)

I originally wanted to remove backing store and draw directly to the window surface, but I ran into this dilema so I didn't do it.


While this change does indeed speed up drawing a lot I'm not sure it's for the reason we hope for:
It seems that the immediate drawing of the canvas basically disables drawing of the rest of the UI (i.e. rulers, coordinates in the lower right, coordinates in inputs, etc). If I hide all UI elements (Ctrl+F11) I get the same perceived performance even without your code change.

While I guess redrawing the canvas is to be preferred over redrawing other UI elements, not redrawing the rest of the UI at all is probably not desirable either.
Also it poses the question: Why did gtk2 manage to redraw the canvas *and* the UI and still yield higher performance than gtk3? So I'm not sure we're not still missing the actual regression. :-/


But there is still way more speedup to be had:

1. rendering cache slows things down 6x!  Compare cells E9 & E10 in the spreadsheet.
     WTH?

Is it always slow? I guess for something simple like a rectangle it might not improve things, but maybe things start to change as soon as filters are involved (or many nodes or anything else that is not easy to render)?
I admit I was not involved when the rendering cache was added and do not know its purpose. I tracked down the commit in which it was added [1] which does not explain anything either, though, so I need to continue digging... If anybody knows where the changes are actually explained some feedback is welcome.

[1] https://gitlab.com/inkscape/inkscape/commit/093f4174abc07b4ea523617fccdd8028f2670fea


2. optimize GDK (maybe it's only slow on Windows) - compare cells J17 and J23 
      I made 2 changes:
      a. disabled layered windows - this is almost the same effect as setting GTK_CSD=0. I'm not clear why it speeds things up. I'm guessing it reduces image copying. Layered windows have to draw to CPU memory (GDI DIB), while non-layered windows draw directly to GPU memory (device dependent bitmap)?

      b. replace surface_content = gdk_window_get_content (window);   in gdk_window_begin_paint_internal()
          with surface_content = CAIRO_CONTENT_COLOR_ALPHA

          why create/delete a surface just to get the type?

Have you published this code anywhere? Also is there any upstream discussion on this yet which I could follow?


3. multithreaded rendering - I've updated it to work with trunk, so you can try it. Very little speed up for simple scenes.

Unfortunately the code does not compile for me, excerpt from the error:
    sp-canvas.cpp:802:22: error: passing 'const boost::shared_mutex' as 'this' argument discards qualifiers [-fpermissive]

Do you want us to compile your code with -fpermissive?



-Yale

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

Eduard Braun
Am 12.02.2018 um 13:12 schrieb Yale Zhang:
Eduard, please pull change #2 (fix priority inversion) before the immediate rendering changes. Without it, the lack of status bar & ruler updates are expected.

I think we're running in circles here... Most of my comments (as well as yours regarding direct drawing) referred to #3.
The only issue I had with #2 was that Rulers seem still to be updated with a high priority and prevented the canvas to redraw (in stock MSYS2 builds and therefore with CSD=0).


Yes, I am using CSD=1 in my testing (for both optimized & original GTK). But CSD isn't the actual reason for performance difference. It's because of the rendering code path CSD=1 uses (draw to CPU memory buffer, then send to UpdateLayeredWindow()), vs CSD=0  (draw directly to GDI device context - surprisingly this is slower until my optimizations).

Please note that CSD=0/1 in our stock MSYS2 builds makes a *huge* difference. If that is really not the case for your custom builds we might want to start looking into that, too. Maybe we're facing at a more fundamental difference. As MSYS2 is the official way to get GTK+ for Windows nowadays such a difference might be very relevant for many projects.

Are your cross-compiled libraries using mingw-w64? Which OS are you using btw? (I'm usually testing on Windows 10 - I'd not be surprised if there's some major difference compared to e.g. Windows 7 wrt to the low level drawing functions).

I'm very interested in testing your GDK-modifications and see how they behave with the MSYS2 builds, so if you could drop a patch somewhere that would be much appreciated!

I did get an error from the CI build after the multithreaded rendering feature. It doesn't even get past CMake configure stage, so not very useful. That's because the build server doesn't have the Boost libs (which I use, not just the headers).

I think you looked at the Linux build - Windows CI is "external" via AppVeyor and has the required Boost libraries. It's just not working in your branch right now because an upstream update broke updating but I pushed a workaround for this already in the master branch [1] (that's why I suggested to rebase)

[1] https://gitlab.com/inkscape/inkscape/commit/85d7fa343f477d8faae6cbde90ae7a243115fa37 (I messed up the rebase so it's authored by Tav, sorry for that)




On Mon, Feb 12, 2018 at 2:41 AM, Eduard Braun <[hidden email]> wrote:
Am 12.02.2018 um 10:15 schrieb Yale Zhang:
"As noted before, when rulers are shown there still is no redraw with this change"
It works for me on Windows with rulers. Could it be some out of date libraries? I'm still using a custom built cross compiler & libraries (GTK 3.22.26 & glib 2.54.2). I know you're using the MSYS 2 prebuilt libraries. I've been wanting to use those too, but how recent are they?

They are usually the latest available (think of MSYS2's MINGW-packages as arch Linux for Windows), right now gtk 3.22.26 and glib 2.54.3.

Aside from disabling CSD they are unpatched. Just to make sure we're not comparing apples and oranges: Are you using CSD in your builds or not? This switch made a huge difference before, so if you're working with CSD enabled this might be the likely explanation why some things work in your builds that do not work in the stock builds.


"It seems that the immediate drawing of the canvas basically disables drawing of the rest of the UI"

You scared me, that would be a most grievous mistake. I just tested it again and don't see any problem. The rulers and status bar still work when dragging an object. Did you build my stream directly or have any other non-trunk changes? Sorry to suggest this but here are binaries you can test. Maybe try copying the GTK & cairo? libs to your build.

I used https://gitlab.com/inkscape/inkscape/commit/78d47938194fc52ee085387d9a0dc0753f3ed6d9 as the later commits did not compile for me.

I'll check your build this evening.

We also have CI builds with MSYS2 available: https://ci.appveyor.com/project/inkscape/inkscape/history
If you rebase your branch on master your branch will be built, too (as long as there are not more errors/warnings preventing the build)

I hope you're not suggesting to forget about immediate drawing and just fix the drawing priorities. Using priorities would be easier to break, while drawing immediately is fool proof.

I'm just saying that priorities have been tweaked before to make all UI update properly and we should aim to retain this state.
If direct drawing is compatible with this goal (I guess it was in gtk2) that's probably fine.


"Have you published [GTK3] code anywhere? "
No, I haven't had time yet. I also want to discuss the problem I posed on StackOverflow and someone suggested IRC, but that I've never used IRC and it sounds very 1990s.

It's like SMS... it just works (even today)...
A lot easier than all the modern stuff that claims to be easier than IRC.

I've talked to gtk devs on IRC before and it's the easiest way to get some interaction (bug reports usually fall into oblivion sooner rather than later).


BTW, the optimized GTK also disables clearing the region to be drawn (gdk_window_clear_backing_region()).

"Is [render cache] always slow?"
It's only much slower if drawing a big area AND the scene complexity is low. For small areas and high complexity scenes, the overhead is much less noticeable.

I see... I guess before the low complexity scenes were not that important as redraw times were sufficiently fast anyway.
User reports of slow redrawing usually involve blurs (or less frequently other filters).


For the multithreaded rendering, it's still a work in progress. AFAIK, I've eliminated all the race conditions with ThreadSanitizer, so it should be stable.
I just pushed some further changes to allow the rendering to be incremental like it always has been. It should have that -fpermissive compile error in sp-canvas.cpp fixed, but you might still need it for other files.

I'll try to build this evening.
As recommended before you could check the CI to make sure your branch is properly built, which should help with testing.

Regards,
Eduard







On Sun, Feb 11, 2018 at 8:37 AM, Eduard Braun <[hidden email]> wrote:

Hi Yale,

thanks for continuing to investigate this! Some comments:


Am 09.02.2018 um 16:02 schrieb Yale Zhang:
I have an update on my progress. I've made these changes which I'm requesting to be merged from my simdgenius_inkscape branch

1. disable event compression (previously mentioned)

2. fix priority inversion (09f55021, previously mentioned) - without this, dragging objects too fast would cause no redraw.

As noted before, when rulers are shown there still is no redraw with this change


3. draw immediately (78d47938) this partially reverts Krzysztof's Hack fest 2016 changes like in 0.92.  This reduces latency by ~10ms  (compare cells G22 and E22 in spreadsheet)

I originally wanted to remove backing store and draw directly to the window surface, but I ran into this dilema so I didn't do it.


While this change does indeed speed up drawing a lot I'm not sure it's for the reason we hope for:
It seems that the immediate drawing of the canvas basically disables drawing of the rest of the UI (i.e. rulers, coordinates in the lower right, coordinates in inputs, etc). If I hide all UI elements (Ctrl+F11) I get the same perceived performance even without your code change.

While I guess redrawing the canvas is to be preferred over redrawing other UI elements, not redrawing the rest of the UI at all is probably not desirable either.
Also it poses the question: Why did gtk2 manage to redraw the canvas *and* the UI and still yield higher performance than gtk3? So I'm not sure we're not still missing the actual regression. :-/


But there is still way more speedup to be had:

1. rendering cache slows things down 6x!  Compare cells E9 & E10 in the spreadsheet.
     WTH?

Is it always slow? I guess for something simple like a rectangle it might not improve things, but maybe things start to change as soon as filters are involved (or many nodes or anything else that is not easy to render)?
I admit I was not involved when the rendering cache was added and do not know its purpose. I tracked down the commit in which it was added [1] which does not explain anything either, though, so I need to continue digging... If anybody knows where the changes are actually explained some feedback is welcome.

[1] https://gitlab.com/inkscape/inkscape/commit/093f4174abc07b4ea523617fccdd8028f2670fea


2. optimize GDK (maybe it's only slow on Windows) - compare cells J17 and J23 
      I made 2 changes:
      a. disabled layered windows - this is almost the same effect as setting GTK_CSD=0. I'm not clear why it speeds things up. I'm guessing it reduces image copying. Layered windows have to draw to CPU memory (GDI DIB), while non-layered windows draw directly to GPU memory (device dependent bitmap)?

      b. replace surface_content = gdk_window_get_content (window);   in gdk_window_begin_paint_internal()
          with surface_content = CAIRO_CONTENT_COLOR_ALPHA

          why create/delete a surface just to get the type?

Have you published this code anywhere? Also is there any upstream discussion on this yet which I could follow?


3. multithreaded rendering - I've updated it to work with trunk, so you can try it. Very little speed up for simple scenes.

Unfortunately the code does not compile for me, excerpt from the error:
    sp-canvas.cpp:802:22: error: passing 'const boost::shared_mutex' as 'this' argument discards qualifiers [-fpermissive]

Do you want us to compile your code with -fpermissive?



-Yale

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: slow, sluggish drawing with pencil & calligraphy tool solved

Eduard Braun

I was now able to build 0bde236

  • With the status bar visible I'm getting super fast redraws of the status bar with some occasional redraws of the rulers but everything else is locked when moving a rect.
  • With the status bar hidden I'm getting more redraws now and also infrequent redraws of the whole UI, however moving the rect is still extremely sluggish.
  • With the status bar and rulers hidden moving the rect has a usable redraw speed, rest of the UI (now only values in select toolbar I guess) update infrequently.

Comparing with your build linked before (warn me next time it's not relocatable, I had to move it to C:\Users\Yale\inkscape.gmesh ;-) ) there are some grave differences:

  • Redraw is in fact much faster with your version - are these the gdk changes? Or are we really on to something fundamental?
    This is also true for GTK_CSD=0!
  • Also the rest of the UI is updated much more frequently, even with the status bar visible
  • In your version I'm not able to resize the Window (or rather I can but the parts that were not shown initially are not redrawn and only show some graphical garbage. Is this related to you gdk changes?

Am 12.02.2018 um 13:57 schrieb Eduard Braun:
Am 12.02.2018 um 13:12 schrieb Yale Zhang:
Eduard, please pull change #2 (fix priority inversion) before the immediate rendering changes. Without it, the lack of status bar & ruler updates are expected.

I think we're running in circles here... Most of my comments (as well as yours regarding direct drawing) referred to #3.
The only issue I had with #2 was that Rulers seem still to be updated with a high priority and prevented the canvas to redraw (in stock MSYS2 builds and therefore with CSD=0).


Yes, I am using CSD=1 in my testing (for both optimized & original GTK). But CSD isn't the actual reason for performance difference. It's because of the rendering code path CSD=1 uses (draw to CPU memory buffer, then send to UpdateLayeredWindow()), vs CSD=0  (draw directly to GDI device context - surprisingly this is slower until my optimizations).

Please note that CSD=0/1 in our stock MSYS2 builds makes a *huge* difference. If that is really not the case for your custom builds we might want to start looking into that, too. Maybe we're facing at a more fundamental difference. As MSYS2 is the official way to get GTK+ for Windows nowadays such a difference might be very relevant for many projects.

Are your cross-compiled libraries using mingw-w64? Which OS are you using btw? (I'm usually testing on Windows 10 - I'd not be surprised if there's some major difference compared to e.g. Windows 7 wrt to the low level drawing functions).

I'm very interested in testing your GDK-modifications and see how they behave with the MSYS2 builds, so if you could drop a patch somewhere that would be much appreciated!

I did get an error from the CI build after the multithreaded rendering feature. It doesn't even get past CMake configure stage, so not very useful. That's because the build server doesn't have the Boost libs (which I use, not just the headers).

I think you looked at the Linux build - Windows CI is "external" via AppVeyor and has the required Boost libraries. It's just not working in your branch right now because an upstream update broke updating but I pushed a workaround for this already in the master branch [1] (that's why I suggested to rebase)

[1] https://gitlab.com/inkscape/inkscape/commit/85d7fa343f477d8faae6cbde90ae7a243115fa37 (I messed up the rebase so it's authored by Tav, sorry for that)




On Mon, Feb 12, 2018 at 2:41 AM, Eduard Braun <[hidden email]> wrote:
Am 12.02.2018 um 10:15 schrieb Yale Zhang:
"As noted before, when rulers are shown there still is no redraw with this change"
It works for me on Windows with rulers. Could it be some out of date libraries? I'm still using a custom built cross compiler & libraries (GTK 3.22.26 & glib 2.54.2). I know you're using the MSYS 2 prebuilt libraries. I've been wanting to use those too, but how recent are they?

They are usually the latest available (think of MSYS2's MINGW-packages as arch Linux for Windows), right now gtk 3.22.26 and glib 2.54.3.

Aside from disabling CSD they are unpatched. Just to make sure we're not comparing apples and oranges: Are you using CSD in your builds or not? This switch made a huge difference before, so if you're working with CSD enabled this might be the likely explanation why some things work in your builds that do not work in the stock builds.


"It seems that the immediate drawing of the canvas basically disables drawing of the rest of the UI"

You scared me, that would be a most grievous mistake. I just tested it again and don't see any problem. The rulers and status bar still work when dragging an object. Did you build my stream directly or have any other non-trunk changes? Sorry to suggest this but here are binaries you can test. Maybe try copying the GTK & cairo? libs to your build.

I used https://gitlab.com/inkscape/inkscape/commit/78d47938194fc52ee085387d9a0dc0753f3ed6d9 as the later commits did not compile for me.

I'll check your build this evening.

We also have CI builds with MSYS2 available: https://ci.appveyor.com/project/inkscape/inkscape/history
If you rebase your branch on master your branch will be built, too (as long as there are not more errors/warnings preventing the build)

I hope you're not suggesting to forget about immediate drawing and just fix the drawing priorities. Using priorities would be easier to break, while drawing immediately is fool proof.

I'm just saying that priorities have been tweaked before to make all UI update properly and we should aim to retain this state.
If direct drawing is compatible with this goal (I guess it was in gtk2) that's probably fine.


"Have you published [GTK3] code anywhere? "
No, I haven't had time yet. I also want to discuss the problem I posed on StackOverflow and someone suggested IRC, but that I've never used IRC and it sounds very 1990s.

It's like SMS... it just works (even today)...
A lot easier than all the modern stuff that claims to be easier than IRC.

I've talked to gtk devs on IRC before and it's the easiest way to get some interaction (bug reports usually fall into oblivion sooner rather than later).


BTW, the optimized GTK also disables clearing the region to be drawn (gdk_window_clear_backing_region()).

"Is [render cache] always slow?"
It's only much slower if drawing a big area AND the scene complexity is low. For small areas and high complexity scenes, the overhead is much less noticeable.

I see... I guess before the low complexity scenes were not that important as redraw times were sufficiently fast anyway.
User reports of slow redrawing usually involve blurs (or less frequently other filters).


For the multithreaded rendering, it's still a work in progress. AFAIK, I've eliminated all the race conditions with ThreadSanitizer, so it should be stable.
I just pushed some further changes to allow the rendering to be incremental like it always has been. It should have that -fpermissive compile error in sp-canvas.cpp fixed, but you might still need it for other files.

I'll try to build this evening.
As recommended before you could check the CI to make sure your branch is properly built, which should help with testing.

Regards,
Eduard







On Sun, Feb 11, 2018 at 8:37 AM, Eduard Braun <[hidden email]> wrote:

Hi Yale,

thanks for continuing to investigate this! Some comments:


Am 09.02.2018 um 16:02 schrieb Yale Zhang:
I have an update on my progress. I've made these changes which I'm requesting to be merged from my simdgenius_inkscape branch

1. disable event compression (previously mentioned)

2. fix priority inversion (09f55021, previously mentioned) - without this, dragging objects too fast would cause no redraw.

As noted before, when rulers are shown there still is no redraw with this change


3. draw immediately (78d47938) this partially reverts Krzysztof's Hack fest 2016 changes like in 0.92.  This reduces latency by ~10ms  (compare cells G22 and E22 in spreadsheet)

I originally wanted to remove backing store and draw directly to the window surface, but I ran into this dilema so I didn't do it.


While this change does indeed speed up drawing a lot I'm not sure it's for the reason we hope for:
It seems that the immediate drawing of the canvas basically disables drawing of the rest of the UI (i.e. rulers, coordinates in the lower right, coordinates in inputs, etc). If I hide all UI elements (Ctrl+F11) I get the same perceived performance even without your code change.

While I guess redrawing the canvas is to be preferred over redrawing other UI elements, not redrawing the rest of the UI at all is probably not desirable either.
Also it poses the question: Why did gtk2 manage to redraw the canvas *and* the UI and still yield higher performance than gtk3? So I'm not sure we're not still missing the actual regression. :-/


But there is still way more speedup to be had:

1. rendering cache slows things down 6x!  Compare cells E9 & E10 in the spreadsheet.
     WTH?

Is it always slow? I guess for something simple like a rectangle it might not improve things, but maybe things start to change as soon as filters are involved (or many nodes or anything else that is not easy to render)?
I admit I was not involved when the rendering cache was added and do not know its purpose. I tracked down the commit in which it was added [1] which does not explain anything either, though, so I need to continue digging... If anybody knows where the changes are actually explained some feedback is welcome.

[1] https://gitlab.com/inkscape/inkscape/commit/093f4174abc07b4ea523617fccdd8028f2670fea


2. optimize GDK (maybe it's only slow on Windows) - compare cells J17 and J23 
      I made 2 changes:
      a. disabled layered windows - this is almost the same effect as setting GTK_CSD=0. I'm not clear why it speeds things up. I'm guessing it reduces image copying. Layered windows have to draw to CPU memory (GDI DIB), while non-layered windows draw directly to GPU memory (device dependent bitmap)?

      b. replace surface_content = gdk_window_get_content (window);   in gdk_window_begin_paint_internal()
          with surface_content = CAIRO_CONTENT_COLOR_ALPHA

          why create/delete a surface just to get the type?

Have you published this code anywhere? Also is there any upstream discussion on this yet which I could follow?


3. multithreaded rendering - I've updated it to work with trunk, so you can try it. Very little speed up for simple scenes.

Unfortunately the code does not compile for me, excerpt from the error:
    sp-canvas.cpp:802:22: error: passing 'const boost::shared_mutex' as 'this' argument discards qualifiers [-fpermissive]

Do you want us to compile your code with -fpermissive?



-Yale

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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
12