Severe performance regression with gtk3 on Windows

A big hit in performance seems to be a major performance regression in gtk3 which is occuring when disabling client side decorations (CSD), see upstream bug [1].

Client side decorations are basically window decorations (borders, title bar) and gtk3 introduced the possibility to draw UI elements into these areas (which Inkscape does not use, though). This feature requires GTK to draw these parts itself instead of off-loading this work to the OSs window manager.

CSD therefore results in the window looking non-native on Windows (it's using the default Adwaita theme - even for borders - as there is no system theme like in other OSs). Even worse, CSD breaks most functionality of the window manager (like aero snap and related features). See [2] for the upstream request to disable CSD on Windows by default and bugs linked from there for details.

MSYS2 already decided to go ahead and disable CSD by default [3].

By enabling CSD again (e.g. by setting the environment variable GTK_CSD=1) performance of Inkscape increases significantly (not to the level of gtk2 builds, though), so this could be a workaround in the worst case scenario (gtk3 - as so often for win32 related issues - doesn't give a sh*t and ignores this issue and we can not figure something out ourselves).
I'm pretty sure we'll get a lot of heat when shipping Inkscape without native window decorations and with crippled functionality, though, and to be honest I feel users would be completely right to give us heat if we choose this crappy solution...

[1] https://bugzilla.gnome.org/show_bug.cgi?id=781153
[2] https://bugzilla.gnome.org/show_bug.cgi?id=778791
[3] https://github.com/Alexpux/MINGW-packages/pull/2981

As mentioned in the last comment, even when enabling CSD, performance with gtk3 in master is worse than with gtk3 in 0.92.x.

I'm having a hard time to quantify this, but when using 0.92.x and master side by side the difference becomes obvious. Perceived perfomance ("responsiveness") of the gtk3 version is still off...

One potential reason could be the refactoring done during the Hackfest in 2016. Those changes were reverted in 0.92.x (see bug #1571192 for details) but are still part of master. As far as I understood gtk3 should *not* have been affected by this change but we can't know for sure as we were not able to do gtk3 builds on Windows at that time.

I tried to investigate this once by building 0.92.x with gtk3 so I could do a direct comparison, but unfortunately I ended up with a working compile that had one "small" issue: It didn't show the canvas at all, so obviously the build was unusable to determine any performance differences...

If the GTK3 developers "don't give a sh*t" as you say, if they prefer the "decorations" (it is a fortunate word isn't it?) over functionality, could it be high time to port the whole project to QT?

I realize it would be an ambitious undertaking, but it is not without precedent. Wireshark is probably the biggest project ported away from GTK; that was done two years ago (and accomplished to beta in six months), and they have not looked back.

Although it would represent a substantial investment in development time it would end the latency issue, which I've experienced and read about since at least version 0.48. Since this project has a relatively high profile, you might be able to get some sponsorship or development assistance from QT. In the end I think the application would perform better and be more maintainable.

If there is a philosophical barrier to QT, I'd like to know what it is. Also I would be glad to donate to the project to help with the cost of porting or the development time.

First of all, I don't want any bad blood here... I was a bit rude there which was mostly the frustration talking and I'm sorry about that. GTK+ is a great project (I don't want to diminish anybody's effort) but it has its rough edges, no question (especially if you're on Windows/Mac and don't want to create the GNOME desktop). If you want a "good" laugh watch [1], that's how I'm feeling most of the time and while entertaining it caries a scary bit of truth.

That being said, Inkscape code is *huge* and we don't even have enough resources to properly support GTK+3 (and we're "only" switching from GTK+2 here!). Rewriting Inkscape in Qt - while it might no be a bad thing - is pretty much out of the question unless you plan to hire several developers full-time. While others might disagree, Inkscape certainly is not lacking the money but the developer time (and I'm not sure how you plan to "dontate" that). If you have any ideas, though, I welcome you to join us on the mailing list in inkscape-devel and discuss those possibilities with us!

One more idea: Having some more develper ressources in the GTK+ project looking after the currently neglected backends and usage scenarios might be a good path into the future, too!

[1] http://mirror.linux.org.au/pub/linux.conf.au/2014/Thursday/83-Gtk_to_Qt_-_a_strange_journey_-_Dirk_Hohndel.mp4

Version 1.0 of inkscape came out, is this still a bug ?

If so + "Inkscape certainly is not lacking the money but the developer time", then maybe hiring one of the consultancies that work with Gtk to attempt to fix the issues on Windows could be an option ?

Then again, Gtk 4 looks like it will be built with better hardware acceleration, so there is always that.