Correct, the slow refresh when dragging objects is still there. I'm looking into it next since it also kills my productivity. But for now at least, pen & calligraphy responsiveness matches that in 0.92. I use the Wacom pen all the time and with event compression it simply could not keep up with something like signing your name.

I've had lots of experience debugging CPU throughput bottlenecks (I've used Linux perf, gprof, Zoom, VTune), but not *latency* ones. Validating real time & parallel behavior is a lot hard from what I heard.

I've approached this rather amateurishly so far with good old printf() debugging :) I just recorded the time stamps of a GdkEvent throughout its life cycle from creation, dispatch, and to when it's handled. You could plot all the events on parallel time lines (like in NVIDIA's CUDA profiler) to get a big picture and spot any anomalies (I've made a web app that generates parallel timelines in SVG) but that will probably take too long to study.

On Tue, Jan 2, 2018 at 4:07 PM, Eduard Braun <eduard.braun2@...173...> wrote:

Hi Yale,

great to see somebody looking into this!

I was looking into motion event compression before and it certainly sounds like something that could improve responsiveness of certain tools in Inkscape.

Unfortunately it does not noticeably improve redraw performance in relation to the cited bug for me - as mentioned in the bug report it becomes extremely noticeable with increasing window size and happens for "simple" tasks like moving a rect on canvas. For a 2560x1440 window redrawing basically stops for me while moving the mouse and only resumes once I stop movement of the mouse pointer...

I hope we can figure out the source - you certainly seem to be more experienced with profiling tasks (maybe you can give me some pointers on your workflow?) eventually...

Best Regards, Eduard

Am 31.12.2017 um 10:52 schrieb Yale Zhang:

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

I've created a merge request https://gitlab.com/inkscape/inkscape/merge_requests/169

On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang <yzhang1985@...400...> 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 listInkscape-devel@...1901...://lists.sourceforge.net/lists/listinfo/inkscape-devel

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 <yzhang1985@...400...> wrote:

After digging further, I have some questions about how rendering works.

At 1st, it seems the lack of refresh when dragging things is because the refresh priority (for calling idle function) is lower than the mouse event priority. This is consistent with the behavior of refresh working only when you move the mouse slowly.

I tried changing UPDATE_PRIORITY in sp-canvas.cpp to high, but it didn't help since idle_handler() & SPCanvas::paint() are being called frequently when when dragging rapidly. But why don't the changes show on the screen? Is it drawing to an off screen buffer?

I noticed there's a call to gdk_widget_queue_draw_area() that's not in 0.92. What does that do? The documentation says it will generate an expose event for that invalidated area, but that doesn't make sense because why would you invalidate the region right after drawing it.

I just need to know where the screen is actually updated.

thanks, -yale

On Wed, Jan 3, 2018 at 12:34 AM, Yale Zhang <yzhang1985@...400...> wrote:

...

Correct, the slow refresh when dragging objects is still there. I'm looking into it next since it also kills my productivity. But for now at least, pen & calligraphy responsiveness matches that in 0.92. I use the Wacom pen all the time and with event compression it simply could not keep up with something like signing your name.

I've had lots of experience debugging CPU throughput bottlenecks (I've used Linux perf, gprof, Zoom, VTune), but not *latency* ones. Validating real time & parallel behavior is a lot hard from what I heard.

I've approached this rather amateurishly so far with good old printf() debugging :) I just recorded the time stamps of a GdkEvent throughout its life cycle from creation, dispatch, and to when it's handled. You could plot all the events on parallel time lines (like in NVIDIA's CUDA profiler) to get a big picture and spot any anomalies (I've made a web app that generates parallel timelines in SVG) but that will probably take too long to study.

On Tue, Jan 2, 2018 at 4:07 PM, Eduard Braun <eduard.braun2@...173...> wrote:

...

Hi Yale,

great to see somebody looking into this!

I was looking into motion event compression before and it certainly sounds like something that could improve responsiveness of certain tools in Inkscape.

Unfortunately it does not noticeably improve redraw performance in relation to the cited bug for me - as mentioned in the bug report it becomes extremely noticeable with increasing window size and happens for "simple" tasks like moving a rect on canvas. For a 2560x1440 window redrawing basically stops for me while moving the mouse and only resumes once I stop movement of the mouse pointer...

I hope we can figure out the source - you certainly seem to be more experienced with profiling tasks (maybe you can give me some pointers on your workflow?) eventually...

Best Regards, Eduard

Am 31.12.2017 um 10:52 schrieb Yale Zhang:

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

I've created a merge request https://gitlab.com/inkscape/inkscape/merge_requests/169

On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang <yzhang1985@...400...> 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 listInkscape-devel@...1901...://lists.sourceforge.net/lists/listinfo/inkscape-devel

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 <yzhang1985@...400... mailto:yzhang1985@...400...> wrote:

After digging further, I have some questions about how rendering
works.

At 1st, it seems the lack of refresh when dragging things is
because the refresh priority (for calling idle function) is lower
than the mouse event priority.
This is consistent with the behavior of refresh working only when
you move the mouse slowly.

I tried changing UPDATE_PRIORITY in sp-canvas.cpp to high, but it
didn't help since idle_handler() & SPCanvas::paint() are being
called frequently when when dragging rapidly.
But why don't the changes show on the screen? Is it drawing to an
off screen buffer?

I noticed there's a call to gdk_widget_queue_draw_area() that's
not in 0.92.  What does that do? The documentation says it will
generate an expose event for that invalidated area, but that
doesn't make sense because
why would you invalidate the region right after drawing it.

I just need to know where the screen is actually updated.

thanks,
-yale


