<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [Regression, bisected] Tooltip corruption in Chrome" href="https://bugs.freedesktop.org/show_bug.cgi?id=90264#c38">Comment # 38</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [Regression, bisected] Tooltip corruption in Chrome" href="https://bugs.freedesktop.org/show_bug.cgi?id=90264">bug 90264</a> from <a class="email" href="mailto:lil_tux@web.de" title="Heiko <lil_tux@web.de>"> Heiko</a> <pre>(In reply to Antoine Labour from <a href="show_bug.cgi?id=90264#c37">comment #37</a>) > 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] <a href="http://lists.freedesktop.org/archives/mesa-dev/2011-June/008241.html">http://lists.freedesktop.org/archives/mesa-dev/2011-June/008241.html</a></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>