Hi! Dnia 19-11-2004, pią o godzinie 12:24 -0500, Michel Dänzer napisał(a): > On Fri, 2004-11-19 at 12:51 +0100, Jacek Rosik wrote: > > > > Am Fr, den 19.11.2004 schrieb Keith Whitwell um 12:14: > > > > > > 1) Do all drawing three times, avoiding the rectangle-blits and > > > possible > > > corruption. > > > > > > or > > > 2) Make the X server do its drawing to the current frontbuffer (rather > > > than > > > just buffer 0), and then do the shadow-blits from that buffer. > > > > > > 2) is the more appealing option for me. I'm not sure how to get it to > > > work in > > > the context of the XAA pixmap cache which seems to be indexed from the > > > same > > > origin as X's idea of the frontbuffer. > > The 2D acceleration hooks could check whether the coordinates are within > 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 (eg. > > 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 two > > frontbuffers and everything rendered by X server should appear in both > > 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 twice. > > BTW: What is the reason that fb has alway width equal to virtual desktop > > 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 properly. > Curious, why would you want a pitch that's larger than the required > minimum? 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 cache further. Best, -- Jacek Rosik <[EMAIL PROTECTED]> ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
