On Tue, May 5, 2009 at 2:34 PM, Jesse Barnes <jbar...@virtuousgeek.org> wrote: > 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?).
I wayland page flipping/copying, double, triple or n-buffering is all client side decisions. Wayland only knows about the front buffer (which doesn't have child windows or other cliprects), all the other buffers are managed by the client. The client can do page flipping by passing attaching a new buffer handle to the surface or copy (all or regions) from a temp/back buffer to the wayland surface. How many buffers to keep around and whether or when to block rendering is up to the client. > On X, we unfortunately always have to do the copy to the front buffer, > though we could probably get smarter about the frequency. The main reason we can't easily promise flipping under X is child windows and clip-rects. We could fake it by copying back the dirty regions from the new front to the back just after the flip, at that point it's not really worthwhile anymore, and definitely too complex. cheers, Kristian ------------------------------------------------------------------------------ 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
