slow, sluggish drawing with pencil & calligraphy tool solved

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

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

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.

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

"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.

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 <[hidden email]> 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 (I messed up the rebase so it's authored by Tav, sorry for that)




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

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

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


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

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

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

I'll check your build this evening.

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

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

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


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

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

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


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

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

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


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

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

Regards,
Eduard







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

Hi Yale,

thanks for continuing to investigate this! Some comments:


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

1. disable event compression (previously mentioned)

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

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


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

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


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

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


But there is still way more speedup to be had:

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

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

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


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

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

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

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


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

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

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



-Yale

Regards,
Eduard






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


_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

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

Eduard Braun
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 <[hidden email]> 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 (I messed up the rebase so it's authored by Tav, sorry for that)




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

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

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


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

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

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

I'll check your build this evening.

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

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

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


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

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

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


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

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

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


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

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

Regards,
Eduard







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

Hi Yale,

thanks for continuing to investigate this! Some comments:


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

1. disable event compression (previously mentioned)

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

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


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

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


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

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


But there is still way more speedup to be had:

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

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

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


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

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

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

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


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

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

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



-Yale

Regards,
Eduard






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


_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

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

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.

-yale


On Wed, Feb 14, 2018 at 2:30 AM, Eduard Braun <[hidden email]> 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 <[hidden email]> 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 (I messed up the rebase so it's authored by Tav, sorry for that)




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

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

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


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

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

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

I'll check your build this evening.

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

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

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


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

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

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


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

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

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


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

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

Regards,
Eduard







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

Hi Yale,

thanks for continuing to investigate this! Some comments:


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

1. disable event compression (previously mentioned)

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

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


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

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


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

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


But there is still way more speedup to be had:

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

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

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


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

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

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

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


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

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

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



-Yale

Regards,
Eduard






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


_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel





------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

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

Eduard Braun
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 <[hidden email]> 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 <[hidden email]> 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 (I messed up the rebase so it's authored by Tav, sorry for that)




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

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

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


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

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

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

I'll check your build this evening.

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

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

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


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

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

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


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

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

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


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

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

Regards,
Eduard







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

Hi Yale,

thanks for continuing to investigate this! Some comments:


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

1. disable event compression (previously mentioned)

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

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


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

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


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

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


But there is still way more speedup to be had:

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

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

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


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

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

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

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


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

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

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



-Yale

Regards,
Eduard






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


_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel






------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

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

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 :)


On Thu, Feb 15, 2018 at 3:58 PM, Eduard Braun <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 (I messed up the rebase so it's authored by Tav, sorry for that)




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

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

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


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

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

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

I'll check your build this evening.

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

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

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


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

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

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


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

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

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


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

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

Regards,
Eduard







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

Hi Yale,

thanks for continuing to investigate this! Some comments:


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

1. disable event compression (previously mentioned)

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

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


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

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


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

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


But there is still way more speedup to be had:

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

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

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


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

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

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

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


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

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

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



-Yale

Regards,
Eduard






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


_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel







------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

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

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 (I messed up the rebase so it's authored by Tav, sorry for that)




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

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

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


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

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

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

I'll check your build this evening.

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

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

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


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

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

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


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

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

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


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

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

Regards,
Eduard







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

Hi Yale,

thanks for continuing to investigate this! Some comments:


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

1. disable event compression (previously mentioned)

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

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


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

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


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

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


But there is still way more speedup to be had:

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

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

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


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

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

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

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


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

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

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



-Yale

Regards,
Eduard






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


_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel








------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

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

Eduard Braun

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 (I messed up the rebase so it's authored by Tav, sorry for that)




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

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

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


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

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

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

I'll check your build this evening.

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

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

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


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

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

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


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

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

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


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

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

Regards,
Eduard







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

Hi Yale,

thanks for continuing to investigate this! Some comments:


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

1. disable event compression (previously mentioned)

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

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


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

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


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

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


But there is still way more speedup to be had:

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

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

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


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

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

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

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


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

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

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



-Yale

Regards,
Eduard






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


_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel









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

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

Tavmjong Bah

Hi,

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


-------- Forwarded Message --------
From: Krzysztof Kosiński <[hidden email]>
To: Tavmjong Bah <[hidden email]>
Subject: Re: Inkscape Boston Hackfest
Date: Tue, 27 Mar 2018 08:09:07 +0000
X-Proxad-Sc: state=HAM score=0

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

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

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

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

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

Tav

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

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


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

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

Tavmjong Bah
In reply to this post by Eduard Braun

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@gmx.
> > > 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
> > > > > > > [hidden email]> 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
> > > > > > > > > > [hidden email]> wrote:
> > > > > > > > > > > Am 12.02.2018 um 10:15 schrieb Yale Zhang:
> > > > > > > > > > > > "As noted before, when rulers are shown there
> > > > > > > > > > > > still is no redraw with this change"
> > > > > > > > > > > > It works for me on Windows with rulers. Could
> > > > > > > > > > > > it be some out of date libraries? I'm still
> > > > > > > > > > > > using a custom built cross compiler & libraries
> > > > > > > > > > > > (GTK 3.22.26 & glib 2.54.2). I know you're
> > > > > > > > > > > > using the MSYS 2 prebuilt libraries. I've been
> > > > > > > > > > > > wanting to use those too, but how recent are
> > > > > > > > > > > > they?
> > > > > > > > > > >  
> > > > > > > > > > > They are usually the latest available (think of
> > > > > > > > > > > MSYS2's MINGW-packages as arch Linux for
> > > > > > > > > > > Windows), right now gtk 3.22.26 and glib 2.54.3.
> > > > > > > > > > >
> > > > > > > > > > > Aside from disabling CSD they are unpatched. Just
> > > > > > > > > > > to make sure we're not comparing apples and
> > > > > > > > > > > oranges: Are you using CSD in your builds or not?
> > > > > > > > > > > This switch made a huge difference before, so if
> > > > > > > > > > > you're working with CSD enabled this might be the
> > > > > > > > > > > likely explanation why some things work in your
> > > > > > > > > > > builds that do not work in the stock builds.
> > > > > > > > > > >
> > > > > > > > > > > > "It seems that the immediate drawing of the
> > > > > > > > > > > > canvas basically disables drawing of the rest
> > > > > > > > > > > > of the UI"
> > > > > > > > > > > >
> > > > > > > > > > > > You scared me, that would be a most grievous
> > > > > > > > > > > > mistake. I just tested it again and don't see
> > > > > > > > > > > > any problem. The rulers and status bar still
> > > > > > > > > > > > work when dragging an object. Did you build my
> > > > > > > > > > > > stream directly or have any other non-trunk
> > > > > > > > > > > > changes? Sorry to suggest this but here are
> > > > > > > > > > > > binaries you can test. Maybe try copying the
> > > > > > > > > > > > GTK & cairo? libs to your build.
> > > > > > > > > > > > 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 <
> > > > > > > > > > > > [hidden email]> wrote:
> > > > > > > > > > > > > Hi Yale,
> > > > > > > > > > > > > thanks for continuing to investigate this!
> > > > > > > > > > > > > Some comments:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Am 09.02.2018 um 16:02 schrieb Yale Zhang:
> > > > > > > > > > > > > > I have an update on my progress. I've made
> > > > > > > > > > > > > > these changes which I'm requesting to be
> > > > > > > > > > > > > > merged from my simdgenius_inkscape branch
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 1. disable event compression (previously
> > > > > > > > > > > > > > mentioned)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 2. fix priority inversion
> > > > > > > > > > > > > > (09f55021, previously mentioned) - without
> > > > > > > > > > > > > > this, dragging objects too fast would cause
> > > > > > > > > > > > > > no redraw.
> > > > > > > > > > > > >  
> > > > > > > > > > > > > As noted before, when rulers are shown there
> > > > > > > > > > > > > still is no redraw with this change
> > > > > > > > > > > > >
> > > > > > > > > > > > > > 3. draw immediately (78d47938) this
> > > > > > > > > > > > > > partially reverts Krzysztof's Hack fest
> > > > > > > > > > > > > > 2016 changes like in 0.92.  This reduces
> > > > > > > > > > > > > > latency by ~10ms  (compare cells G22 and
> > > > > > > > > > > > > > E22 in spreadsheet)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I originally wanted to remove backing store
> > > > > > > > > > > > > > and draw directly to the window surface,
> > > > > > > > > > > > > > but I ran into this dilema so I didn't do
> > > > > > > > > > > > > > it.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 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
> > > > > > > > > [hidden email]
> > > > > > > > > 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

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

Tim Mayberry
In reply to this post by Tavmjong Bah
Hi,

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

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

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


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

Tim


On Tue, Mar 27, 2018 at 9:11 PM, Tavmjong Bah <[hidden email]> 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 <[hidden email]>
To: Tavmjong Bah <[hidden email]>
Subject: Re: Inkscape Boston Hackfest
Date: Tue, 27 Mar 2018 08:09:07 +0000
X-Proxad-Sc: state=HAM score=0

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

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

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

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

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

Tav

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


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


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

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

Yale Zhang
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:


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




On Thu, Mar 29, 2018 at 6:26 AM, Tim Mayberry <[hidden email]> wrote:
Hi,

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

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

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


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

Tim


On Tue, Mar 27, 2018 at 9:11 PM, Tavmjong Bah <[hidden email]> 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 <[hidden email]>
To: Tavmjong Bah <[hidden email]>
Subject: Re: Inkscape Boston Hackfest
Date: Tue, 27 Mar 2018 08:09:07 +0000
X-Proxad-Sc: state=HAM score=0

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

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

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

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

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

Tav

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


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



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

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

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

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


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


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

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

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

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

Earlier, I did pose a more general problem described here, but I didn't discuss it with the GTK folks:


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




On Thu, Mar 29, 2018 at 6:26 AM, Tim Mayberry <[hidden email]> wrote:
Hi,

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

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

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


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

Tim


On Tue, Mar 27, 2018 at 9:11 PM, Tavmjong Bah <[hidden email]> 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 <[hidden email]>
To: Tavmjong Bah <[hidden email]>
Subject: Re: Inkscape Boston Hackfest
Date: Tue, 27 Mar 2018 08:09:07 +0000
X-Proxad-Sc: state=HAM score=0

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

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

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

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

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

Tav

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


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




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