From 311e40268414649f047ee177ba22a17a2d437843 Mon Sep 17 00:00:00 2001 From: Brian Paul Date: Wed, 9 Apr 2008 18:39:51 -0600 Subject: gallium: more elaborate tracking of front color buffer state This fixes the case where the app calls SwapBuffers then calls glReadPixels to read the front color buffer. We now keep track of when the front buffer is a _logically_ copy of the back buffer (after SwapBuffers) and read from the back color buffer instead of the front. --- src/mesa/state_tracker/st_cb_flush.c | 27 ++++----------------------- 1 file changed, 4 insertions(+), 23 deletions(-) (limited to 'src/mesa/state_tracker/st_cb_flush.c') diff --git a/src/mesa/state_tracker/st_cb_flush.c b/src/mesa/state_tracker/st_cb_flush.c index 1bcd1b4cd9..1b3402cee2 100644 --- a/src/mesa/state_tracker/st_cb_flush.c +++ b/src/mesa/state_tracker/st_cb_flush.c @@ -44,30 +44,10 @@ #include "pipe/p_winsys.h" -static GLboolean +static INLINE GLboolean is_front_buffer_dirty(struct st_context *st) { - GLframebuffer *fb = st->ctx->DrawBuffer; - - if (!fb) - return GL_FALSE; - - /* XXX: temporary hack. This flag should only be set if we do any - * rendering to the front buffer. - * - * Further more, the scissor rectangle could be tracked to - * construct a dirty region of the front buffer, to avoid - * situations where it must be copied repeatedly. - * - * In the extreme case, some kind of timer could be set up to allow - * coalescing of multiple flushes to the frontbuffer, which can be - * quite a performance drain if there are a sufficient number of - * them. - */ - st->flags.frontbuffer_dirty - = (fb->_ColorDrawBufferMask[0] & BUFFER_BIT_FRONT_LEFT); - - return st->flags.frontbuffer_dirty; + return st->frontbuffer_status == FRONT_STATUS_DIRTY; } @@ -86,7 +66,8 @@ display_front_buffer(struct st_context *st) */ st->pipe->winsys->flush_frontbuffer( st->pipe->winsys, front_surf, st->pipe->priv ); - st->flags.frontbuffer_dirty = 0; + + st->frontbuffer_status = FRONT_STATUS_UNDEFINED; } -- cgit v1.2.3