David Reveman wrote:
Biggest problem with using Xgl and compiz on DRI drivers is that I can't
efficiently update part of the screen. On proprietary drivers it's
efficiently done by using DrawBuffer (GL_FRONT) and CopyPixels.
The attached patch for mesa 6.4.2 is just something I created to prove
that Xgl and compiz runs very well on the Intel driver once this is
fixed.
I'd like to get this solved asap. I suggest that we add support for
GLX_MESA_copy_sub_buffer. If I remove the CopyPixel hack from my Intel
driver patch, that's pretty much what we have.
Xgl will use GLX_MESA_copy_sub_buffer instead of CopyPixels when
available and we'll add protocol support so that compositing managers
can use it.
Thoughts?
I'll probably go ahead and get this done in the next few days if no one
objects.
Is there anything wrong with just using glCopyPixels all the time? If
it's just a matter of speed, we can certainly try to optimize that path.
GLX_MESA_copy_sub_buffer is a bit of an old hack and I'm not sure it's
something we want to promote going forward.
Another option is the new GL_EXT_framebuffer_blit extension which adds
the glBlitFramebufferEXT() function. It's like glCopyPixels() but has
potential for higher speed.
BTW, I think your patch needs to check more state to see if any
per-fragment operations are enabled.
-Brian
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
