Split from bug 87485 Open attachment 112539 [details] and scroll up and down to see it (in your CPU cycles / call trace). More noticeable when scrolling with the scrollbar.
The whole implementation is rather suboptimal performance-wise for all VCL backends: - X11/GTK2 frequently call into XGetImage - GTK3 performs all rendering to system-memory surfaces, so all the scaling is done exclusivly by the CPU The different code-paths are the reason, why GTK3 is more handicapped by this.
GtkInstance::CreateVirtualDevice() explains the difference between GTK2/X11 and GTK3 - in case GTK3 is enabled, all rendering is performed on a software surface by the CPU, which is very slow for large image operations, but often faster for small drawing operations. I hope to find out why this descision was made.
I am happy and grateful that someone tackles this issue and is getting to the bottom of it. I am yet still on LibO 5.4.x and always compiling without gtk3 support since this gave me the least issues. Once I am done fighting Kernel compilation issues here and when the dust of LibO 6 landing has settled ;) I'll give v6 a try. Maybe any improvements and cleanups to any calls LibO issues to other libs might also improve things in other areas (I once had rendering issues w. precompiled LO on xf86-video-geode).
I wonder if this first patch currently in review may help: https://gerrit.libreoffice.org/#/c/49677/
Clemens: if you have some time perhaps you'd be interested in code contributing? (see https://wiki.documentfoundation.org/Development/GetInvolved) Indeed, you seem to know well X11/GTK2/GTK3 mechanisms, you may provide a great help!
(In reply to Julien Nabet from comment #4) > I wonder if this first patch currently in review may help: > https://gerrit.libreoffice.org/#/c/49677/ Nope, just tested it by cherry picking and building (looking at my CPU use).
The theming changes have no direct influcence on the chosen rendering backend implementation from what I have seen in the code. Following a discussion on the dev-mailinglist, I'll try to come up with a cairo/xlib based SalVirtualDevice when I find some spare time ... curious how this will work out.
this is not just about image rendering - all rendering with the GTK3 backend is slow, because it is performed on an image surface and therefore can not be hardware accelerated.
Caolán: thought you might be interested in this one since it concerns VCL and GTK3 specifically.
I mentioned on the list a route to go which may be useful.
Now after https://cgit.freedesktop.org/libreoffice/core/commit/?id=6eea5cffc4399fd31f97b19359eb6ae9c75d21b8 and https://cgit.freedesktop.org/libreoffice/core/commit/?id=b524de950c6eb0bc61d05d41fe69b67ab59b16c6 is here any discernible difference ?
@Buovjaga > Now after > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=6eea5cffc4399fd31f97b19359eb6ae9c75d21b8 and > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=b524de950c6eb0bc61d05d41fe69b67ab59b16c6 is here any discernible > difference ?
(In reply to Telesto from comment #12) > @Buovjaga > > Now after > > https://cgit.freedesktop.org/libreoffice/core/commit/ > > ?id=6eea5cffc4399fd31f97b19359eb6ae9c75d21b8 and > > https://cgit.freedesktop.org/libreoffice/core/commit/ > > ?id=b524de950c6eb0bc61d05d41fe69b67ab59b16c6 is here any discernible > > difference ? This was something that Clemens should have tested first and foremost, not me, but OK: gen and gtk3 seem to give the same amount of CPU cycles, so let's close as fixed.