Keith Packard <[EMAIL PROTECTED]> writes:
> On Wed, 2007-11-28 at 06:19 +0100, Soeren Sandmann wrote:
>
> > - When a client wishes to copy something to the frontbuffer (for
> > whatever reason - glXSwapBuffers(), glCopyPixels(), etc), it uses
> > plain old XCopyArea() with the generated pixmap. The X server is
> > then responsible for any clipping necessary.
>
> Using a plain old XCopyArea will make scheduling this in the kernel
> quite a bit harder; if the kernel knows it's doing a swap buffer, then
> it can interrupt ongoing rendering and do the copy at higher priority,
> precisely when the vblank interrupt lands.
Waiting for vblank is only really interesting for full-screen,
non-clipped clients. In the non-fullscreen case, XCopyArea() type
blitting will actually look better than out-of-band blitting beit
avoids the strange effect where the contents of a window seems to lag
behind the frame when you drag it around. And the clipped case is
slowly going away as compositing becomes the norm.
So in the interesting case the X server would see a fullscreen
CopyArea that was preceded by some sort of wait-for-vblank request
(using SYNC or some other mechanism). The X server then calls a
copy_contents (buf_obj src,
buf_obj dest,
bool wait_blank);
interface in the kernel which will schedule the blit at next vblank
and send a notification back to the server when the blit has finished
and the source buffer can be reused.
Page flipping could be done similarly. A new request
SwapArea (Drawable src, Drawable dest,
int src_x, int src_y,
int width, int height,
int dest_x, int dest_y)
would be added to the server, and a corresponding
swap_contents (buf_obj obj1,
buf_obj obj2,
bool wait_blank);
to the kernel for the full-screen case. The kernel interface would use
pointer swizzling and page-flips if possible.
If clip rectangles appear while these commands are outstanding, the X
server would just wait for them to complete. Going from "no clip" to
"clip" will be much, much less common than going from "clip" to
"different clip".
So basically, using XCopyArea() doesn't rule out having the
implementation in the kernel.
> Plus, you've just added the latency of a pair of context switches to
> the frame update interval.
I don't think it is realistic to completely avoid switching to the
server in the course of a frame update for these reasons:
- If the client is a compositing manager, then it wouldn't be drawing
at all unless it was getting damage events from the server
- Clients often get input events at a frequency on the order of 100Hz.
- GL pixel copying routines such as glXSwapBuffer() need to generate
damage events. With XCopyArea() we get them almost for free.
Soren
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
