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) _______________________________________________ Performance-list mailing list Performance-list@gnome.org http://mail.gnome.org/mailman/listinfo/performance-list
