Re: Gtk performance issues from a user's point of view

["David Turner" <david freetype org>]

Hello,

> This explains quite clearly why drawing a resized empty window is
> much faster than drawing the same window containing a window-sized
> button.
>
well, that's not a fair comparison. Drawing an empty window, resized or
not is going to be considerably faster than _anything_, double-buffering
or not :-)
 
> Plain window background is drawn at the X server side using the
> background color (or pixmap) specified by Gtk, whereas button
> drawing requires (client side) double buffering i.e. the _additional_
> operations of:
> - Drawing the button bg to offscreen double buffer
>    (part of the parent window)
> - Drawing the button contents (icon, label...) on top of that
> - Blitting the double buffer to the screen

The non-buffered scheme is:

- draw the background (in screen pixmap)
- draw the button contents on top (in screen pixmap)

The double-buffered one is:

- draw the background (in offscreen pixmap)
- draw the button content on top (in offscreen pixmap)
- copy the offscreen pixmap to the screen

clearly the additionnal step is one copy, and all three
should be hardware-accelerated, in _theory_. However, that
can only be true when the offscreen buffer is located in
VRAM, and all operations on it can be accelerated.

In practice, this is not always the case, for various reasons:

- XRender calls that are not hardware-accelerated on some cards,
  resulting in sluggish performance (e.g. subpixel-rendered
  anti-aliased text); this is especially painful if your offscreen
  pixmap is in VRAM, because all composition in done in software
  and reading video memory through the PCI bus is incredibly
  slow, like at least 10x the latency of system memory. I don't
  know about PciExpress though, maybe things are better with
  this architecture ?

- The VRAM is already full of pixmaps generously "cached"
  there by applications (e.g. FireFox likes to place a ton
  of images in the XServer), so your offscreen pixmap is
  going to be allocated in system memory. Adieu ma performance,
  when copying the offscreen to VRAM.

- you want to draw some pixmaps (e.g. icons) which have been
  allocated in system memory, blitting is going to be a lot
  slower than optimal.

In some cases, getting rid of double-buffering might be useful,
but only because it would reduce global VRAM memory usage, thus
increasing the chances of having everything working smoothly.

> I.e. >3x data needs to be copied around.
> Did I understand correctly?
> 
I think that the >3x figure is a tad bit exagerated :-)
Besides, the volume of data becomes insignificant if we're doing
VRAM => VRAM transfers.

> (And if composite is used, then this went to X server side double
> buffer (texture) from which it's composited onto screen.)
> 
I can't comment on that, so I'll leave to the experts.

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)