On Tue, 05 May 2009 11:24:29 -0700 Ian Romanick <i...@freedesktop.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Kristian Høgsberg wrote: > > On Tue, May 5, 2009 at 12:20 PM, Jesse Barnes > > <jbar...@virtuousgeek.org> wrote: > >> On Mon, 04 May 2009 19:14:29 -0700 > >> Ian Romanick <i...@freedesktop.org> wrote: > >> > >>> Having this ability would allow us to advertise some fbconfigs > >>> with GLX_SWAP_METHOD_OML = GLX_SWAP_COPY_OML. We obviously don't > >>> have any apps that use that today, but I can think of a couple > >>> that should. :) > >> Yeah, ok. > > > > It's not something that needs to be exposed in the protocol or dri2 > > module. If you want the copy behaviour, use DRI2CopyRegion(). > > Another point about GLX_SWAP_METHOD_OML is that we can't really > > implement the "always swap" (GLX_SWAP_EXCHANGE_OML) behaviour > > without a fair bit of yucky code, and without that we can't really > > claim to support the extension. > > I think you misunderstand the extension. The fbconfig has an extra > value that says "this is how glXSwapBuffer happens." The three > possible values are: flip, copy, unknown. Right now we support this > extension, but we always say unknown. As you point out, I doubt we'd > ever be able to say flip, but we might be able to say copy and > unknown. Telling the application flip isn't terribly useful, but a > lot of applications could do something smart (i.e., partial screen > updates) if they knew the swap method was always copy. Right? Actually I think we could do flip as well, depending on the expected semantics. If all apps had fake front buffers (i.e. private back *and* front buffers), we could simply exchange those two at swapbuffers time. That assumes a reasonably intelligent compositing manager though; we wouldn't want to immediately follow any swap by a copy to the real front buffer or there'd be no benefit. However if the compositing manager was responsible for copying all the fake fronts to the real front if swaps had occurred it could be a win in terms of consumed bandwidth and swap latency (I think Wayland does it this way?). On X, we unfortunately always have to do the copy to the front buffer, though we could probably get smarter about the frequency. -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
