Download it now!
Bug 115702 - Optimise GTK3 rendering
Summary: Optimise GTK3 rendering
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: All Linux (All)
: medium minor
Assignee: Not Assigned
Keywords: perf
Depends on:
Blocks: GTK3
  Show dependency treegraph
Reported: 2018-02-14 07:35 UTC by Buovjaga
Modified: 2018-06-26 06:32 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Buovjaga 2018-02-14 07:35:05 UTC
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.
Comment 1 Clemens Eisserer 2018-02-14 07:40:06 UTC
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.
Comment 2 Clemens Eisserer 2018-02-14 09:35:00 UTC
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.
Comment 3 just-me 2018-02-14 10:01:39 UTC
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).
Comment 4 Julien Nabet 2018-02-14 12:44:14 UTC
I wonder if this first patch currently in review may help:
Comment 5 Julien Nabet 2018-02-14 12:52:31 UTC
Clemens: if you have some time perhaps you'd be interested in code contributing? (see
Indeed, you seem to know well X11/GTK2/GTK3 mechanisms, you may provide a great help!
Comment 6 Buovjaga 2018-02-14 15:07:30 UTC
(In reply to Julien Nabet from comment #4)
> I wonder if this first patch currently in review may help:

Nope, just tested it by cherry picking and building (looking at my CPU use).
Comment 7 Clemens Eisserer 2018-02-14 16:00:17 UTC
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.
Comment 8 Clemens Eisserer 2018-02-23 06:43:41 UTC
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.
Comment 9 Julien Nabet 2018-02-23 08:07:13 UTC
Caolán: thought you might be interested in this one since it concerns VCL and GTK3 specifically.
Comment 10 Caolán McNamara 2018-02-23 14:04:58 UTC
I mentioned on the list a route to go which may be useful.
Comment 12 Telesto 2018-06-25 20:26:44 UTC
> Now after
> ?id=6eea5cffc4399fd31f97b19359eb6ae9c75d21b8 and
> ?id=b524de950c6eb0bc61d05d41fe69b67ab59b16c6 is here any discernible
> difference ?
Comment 13 Buovjaga 2018-06-26 06:32:48 UTC
(In reply to Telesto from comment #12)
> @Buovjaga 
> > Now after
> >
> > ?id=6eea5cffc4399fd31f97b19359eb6ae9c75d21b8 and
> >
> > ?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.