Dnia 19-11-2004, pi=B1 o godzinie 12:24 -0500, Michel D=E4nzer napisa=B3(=
> On Fri, 2004-11-19 at 12:51 +0100, Jacek Rosik wrote:
> > Am Fr, den 19.11.2004 schrieb Keith Whitwell um 12:14:
> > >=20
> > > 1) Do all drawing three times, avoiding the rectangle-blits and po=
> > > corruption.
> > >=20
> > > or
> > > 2) Make the X server do its drawing to the current frontbuffer (ra=
> > > just buffer 0), and then do the shadow-blits from that buffer.
> > >=20
> > > 2) is the more appealing option for me. I'm not sure how to get it=
to work in=20
> > > the context of the XAA pixmap cache which seems to be indexed from =
> > > origin as X's idea of the frontbuffer.
> The 2D acceleration hooks could check whether the coordinates are withi=
> the virtual screen size and adjust the buffer offsets accordingly.
> Nasty, but seems feasible.
> > For now I would also vote for #2. This could help some other things (=
> > GLcore could render directly into back buffer). But I think we need
> > combination of both. Method #2 won't do for stereo. There You have tw=
> > frontbuffers and everything rendered by X server should appear in bot=
> > buffers.
> How is that different from page flipping, where the X rendering has to
> appear in all buffers as well?
As Keith wrote, the problem is when you combine X drawing with GL
drawing. For current page flipping we have front and back buffers. When
we do some X drawing it should appear in *current* front buffer (it may
actually be front or back if pages are flipped). This drawing should not
appear in back buffer, as X doesn't know about back buffer and it may
destroy GL image in back. For stereo we have two front buffers and two
back buffers. X drawing has to appear in both front buffers. Simple
dirty rectangle copying from left buffer will not work as it may destroy
contents of left buffer which may be different, we should draw things
> > BTW: What is the reason that fb has alway width equal to virtual desk=
> > width (pScrn->displayWidth)? I think that Alan Hourihane said that
> > different width would screw up accelerator. But I don't see why.
> The accelerator imposes restrictions on the alignment of the pitch, so
> they're actually not always the same but happen to be for most
> resolutions commonly used today.
So accelerator may work on some fixed set of pitches if I understand
> Curious, why would you want a pitch that's larger than the required
I was just curious too ;). For stereo we have four color buffers so we
use a lot of pixmap cache. I thought that placing left buffers left will
leave more pixmap cache for X. I was thinking also about allocating more
than one depth/stencil buffer which would reduce reduce amount of pixmap
Jacek Rosik <paproch@...>