On Wed, Jan 3, 2018 at 12:34 AM, Yale Zhang <yzhang1985@...400...
<mailto:yzhang1985@...400...>> wrote:

    Correct, the slow refresh when dragging objects is still
    there. I'm looking into it next since it also kills my
    productivity. But for now at least, pen & calligraphy
    responsiveness matches that in 0.92. I use the Wacom pen all
    the time and with event compression it simply could not keep
    up with something like signing your name.

    I've had lots of experience debugging CPU throughput
    bottlenecks (I've used Linux perf, gprof, Zoom, VTune), but
    not *latency* ones. Validating real time & parallel behavior
    is a lot hard from what I heard.

    I've approached this rather amateurishly so far with good old
    printf() debugging :) I just recorded the time stamps of a
    GdkEvent throughout its life cycle from creation, dispatch,
    and to when it's handled. You could plot all the events on
    parallel time lines (like in NVIDIA's CUDA profiler) to get a
    big picture and spot any anomalies (I've made a web app that
    generates parallel timelines in SVG) but that will probably
    take too long to study.




    On Tue, Jan 2, 2018 at 4:07 PM, Eduard Braun
    <eduard.braun2@...173... <mailto:eduard.braun2@...173...>> wrote:

        Hi Yale,

        great to see somebody looking into this!

        I was looking into motion event compression before and it
        certainly sounds like something that could improve
        responsiveness of certain tools in Inkscape.

        Unfortunately it does not noticeably improve redraw
        performance in relation to the cited bug for me - as
        mentioned in the bug report it becomes extremely
        noticeable with increasing window size and happens for
        "simple" tasks like moving a rect on canvas. For a
        2560x1440 window redrawing basically stops for me while
        moving the mouse and only resumes once I stop movement of
        the mouse pointer...

        I hope we can figure out the source - you certainly seem
        to be more experienced with profiling tasks (maybe you
        can give me some pointers on your workflow?) eventually...

        Best Regards,
        Eduard


        Am 31.12.2017 um 10:52 schrieb Yale Zhang:

...

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

        I've created a merge request
        https://gitlab.com/inkscape/inkscape/merge_requests/169
        <https://gitlab.com/inkscape/inkscape/merge_requests/169>

        On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang
        <yzhang1985@...400... <mailto:yzhang1985@...400...>> wrote:

            Hi, I've identified why drawing is lagging with GTK+3.
            https://bugs.launchpad.net/inkscape/+bug/1723247
            <https://bugs.launchpad.net/inkscape/+bug/1723247>

            It's because of GTK3's motion event compression:
            https://bugzilla.gnome.org/show_bug.cgi?id=702392
            <https://bugzilla.gnome.org/show_bug.cgi?id=702392>

            Adding a * gdk_window_set_event_compression (window,
            FALSE);* in SPCanvas::handle_realize() makes things
            much smoother.

            At 1st I thought it was because the events were
            sitting in the queue for too long. So I added some
            timing code to measure the latency between when a
            motion event was generated in GDK  to when
            SPCanvas::paint() is called. Actually, I detect
            bursts of mouse moves or redraws and only use the
            1st for latency measurements since there might not
            be a 1 to 1 relation between motion events and
            redraws. I was seeing a 4 to 10ms latency for head
            (GTK3) but only 0.5 ms for 0.92 (GTK2).

            I thought I was on to something, but this mislead me
            for a while. Finally, I saw that the # motion events
            and redraws were 10x higher for GTK2.


            I haven't stayed up to date with the GitLab
            migration. I tried to push a patch to my branch
            simdgenius_inkscape, migrated from Bazaar, but
            access is denied. I just requested project access,
            so appreciate it if someone grants it.

            -Yale




        ------------------------------------------------------------------------------
        Check out the vibrant tech community on one of the world's most
        engaging tech sites, Slashdot.org!http://sdm.link/slashdot


        _______________________________________________
        Inkscape-devel mailing list
        Inkscape-devel@lists.sourceforge.net
        <mailto:Inkscape-devel@lists.sourceforge.net>
        https://lists.sourceforge.net/lists/listinfo/inkscape-devel
        <https://lists.sourceforge.net/lists/listinfo/inkscape-devel>

---

Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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/972b7daf0ea9f73b55e0b9e48503a130...

*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: https://mail.gnome.org/archives/commits-list/2016-March/msg01108.html

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 <eduard.braun2@...173... mailto:eduard.braun2@...173...> 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 <yzhang1985@...400...
<mailto:yzhang1985@...400...>> wrote:

    After digging further, I have some questions about how
    rendering works.

    At 1st, it seems the lack of refresh when dragging things is
    because the refresh priority (for calling idle function) is
    lower than the mouse event priority.
    This is consistent with the behavior of refresh working only
    when you move the mouse slowly.

    I tried changing UPDATE_PRIORITY in sp-canvas.cpp to high,
    but it didn't help since idle_handler() & SPCanvas::paint()
    are being called frequently when when dragging rapidly.
    But why don't the changes show on the screen? Is it drawing
    to an off screen buffer?

    I noticed there's a call to gdk_widget_queue_draw_area()
    that's not in 0.92.  What does that do? The documentation
    says it will generate an expose event for that invalidated
    area, but that doesn't make sense because
    why would you invalidate the region right after drawing it.

    I just need to know where the screen is actually updated.

    thanks,
    -yale


    On Wed, Jan 3, 2018 at 12:34 AM, Yale Zhang
    <yzhang1985@...400... <mailto:yzhang1985@...400...>> wrote:

        Correct, the slow refresh when dragging objects is still
        there. I'm looking into it next since it also kills my
        productivity. But for now at least, pen & calligraphy
        responsiveness matches that in 0.92. I use the Wacom pen
        all the time and with event compression it simply could
        not keep up with something like signing your name.

        I've had lots of experience debugging CPU throughput
        bottlenecks (I've used Linux perf, gprof, Zoom, VTune),
        but not *latency* ones. Validating real time & parallel
        behavior is a lot hard from what I heard.

        I've approached this rather amateurishly so far with good
        old printf() debugging :)  I just recorded the time
        stamps of a GdkEvent throughout its life cycle from
        creation, dispatch, and to when it's handled. You could
        plot all the events on parallel time lines (like in
        NVIDIA's CUDA profiler) to get a big picture and spot any
        anomalies (I've made a web app that generates parallel
        timelines in SVG) but that will probably take too long to
        study.




        On Tue, Jan 2, 2018 at 4:07 PM, Eduard Braun
        <eduard.braun2@...173... <mailto:eduard.braun2@...173...>> wrote:

            Hi Yale,

            great to see somebody looking into this!

            I was looking into motion event compression before
            and it certainly sounds like something that could
            improve responsiveness of certain tools in Inkscape.

            Unfortunately it does not noticeably improve redraw
            performance in relation to the cited bug for me - as
            mentioned in the bug report it becomes extremely
            noticeable with increasing window size and happens
            for "simple" tasks like moving a rect on canvas. For
            a 2560x1440 window redrawing basically stops for me
            while moving the mouse and only resumes once I stop
            movement of the mouse pointer...

            I hope we can figure out the source - you certainly
            seem to be more experienced with profiling tasks
            (maybe you can give me some pointers on your
            workflow?) eventually...

            Best Regards,
            Eduard


            Am 31.12.2017 um 10:52 schrieb Yale Zhang:

...

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

            I've created a merge request
            https://gitlab.com/inkscape/inkscape/merge_requests/169
            <https://gitlab.com/inkscape/inkscape/merge_requests/169>

            On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang
            <yzhang1985@...400... <mailto:yzhang1985@...400...>>
            wrote:

                Hi, I've identified why drawing is lagging with
                GTK+3.
                https://bugs.launchpad.net/inkscape/+bug/1723247
                <https://bugs.launchpad.net/inkscape/+bug/1723247>

                It's because of GTK3's motion event compression:
                https://bugzilla.gnome.org/show_bug.cgi?id=702392
                <https://bugzilla.gnome.org/show_bug.cgi?id=702392>

                Adding a * gdk_window_set_event_compression
                (window, FALSE);* in SPCanvas::handle_realize()
                makes things much smoother.

                At 1st I thought it was because the events were
                sitting in the queue for too long. So I added
                some timing code to measure the latency between
                when a motion event was generated in GDK  to
                when SPCanvas::paint() is called. Actually, I
                detect bursts of mouse moves or redraws and only
                use the 1st for latency measurements since there
                might not be a 1 to 1 relation between motion
                events and redraws. I was seeing a 4 to 10ms
                latency for head (GTK3) but only 0.5 ms for 0.92
                (GTK2).

                I thought I was on to something, but this
                mislead me for a while. Finally, I saw that the
                # motion events and redraws were 10x higher for
                GTK2.


                I haven't stayed up to date with the GitLab
                migration. I tried to push a patch to my branch
                simdgenius_inkscape, migrated from Bazaar, but
                access is denied. I just requested project
                access, so appreciate it if someone grants it.

                -Yale




            ------------------------------------------------------------------------------
            Check out the vibrant tech community on one of the world's most
            engaging tech sites, Slashdot.org!http://sdm.link/slashdot


            _______________________________________________
            Inkscape-devel mailing list
            Inkscape-devel@lists.sourceforge.net
            <mailto:Inkscape-devel@lists.sourceforge.net>
            https://lists.sourceforge.net/lists/listinfo/inkscape-devel
            <https://lists.sourceforge.net/lists/listinfo/inkscape-devel>

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 <eduard.braun2@...173... mailto:eduard.braun2@...173...> 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
<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
<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:
https://mail.gnome.org/archives/commits-list/2016-March/msg01108.html
<https://mail.gnome.org/archives/commits-list/2016-March/msg01108.html>

    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
<eduard.braun2@...173... <mailto:eduard.braun2@...173...>> 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
    <yzhang1985@...400... <mailto:yzhang1985@...400...>> wrote:

        After digging further, I have some questions about how
        rendering works.

        At 1st, it seems the lack of refresh when dragging
        things is because the refresh priority (for calling idle
        function) is lower than the mouse event priority.
        This is consistent with the behavior of refresh working
        only when you move the mouse slowly.

        I tried changing UPDATE_PRIORITY in sp-canvas.cpp to
        high, but it didn't help since idle_handler() &
        SPCanvas::paint() are being called frequently when when
        dragging rapidly.
        But why don't the changes show on the screen? Is it
        drawing to an off screen buffer?

        I noticed there's a call to gdk_widget_queue_draw_area()
        that's not in 0.92.  What does that do? The
        documentation says it will generate an expose event for
        that invalidated area, but that doesn't make sense because
        why would you invalidate the region right after drawing it.

        I just need to know where the screen is actually updated.

        thanks,
        -yale


        On Wed, Jan 3, 2018 at 12:34 AM, Yale Zhang
        <yzhang1985@...400... <mailto:yzhang1985@...400...>> wrote:

            Correct, the slow refresh when dragging objects is
            still there. I'm looking into it next since it also
            kills my productivity. But for now at least, pen &
            calligraphy responsiveness matches that in 0.92. I
            use the Wacom pen all the time and with event
            compression it simply could not keep up with
            something like signing your name.

            I've had lots of experience debugging CPU throughput
            bottlenecks (I've used Linux perf, gprof, Zoom,
            VTune), but not *latency* ones. Validating real time
            & parallel behavior is a lot hard from what I heard.

            I've approached this rather amateurishly so far with
            good old printf() debugging :)  I just recorded the
            time stamps of a GdkEvent throughout its life cycle
            from creation, dispatch, and to when it's handled.
            You could plot all the events on parallel time lines
            (like in NVIDIA's CUDA profiler) to get a big
            picture and spot any anomalies (I've made a web app
            that generates parallel timelines in SVG) but that
            will probably take too long to study.




            On Tue, Jan 2, 2018 at 4:07 PM, Eduard Braun
            <eduard.braun2@...173... <mailto:eduard.braun2@...173...>>
            wrote:

                Hi Yale,

                great to see somebody looking into this!

                I was looking into motion event compression
                before and it certainly sounds like something
                that could improve responsiveness of certain
                tools in Inkscape.

                Unfortunately it does not noticeably improve
                redraw performance in relation to the cited bug
                for me - as mentioned in the bug report it
                becomes extremely noticeable with increasing
                window size and happens for "simple" tasks like
                moving a rect on canvas. For a 2560x1440 window
                redrawing basically stops for me while moving
                the mouse and only resumes once I stop movement
                of the mouse pointer...

                I hope we can figure out the source - you
                certainly seem to be more experienced with
                profiling tasks (maybe you can give me some
                pointers on your workflow?) eventually...

                Best Regards,
                Eduard


                Am 31.12.2017 um 10:52 schrieb Yale Zhang:

...

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

                I've created a merge request
                https://gitlab.com/inkscape/inkscape/merge_requests/169
                <https://gitlab.com/inkscape/inkscape/merge_requests/169>

                On Sun, Dec 31, 2017 at 4:08 AM, Yale Zhang
                <yzhang1985@...400...
                <mailto:yzhang1985@...400...>> wrote:

                    Hi, I've identified why drawing is lagging
                    with GTK+3.
                    https://bugs.launchpad.net/inkscape/+bug/1723247
                    <https://bugs.launchpad.net/inkscape/+bug/1723247>

                    It's because of GTK3's motion event
                    compression:
                    https://bugzilla.gnome.org/show_bug.cgi?id=702392
                    <https://bugzilla.gnome.org/show_bug.cgi?id=702392>

                    Adding a * gdk_window_set_event_compression
                    (window, FALSE);* in
                    SPCanvas::handle_realize() makes things
                    much smoother.

                    At 1st I thought it was because the events
                    were sitting in the queue for too long. So
                    I added some timing code to measure the
                    latency between when a motion event was
                    generated in GDK  to when SPCanvas::paint()
                    is called. Actually, I detect bursts of
                    mouse moves or redraws and only use the 1st
                    for latency measurements since there might
                    not be a 1 to 1 relation between motion
                    events and redraws. I was seeing a 4 to
                    10ms latency for head (GTK3) but only 0.5
                    ms for 0.92 (GTK2).

                    I thought I was on to something, but this
                    mislead me for a while. Finally, I saw that
                    the # motion events and redraws were 10x
                    higher for GTK2.


                    I haven't stayed up to date with the GitLab
                    migration. I tried to push a patch to my
                    branch simdgenius_inkscape, migrated from
                    Bazaar, but access is denied. I just
                    requested project access, so appreciate it
                    if someone grants it.

                    -Yale




                ------------------------------------------------------------------------------
                Check out the vibrant tech community on one of the world's most
                engaging tech sites, Slashdot.org!http://sdm.link/slashdot


                _______________________________________________
                Inkscape-devel mailing list
                Inkscape-devel@lists.sourceforge.net
                <mailto:Inkscape-devel@lists.sourceforge.net>
                https://lists.sourceforge.net/lists/listinfo/inkscape-devel
                <https://lists.sourceforge.net/lists/listinfo/inkscape-devel>

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 revertsKrzysztof'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.

https://stackoverflow.com/questions/48339792/when-drawing-to-a-window-are-th...

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/093f4174abc07b4ea523617fccdd8028...

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

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 <yzhang1985@...400...> 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. https://1drv.ms/u/s!AngRQgSreBCehy4R7D3x3Y2vIXPC

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 <eduard.braun2@...173...> 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.

https://stackoverflow.com/questions/48339792/when-drawing- to-a-window-are-the-previous-contents-usually-discarded-and-what

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/093f4174abc07b4e a523617fccdd8028f2670fea

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

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 <eduard.braun2@...173...> 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. https://1drv.ms/u/s!AngRQgSreBCehy4R7D3x3Y2vIXPC

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 <eduard.braun2@...173...> 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.

https://stackoverflow.com/questions/48339792/when-drawing- to-a-window-are-the-previous-contents-usually-discarded-and-what

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/093f4174abc07b4e a523617fccdd8028f2670fea

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

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/85d7fa343f477d8faae6cbde90ae7a24... (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 <eduard.braun2@...173... mailto:eduard.braun2@...173...> 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.
https://1drv.ms/u/s!AngRQgSreBCehy4R7D3x3Y2vIXPC
<https://1drv.ms/u/s%21AngRQgSreBCehy4R7D3x3Y2vIXPC>

I used
https://gitlab.com/inkscape/inkscape/commit/78d47938194fc52ee085387d9a0dc0753f3ed6d9
<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
<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
<eduard.braun2@...173... <mailto:eduard.braun2@...173...>> 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
    revertsKrzysztof'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.

    https://stackoverflow.com/questions/48339792/when-drawing-to-a-window-are-the-previous-contents-usually-discarded-and-what
    <https://stackoverflow.com/questions/48339792/when-drawing-to-a-window-are-the-previous-contents-usually-discarded-and-what>

    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
    <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 Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Am 14.02.2018 um 11:09 schrieb Yale Zhang:

Good, we're getting closer to the same page. Can you please tell me which of my commits did you include in your testing? If dragging is still lagging, it sounds like you didn't take change #2 (priorities). You complained it didn't help or made things worse, but it should be quite the opposite.

As I wrote: I checked out 0bde236 and built the resulting code. It should therefore have contained all you latest (public) changes.

Let me get the MSYS2 headers & libs and do a build to rule out any library issues.

This would certainly help... Even though you keep telling me the stock builds *should* behave differently with your changes - they don't. If you're able to test yourself we'll probably safe ourselves some back and forth as seeing is believing. ;-)

"warn me next time it's not relocatable" - I think all you have to do to relocate was regenerate immodules.cache & loaders.cache. I wonder how the release packages of Inkscape & Gimp avoid this problem.

Ah, if they contain absolute paths that might have been it. As for the release packages: they contain relative paths in imloaders.cache (MSYS2 contains a relocation patch for gdk-pixbuf2). Earlier versions (built wit devlibs) included the loaders in libgdk_pixbuf-2.0-0.dll to work around this (it's a built option)

Yes, my version should be quite fast, but it has little to do with the GDK optimizations. You should see the same benefits with vanilla GTK (GTK_CSD=1). For the optimized version, there should be no performance difference for GTK_CSD because I force the rendering code path to what GTK_CSD=0 uses, plus some optimizations.

"I'm not able to resize the Window" Sorry, I forgot to mention it has my optimized, but work in progress libgdk-3-0.dll. Please roll back to the stock version (libgdk-3-0.dll.orig). The optimized one keeps a persistent Cairo Win32 surface for window updates, but resizing isn't handled.

On Tue, Feb 13, 2018 at 6:27 PM, Eduard Braun <eduard.braun2@...173... mailto:eduard.braun2@...173...> wrote:

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
<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
<eduard.braun2@...173... <mailto:eduard.braun2@...173...>> 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.
    https://1drv.ms/u/s!AngRQgSreBCehy4R7D3x3Y2vIXPC
    <https://1drv.ms/u/s%21AngRQgSreBCehy4R7D3x3Y2vIXPC>

    I used
    https://gitlab.com/inkscape/inkscape/commit/78d47938194fc52ee085387d9a0dc0753f3ed6d9
    <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
    <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
    <eduard.braun2@...173... <mailto:eduard.braun2@...173...>> 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
        revertsKrzysztof'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.

        https://stackoverflow.com/questions/48339792/when-drawing-to-a-window-are-the-previous-contents-usually-discarded-and-what
        <https://stackoverflow.com/questions/48339792/when-drawing-to-a-window-are-the-previous-contents-usually-discarded-and-what>

        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
        <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
Inkscape-devel@lists.sourceforge.net
<mailto:Inkscape-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
<https://lists.sourceforge.net/lists/listinfo/inkscape-devel>

Am 15.02.2018 um 12:23 schrieb Yale Zhang:

I've updated my custom cross compiler to use MSYS2 packages and finally saw the lack of rule/status bar updates. Unfortunately, it had nothing to do with using MSYS2. I just didn't look hard enough earlier :( The earlier versions (including the binaries) did suffer the problem but only when dragging large rectangles. Plus I had _INKSCAPE_DISABLE_CACHE=1, making the problem less noticeable.

So now I know what's wrong. The ruler update priority is G_PRIORITY_LOW = 300, while UPDATE_PRIORITY in SPCanvas::addIdle() is GDK_PRIORITY_EVENTS = 0, so it's no mystery who loses.

Changing UPDATE_PRIORITY back to GDK_PRIORITY_REDRAW + 10 fixes the problem. But the ~10ms less latency for immediate drawing (#3) now is reduced because a ~2ms delay is added between SPCanvas::addIdle() and SPCanvas::paint().

Of course, this is perfectly usable, but I have an itch to further improve. That 2ms latency is gone if I disable the status bar, so I'd like to do the status bar updates after SPCanvas::paint().

But I can't find where the status bar is being drawn. Do you? And also, what is SP_DOCUMENT_UPDATE_PRIORITY and SP_DOCUMENT_ROUTING_PRIORITY in document.cpp? I don't know if those need to be rebalanced.

The coordinates are updated by calling "SPDesktop::set_coordinate_status" in "desktop.cpp" (which calls "SPDesktopWidget::setCoordinateStatus" in "desktop-widget.cpp").

-yale

On Wed, Feb 14, 2018 at 2:30 AM, Eduard Braun <eduard.braun2@...173... mailto:eduard.braun2@...173...> wrote:

Am 14.02.2018 um 11:09 schrieb Yale Zhang:

...

Good, we're getting closer to the same page. Can you please tell
me which of my commits did you include in your testing? If
dragging is still lagging, it sounds like you didn't take change
#2 (priorities). You complained it didn't help or made things
worse, but it should be quite the opposite.

As I wrote: I checked out 0bde236 and built the resulting code. It
should therefore have contained all you latest (public) changes.

...

Let me get the MSYS2 headers & libs and do a build to rule out
any library issues.

This would certainly help... Even though you keep telling me the
stock builds *should* behave differently with your changes - they
don't. If you're able to test yourself we'll probably safe
ourselves some back and forth as seeing is believing. ;-)

...

"warn me next time it's not relocatable" - I think all you have
to do to relocate was regenerate immodules.cache & loaders.cache.
I wonder how the release packages of Inkscape & Gimp avoid this
problem.

Ah, if they contain absolute paths that might have been it. As for
the release packages: they contain relative paths in
imloaders.cache (MSYS2 contains a relocation patch for
gdk-pixbuf2). Earlier versions (built wit devlibs) included the
loaders in libgdk_pixbuf-2.0-0.dll to work around this (it's a
built option)

...

Yes, my version should be quite fast, but it has little to do
with the GDK optimizations. You should see the same benefits with
vanilla GTK (GTK_CSD=1). For the optimized version, there should
be no performance difference for GTK_CSD because I force the
rendering code path to what GTK_CSD=0 uses, plus some optimizations.

"I'm not able to resize the Window"
Sorry, I forgot to mention it has my optimized, but work in
progress libgdk-3-0.dll. Please roll back to the stock version
(libgdk-3-0.dll.orig). The optimized one keeps a persistent Cairo
Win32 surface for window updates, but resizing isn't handled.



On Tue, Feb 13, 2018 at 6:27 PM, Eduard Braun
<eduard.braun2@...173... <mailto:eduard.braun2@...173...>> wrote:

    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
    <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
    <eduard.braun2@...173... <mailto:eduard.braun2@...173...>> 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.
        https://1drv.ms/u/s!AngRQgSreBCehy4R7D3x3Y2vIXPC
        <https://1drv.ms/u/s%21AngRQgSreBCehy4R7D3x3Y2vIXPC>

        I used
        https://gitlab.com/inkscape/inkscape/commit/78d47938194fc52ee085387d9a0dc0753f3ed6d9
        <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
        <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
        <eduard.braun2@...173... <mailto:eduard.braun2@...173...>>
        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
            revertsKrzysztof'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.

            https://stackoverflow.com/questions/48339792/when-drawing-to-a-window-are-the-previous-contents-usually-discarded-and-what
            <https://stackoverflow.com/questions/48339792/when-drawing-to-a-window-are-the-previous-contents-usually-discarded-and-what>

            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
            <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
    Inkscape-devel@lists.sourceforge.net
    <mailto:Inkscape-devel@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/inkscape-devel
    <https://lists.sourceforge.net/lists/listinfo/inkscape-devel>

Am 16.02.2018 um 11:51 schrieb Yale Zhang:

Thanks, I couldn't find it because I was expecting the status bar to be drawn by Cairo. I tried to increase the priority of UPDATE_PRIORITY & SP_UPDATE_SELECTION_PRIORITY, but couldn't do so without causing the ruler & status bar updates to starve. I conclude that UPDATE_PRIORITY cannot have any higher priority than GDK_PRIORITY_REDRAW. Even when those priorities are the same, the status bar will always get drawn before canvas because SPDesktopWidget::setCoordinateStatus() is called before SPCanvas::addIdle().

I've pushed my changes (I did some git resets instead of revert so it's diverged). Hopefully now, you can approve? Sorry about the back and forth over the rulers & status bar not updating. Shouldn't have been greedy about reducing latency by 2ms by setting UPDATE_PRIORITY = GDK_PRIORITY_EVENTS :)

Hm, actually I'm afraid fd2d6d7b8ab36ed8e93b39aeac03a01c8419ff85 performs better than the last commit I tested but unfortunately is still slowish most of the time:

* With the status bar and rulers visible I'm getting super fast redraws of the status bar and redraws of the rulers but everything else is not redrawn when moving a rect. * With the status bar visible and rulers hidden I'm getting super fast redraws of the status bar and canvas redraws (still a bit sluggish, though). Selection toolbar is not updated while moving fast. * With the status bar hidden and rulers visible I'm getting canvas redraws (still a bit sluggish, though) and redraws of the rulers. Selection toolbar is not updated while moving fast. * With the status bar and rulers hidden moving the rect is fast (as I'd expect it to be). Selection toolbar is not updated while moving fast.

All these tests with MSYS2 stock builds without any modifications (i.e. GTK_CSD=0, caching enabled).

On Thu, Feb 15, 2018 at 3:58 PM, Eduard Braun <eduard.braun2@...173... mailto:eduard.braun2@...173...> wrote:

Am 15.02.2018 um 12:23 schrieb Yale Zhang:

...

I've updated my custom cross compiler to use MSYS2 packages and
finally saw the lack of rule/status bar updates. Unfortunately,
it had nothing to do with using MSYS2. I just didn't look hard
enough earlier :(
The earlier versions (including the binaries) did suffer the
problem but only when dragging large rectangles. Plus I had
_INKSCAPE_DISABLE_CACHE=1, making the problem less noticeable.

So now I know what's wrong. The ruler update priority is
G_PRIORITY_LOW = 300, while UPDATE_PRIORITY in
SPCanvas::addIdle() is GDK_PRIORITY_EVENTS = 0, so it's no
mystery who loses.

Changing UPDATE_PRIORITY back to GDK_PRIORITY_REDRAW + 10 fixes
the problem. But the ~10ms less latency for immediate drawing
(#3) now is reduced because a ~2ms delay is added between
SPCanvas::addIdle() and SPCanvas::paint().

Of course, this is perfectly usable, but I have an itch to
further improve. That 2ms latency is gone if I disable the status
bar, so I'd like to do the status bar updates after
SPCanvas::paint().

But I can't find where the status bar is being drawn. Do you?
And also, what is SP_DOCUMENT_UPDATE_PRIORITY and 
SP_DOCUMENT_ROUTING_PRIORITY in document.cpp? I don't know if
those need to be rebalanced.

The coordinates are updated by calling
"SPDesktop::set_coordinate_status" in "desktop.cpp" (which calls
"SPDesktopWidget::setCoordinateStatus" in "desktop-widget.cpp").

...

-yale


On Wed, Feb 14, 2018 at 2:30 AM, Eduard Braun
<eduard.braun2@...173... <mailto:eduard.braun2@...173...>> wrote:

    Am 14.02.2018 um 11:09 schrieb Yale Zhang:

...

    Good, we're getting closer to the same page. Can you please
    tell me which of my commits did you include in your testing?
    If dragging is still lagging, it sounds like you didn't take
    change #2 (priorities). You complained it didn't help or
    made things worse, but it should be quite the opposite.

    As I wrote: I checked out 0bde236 and built the resulting
    code. It should therefore have contained all you latest
    (public) changes.

...

    Let me get the MSYS2 headers & libs and do a build to rule
    out any library issues.

    This would certainly help... Even though you keep telling me
    the stock builds *should* behave differently with your
    changes - they don't. If you're able to test yourself we'll
    probably safe ourselves some back and forth as seeing is
    believing. ;-)

...

    "warn me next time it's not relocatable" - I think all you
    have to do to relocate was regenerate immodules.cache &
    loaders.cache. I wonder how the release packages of Inkscape
    & Gimp avoid this problem.

    Ah, if they contain absolute paths that might have been it.
    As for the release packages: they contain relative paths in
    imloaders.cache (MSYS2 contains a relocation patch for
    gdk-pixbuf2). Earlier versions (built wit devlibs) included
    the loaders in libgdk_pixbuf-2.0-0.dll to work around this
    (it's a built option)

...

    Yes, my version should be quite fast, but it has little to
    do with the GDK optimizations. You should see the same
    benefits with vanilla GTK (GTK_CSD=1). For the optimized
    version, there should be no performance difference for
    GTK_CSD because I force the rendering code path to what
    GTK_CSD=0 uses, plus some optimizations.

    "I'm not able to resize the Window"
    Sorry, I forgot to mention it has my optimized, but work in
    progress libgdk-3-0.dll. Please roll back to the stock
    version (libgdk-3-0.dll.orig). The optimized one keeps a
    persistent Cairo Win32 surface for window updates, but
    resizing isn't handled.



    On Tue, Feb 13, 2018 at 6:27 PM, Eduard Braun
    <eduard.braun2@...173... <mailto:eduard.braun2@...173...>> wrote:

        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
        <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
        <eduard.braun2@...173... <mailto:eduard.braun2@...173...>>
        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.
            https://1drv.ms/u/s!AngRQgSreBCehy4R7D3x3Y2vIXPC
            <https://1drv.ms/u/s%21AngRQgSreBCehy4R7D3x3Y2vIXPC>

            I used
            https://gitlab.com/inkscape/inkscape/commit/78d47938194fc52ee085387d9a0dc0753f3ed6d9
            <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
            <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
            <eduard.braun2@...173...
            <mailto:eduard.braun2@...173...>> 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 revertsKrzysztof'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. > > https://stackoverflow.com/questions/48339792/when-drawing-to-a-window-are-th... > https://stackoverflow.com/questions/48339792/when-drawing-to-a-window-are-the-previous-contents-usually-discarded-and-what

                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
                <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
        Inkscape-devel@lists.sourceforge.net
        <mailto:Inkscape-devel@lists.sourceforge.net>
        https://lists.sourceforge.net/lists/listinfo/inkscape-devel
        <https://lists.sourceforge.net/lists/listinfo/inkscape-devel>

Hi,

I asked KK about why he made the changes to the rendering code. Here is his response:

-------- Forwarded Message -------- From: Krzysztof Kosiński <tweenk.pl@...400...> To: Tavmjong Bah <tavmjong@...8...> Subject: Re: Inkscape Boston Hackfest Date: Tue, 27 Mar 2018 08:09:07 +0000 X-Proxad-Sc: state=HAM score=0

Before these changes, we would draw directly to the surface exposed by GTK outside the draw signal. This is no longer supported by GTK 3, it is only allowed to draw to the window in the draw signal. To satisfy this requirement, on each draw signal, we blit content that are up to date to the window, then schedule further rendering in the idle callback. The idle callback renders content, then invalidates the window, so that a second draw signal can actually blit the newly rendered content to the GDK window.

If our rendering was fast enough, we could remove the whole system of rendering in the idle callback and render directly in the draw signal. This would have the side effect of removing the visible redrawing in strips, but could increase latency on complex scenes. (On the other hand, the worst files are those with filters with large dependency areas which are rendered over and over for each tile - the overall performance would actually improve for these files.)

In retrospect, the rendering cache is more of a band-aid than an actual solution to rendering performance problems. It might make sense to remove most of it and just keep the offscreen buffer for drawing content, which significantly helps cases like hovering the node tool over a complex drawing, where we just want to draw different controls or path outlines on top.

At one point in the linked thread, Yale mentions the analysis of "parallel timelines" to find performance issues. This is known as a tracing framework and one open source option is LTTng.

[The linked thread was http://inkscape.13.x6.nabble.com/slow-sluggish-drawing-with-pencil-amp- calligraphy-tool-solved-td4981276i20.html ]

Tav

On Tue, 2018-03-27 at 00:07 +0200, Eduard Braun wrote:

Hi Yale, I'm not sure if you've seen my last mail (the one I'm replying to right now) as the sf.net servers were glitchy when I sent it. Regarding the GTK/GDK part of the performance problem there is some movement: LRN did some profiling and I think it matches your observations well and might helpt to investigate this further, see https://bugzilla.gnome.org/show_bug.cgi?id=781153#c14 I'm not sure if you had the chance to talk to GTK devs yet? If not, this might be a good opportunity to exchange the results collected so far and maybe have another shot at resolving the performance issues in GTK itself, which might also make it easier to get consistent results in the Inkscape-specific code. Regards, Eduard

Sorry everyone for the late response. Hope the Hack fest went well.

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

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

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

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

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

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

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

Hi,

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

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

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

https://vimeo.com/262213837

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

Tim

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

...

Hi,

I asked KK about why he made the changes to the rendering code. Here is his response:

-------- Forwarded Message -------- From: Krzysztof Kosiński <tweenk.pl@...400...> To: Tavmjong Bah <tavmjong@...8...> Subject: Re: Inkscape Boston Hackfest Date: Tue, 27 Mar 2018 08:09:07 +0000 X-Proxad-Sc: state=HAM score=0

Before these changes, we would draw directly to the surface exposed by GTK outside the draw signal. This is no longer supported by GTK 3, it is only allowed to draw to the window in the draw signal. To satisfy this requirement, on each draw signal, we blit content that are up to date to the window, then schedule further rendering in the idle callback. The idle callback renders content, then invalidates the window, so that a second draw signal can actually blit the newly rendered content to the GDK window.

If our rendering was fast enough, we could remove the whole system of rendering in the idle callback and render directly in the draw signal. This would have the side effect of removing the visible redrawing in strips, but could increase latency on complex scenes. (On the other hand, the worst files are those with filters with large dependency areas which are rendered over and over for each tile - the overall performance would actually improve for these files.)

In retrospect, the rendering cache is more of a band-aid than an actual solution to rendering performance problems. It might make sense to remove most of it and just keep the offscreen buffer for drawing content, which significantly helps cases like hovering the node tool over a complex drawing, where we just want to draw different controls or path outlines on top.

At one point in the linked thread, Yale mentions the analysis of "parallel timelines" to find performance issues. This is known as a tracing framework and one open source option is LTTng.

[The linked thread was http://inkscape.13.x6.nabble.com/slow-sluggish-drawing-with-pencil-amp- calligraphy-tool-solved-td4981276i20.html http://inkscape.13.x6.nabble.com/slow-sluggish-drawing-with-pencil-amp-calligraphy-tool-solved-td4981276i20.html ]

Tav

On Tue, 2018-03-27 at 00:07 +0200, Eduard Braun wrote:

...

Hi Yale, I'm not sure if you've seen my last mail (the one I'm replying to right now) as the sf.net servers were glitchy when I sent it. Regarding the GTK/GDK part of the performance problem there is some movement: LRN did some profiling and I think it matches your observations well and might helpt to investigate this further, see https://bugzilla.gnome.org/show_bug.cgi?id=781153#c14 I'm not sure if you had the chance to talk to GTK devs yet? If not, this might be a good opportunity to exchange the results collected so far and maybe have another shot at resolving the performance issues in GTK itself, which might also make it easier to get consistent results in the Inkscape-specific code. Regards, Eduard

---

---

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

Hi,

We have a GTK expert at the hackfest today. If you can give a precise summary of the status, we can ask for guidance. (Sorry about the late notice, I thought I sent this email earlier.)

Tav

On Tue, 2018-03-27 at 00:07 +0200, Eduard Braun wrote:

Hi Yale, I'm not sure if you've seen my last mail (the one I'm replying to right now) as the sf.net servers were glitchy when I sent it. Regarding the GTK/GDK part of the performance problem there is some movement: LRN did some profiling and I think it matches your observations well and might helpt to investigate this further, see https://bugzilla.gnome.org/show_bug.cgi?id=781153#c14 I'm not sure if you had the chance to talk to GTK devs yet? If not, this might be a good opportunity to exchange the results collected so far and maybe have another shot at resolving the performance issues in GTK itself, which might also make it easier to get consistent results in the Inkscape-specific code. Regards, Eduard

Am 16.02.2018 um 19:25 schrieb Eduard Braun:

...

Am 16.02.2018 um 11:51 schrieb Yale Zhang:

...

Thanks, I couldn't find it because I was expecting the status bar to be drawn by Cairo. I tried to increase the priority of UPDATE_PRIORITY & SP_UPDATE_SELECTION_PRIORITY, but couldn't do so without causing the ruler & status bar updates to starve. I conclude that UPDATE_PRIORITY cannot have any higher priority than GDK_PRIORITY_REDRAW. Even when those priorities are the same, the status bar will always get drawn before canvas because SPDesktopWidget::setCoordinateStatus() is called before SPCanvas::addIdle().

I've pushed my changes (I did some git resets instead of revert so it's diverged). Hopefully now, you can approve? Sorry about the back and forth over the rulers & status bar not updating. Shouldn't have been greedy about reducing latency by 2ms by setting UPDATE_PRIORITY = GDK_PRIORITY_EVENTS :)

Hm, actually I'm afraid fd2d6d7b8ab36ed8e93b39aeac03a01c8419ff85 performs better than the last commit I tested but unfortunately is still slowish most of the time: With the status bar and rulers visible I'm getting super fast redraws of the status bar and redraws of the rulers but everything else is not redrawn when moving a rect. With the status bar visible and rulers hidden I'm getting super fast redraws of the status bar and canvas redraws (still a bit sluggish, though). Selection toolbar is not updated while moving fast. With the status bar hidden and rulers visible I'm getting canvas redraws (still a bit sluggish, though) and redraws of the rulers. Selection toolbar is not updated while moving fast. With the status bar and rulers hidden moving the rect is fast (as I'd expect it to be). Selection toolbar is not updated while moving fast. All these tests with MSYS2 stock builds without any modifications (i.e. GTK_CSD=0, caching enabled).

...

On Thu, Feb 15, 2018 at 3:58 PM, Eduard Braun <eduard.braun2@...3648... de> wrote:

...

Am 15.02.2018 um 12:23 schrieb Yale Zhang:

...

I've updated my custom cross compiler to use MSYS2 packages and finally saw the lack of rule/status bar updates. Unfortunately, it had nothing to do with using MSYS2. I just didn't look hard enough earlier :( The earlier versions (including the binaries) did suffer the problem but only when dragging large rectangles. Plus I had _INKSCAPE_DISABLE_CACHE=1, making the problem less noticeable.

So now I know what's wrong. The ruler update priority is G_PRIORITY_LOW = 300, while UPDATE_PRIORITY in SPCanvas::addIdle() is GDK_PRIORITY_EVENTS = 0, so it's no mystery who loses.

Changing UPDATE_PRIORITY back to GDK_PRIORITY_REDRAW + 10 fixes the problem. But the ~10ms less latency for immediate drawing (#3) now is reduced because a ~2ms delay is added between SPCanvas::addIdle() and SPCanvas::paint().

Of course, this is perfectly usable, but I have an itch to further improve. That 2ms latency is gone if I disable the status bar, so I'd like to do the status bar updates after SPCanvas::paint().

But I can't find where the status bar is being drawn. Do you? And also, what is SP_DOCUMENT_UPDATE_PRIORITY and SP_DOCUMENT_ROUTING_PRIORITY in document.cpp? I don't know if those need to be rebalanced.

The coordinates are updated by calling "SPDesktop::set_coordinate_status" in "desktop.cpp" (which calls "SPDesktopWidget::setCoordinateStatus" in "desktop- widget.cpp").

...

-yale

On Wed, Feb 14, 2018 at 2:30 AM, Eduard Braun <eduard.braun2@ gmx.de> wrote:

...

Am 14.02.2018 um 11:09 schrieb Yale Zhang: > Good, we're getting closer to the same page. Can you > please tell me which of my commits did you include in > your testing? If dragging is still lagging, it sounds > like you didn't take change #2 (priorities). You > complained it didn't help or made things worse, but it > should be quite the opposite.

As I wrote: I checked out 0bde236 and built the resulting code. It should therefore have contained all you latest (public) changes.

> Let me get the MSYS2 headers & libs and do a build to > rule out any library issues.

This would certainly help... Even though you keep telling me the stock builds *should* behave differently with your changes - they don't. If you're able to test yourself we'll probably safe ourselves some back and forth as seeing is believing. ;-)

> "warn me next time it's not relocatable" - I think all > you have to do to relocate was regenerate immodules.cache > & loaders.cache. I wonder how the release packages of > Inkscape & Gimp avoid this problem.

Ah, if they contain absolute paths that might have been it. As for the release packages: they contain relative paths in imloaders.cache (MSYS2 contains a relocation patch for gdk- pixbuf2). Earlier versions (built wit devlibs) included the loaders in libgdk_pixbuf-2.0-0.dll to work around this (it's a built option)

> Yes, my version should be quite fast, but it has little > to do with the GDK optimizations. You should see the same > benefits with vanilla GTK (GTK_CSD=1). For the optimized > version, there should be no performance difference for > GTK_CSD because I force the rendering code path to what > GTK_CSD=0 uses, plus some optimizations. > > "I'm not able to resize the Window" > Sorry, I forgot to mention it has my optimized, but work > in progress libgdk-3-0.dll. Please roll back to the stock > version (libgdk-3-0.dll.orig). The optimized one keeps a > persistent Cairo Win32 surface for window updates, but > resizing isn't handled. > > > > On Tue, Feb 13, 2018 at 6:27 PM, Eduard Braun <eduard.bra > un2@...173...> wrote: > > 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/85d7f > > > a343f477d8faae6cbde90ae7a243115fa37 (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 <edua > > > > rd.braun2@...173...> 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. > > > > > > https://1drv.ms/u/s!AngRQgSreBCehy4R7D3x3Y2vIXP > > > > > > C > > > > > > > > > > I used https://gitlab.com/inkscape/inkscape/commi > > > > > t/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: http > > > > > s://ci.appveyor.com/project/inkscape/inkscape/his > > > > > tory > > > > > 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 < > > > > > > eduard.braun2@...173...> 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. > > > > > > > > > > > > > > > > https://stackoverflow.com/questions/4833979 > > > > > > > > 2/when-drawing-to-a-window-are-the- > > > > > > > > previous-contents-usually-discarded-and- > > > > > > > > what > > > > > > > > > > > > > > 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/comm > > > > > > > it/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/sl > > > ashdot > > > > > > > > > _______________________________________________ > > > Inkscape-devel mailing list > > > Inkscape-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/inkscape > > > -devel > > > >

Dieser Nachrichteninhalt wird auf Anfrage komplett heruntergeladen.

Dieser Nachrichteninhalt wird auf Anfrage komplett heruntergeladen.

---

---

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