https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #38 from Heiko <[email protected]> --- (In reply to Antoine Labour from comment #37) > Can you make glXWaitX "re-evaluate window sizes"? That's the reason we call > it - we just resized the window, we want to make sure we're drawing to the > right back buffer. This is a UI workload, we may draw only once and we don't > want flashing (what a glXSwapBuffers would do), so we want to make sure > we're drawing to a buffer of the right size - glXWaitX is meant to > synchronize GL with changes in X. > > In this trace, you're only seeing parts of the calls - in particular there > should be a glViewport and draws and a glXSwapBuffers after the resize. > > I don't think there's confusion from the app side. Parts of what you're > seeing is chromium restoring state between its "virtual contexts" (we have > different subsystems that all need to access GL, and are multiplexed, > possibly on a single GL context, depending on the version), so it's not > necessarily surprising to see scissor/viewport that doesn't match the window > size - until we get to actually draw the picture on screen. In particular, > the texture is correctly loaded with 370x72, so no confusion there. Well, most of my findings were pretty vague, because I'm neither a GL expert nor a mesa expert. With your hint, I just noticed that dri2_wait_x()/dri2_wait_gl() don't do anything, because of priv->have_fake_front being zero all the time. It would be set to 1 for buffer attachments of __DRI_BUFFER_FAKE_FRONT_LEFT, but that's nowhere set in mesa. Thus gcc just optimized it away completely along with dri2_copy_drawable(). Seems to be related to [1]? [1] http://lists.freedesktop.org/archives/mesa-dev/2011-June/008241.html -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
