Performance change from X in Fedora Core 4 to Fedora Core 5

[Carsten Haitzler (The Rasterman)]

On Mon, 10 Jul 2006 22:41:16 +0100 Felix Bellaby <felix at bellaby.plus.com>
babbled:

> On Mon, 2006-07-10 at 11:06 -0400, Owen Taylor wrote:
> > - in the composited architecture, there already *are* persistent double
> > buffers for all toplevel windows, so investigating using those in some
> > way could be interesting. What you have to avoid is the compositing
> > manager doing tons of extra work in this case.
> 
> Back buffering within applications & toolkits should almost certainly be
> avoided when a compositor is running. The Xcomposite design buffers
> everything that apps draw into offscreen pixmaps already and the
> compositor may well be using a further layer of double buffering when
> drawing those offscreen pixmaps onto the visible screen.

that presents a problem. a big one. how do you then get artifact-free updates
of a window? sure - if you mean permanently keeping a full window sized pixmap
- i agree - don't keep it around all the time. when you need to redraw a
section of a window, allocate a pixmap big enough - draw to it, then copy it to
the real window. the problem is that there is no way to pause xdamage
reports, draw to the window then tell xdamage "ok- now flush all my window
draws you just queued - merging them into a minimum rect list". the only way
to do that effectively (i know of) is to draw to an offscreen pixmap first.

> What we should be aiming to do is avoid the generation of damage reports
> until we are ready to display the finished drawing. The compositor will
> ignore drawing operations until the damage is reported, allowing the off
> screen pixmap to act as a buffer. Then the compositor will set about
> displaying the pixmap when the damage is reported, effectively
> performing a buffer swap. Compositors already do this automatically so
> you are not putting any extra burden on them whatsoever.

and how do you do that? that's the problem.. There is no mechanism to
freeze/thaw or artificially inseminate xdamage (and force it to be turned off).
admittedly - if this was possible i 100% would agree - draw in-place as this
saves a tmp buffer inbetween.

> Ensuring that damage is only reported when the app / toolkit is ready
> for a buffer swap probably requires a suitable hook in the server that
> performs the buffer swap operation. One might hope that the DBE
> extension or a properly designed variation might do the job. 

hmm - i think it simply needs xdamage additions to force 1 window (and its
children optionally) out of the xdamage world so xdamage doesn't auto-report
changes, and then add a way of manually reporting them (and add a way to detect
if a window is part of an xdamage tree/region).

we still have 1 more problem. if the compositor decides to update for another
reason (animation - fade in, another window on top/below changed WHILE a window
in the same screen region is doing a redraw), then you will get artifacts - you
will see the partially redrawn state which will frankly - look bad, so you are
back to the only viable solution - a (tmp) buffer to draw to before copying it
to the window. note - i am talking about manual double buffering - not gl
buffers/double buffer extension.

> The developers of the X server and its drivers can not be expected to
> optimise the behavior of apps and toolkits that allocate pixmaps all
> over the place. However, they could certainly make a stab at optimising
> a consistent and sensible double buffering extension.
> 
> I understand that nVidia have left damage reporting for double buffered
> GL drawing until glXSwapBuffers is called. I think that have things
> right here.
> 
> Felix
> 
> 
> 
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)