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? > 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. Curious, why would you want a pitch that's larger than the required minimum? -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer ------------------------------------------------------- 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
