On Sun, Mar 14, 2010 at 4:53 PM, Keith Whitwell
<keith.whitw...@googlemail.com> wrote:
> This looks like it introduces an extra full-window copying operation
> at every swapbuffers... is that correct?
> If so, I think we should try to figure out an alternative approach
> without the copying... would actually flipping between two textures
> (thus preserving the old back/new front) contents be workable?
Buffers swapping is handled in xmesa_swap_st_framebuffer. It is a zero-copy
operation.
This commit is to fix a bug when this code path is hit
/* draw something and ... */
glXSwapBuffers();
glReadBuffer(GL_FRONT);
glReadPixels();
In the above, glReadBuffer will cause BUFFER_FRONT_LEFT renderbuffer to be
added on demand as can be seen in st_ReadBuffer. The validation list would
become { ST_ATTACHMENT_FRONT_LEFT, ST_ATTACHMENT_BACK_LEFT }. When
glReadPixels is called, st/mesa will validate with the list and read from the
front buffer.
On the st/glx side, this use pattern is catched. When the front buffer is
allocated, the contents of the back buffer will be copied to the front buffer.
This happens only once. When the same code is run again, glXSwapBuffers will
swap the buffers.
The copying is required because xmesa_swap_st_framebuffer does not always swap
the buffers. It is so that only the back buffer is allocated when the
application never draws/reads the front buffer.
--
o...@lunarg.com
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
