preformance issues with oxygen style and window decoration

[Maksim Orlovich]

> Maksim Orlovich wrote:
>> Well, the above will likely negate what I am about to say; but this
>> thread
>> reminded me that I've seen a hotspot/inefficiency in oxygen in some
>> profiles, so I looked at it some more. In short, could you please try
>> the
>> attached patch? It's proof-of-concept only; it has not been reviewed
>> by/discussed with Oxygen developers, but it'll hopefully say if it's
>> worth
>> addressing or not.
>
> Without comparing to the actual sources, I'm curious, why would reducing
> the pixmap size by 10 px make a significant difference? (It's nice to
> note that when posting a patch...)

It was asking to draw a pixmap of height 64px to a 54px height, e.g. to
scale it down. Doing that in current Qt[1] involves converting it back to
an image --- e.g. transferring data from the X server (or worse, GPU) back
to the application (and the app blocking waiting for it), scaling it, then
transferring it back to draw --- in this case, all needlessly. With the
fixed version, it uploads the proper version once, and every time it draws
it, it merely sends a draw request with pixmap ID, asynchronously (so
there is no extra blocking or context-switching) to X, which will
hopefully execute it with HW accel, perhaps not even transferring any data
between the GPU and the CPU besides the draw request.

There are some other instances of such problems around, BTW, in e.g.
KPixmapCache, but I don't know if they're hot enough to warrant changes.

[1] With modern XRender, it's possible to ask that to scale, but Qt
doesn't do that, and I don't know how well that performs these days.