https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #37 from Antoine Labour <pi...@chromium.org> --- (In reply to Heiko from comment #35) > Just some more input > > Debuggable with smth like > `/usr/lib/chromium-browser/chrome --user-data-dir=/tmp/fake --no-sandbox > --enable-gpu-debugging --gpu-launcher="xterm -e gdb --args"` and break at > gfx::NativeViewGLSurfaceGLX::Resize > > 531 bool NativeViewGLSurfaceGLX::Resize(const gfx::Size& size) { > 532 size_ = size; > 533 glXWaitGL(); > 534 XResizeWindow(g_display, window_, size.width(), size.height()); > 535 glXWaitX(); > 536 return true; > 537 } > > Is called for every tooltip. Looks like the tooltip xwindow is resized: > (gdb) x/2d $rsi > 0x7fffffffc2f0: 221 21 ('New tab' tooltip 221x21) > (gdb) x/2d $rsi > 0x7fffffffc2f0: 370 72 (chromium bug 442111 tooltip 370x72) > > From the 'New tab' tooltip to chromium bug 442111 tooltip, the gl calls > looks really wierd. The final tooltip should be 370x72, but the gl calls > setup something from the old 112x21 tooltip plus the missing 51px to get to > Xx72 > > 100959 glUseProgram(program = 15) > 100960 glDisable(cap = GL_SCISSOR_TEST) > 100961 glScissor(x = 0, y = 51, width = 112, height = 21) > 100962 glViewport(x = 0, y = 0, width = 59, height = 21) > 100963 glBindTexture(target = GL_TEXTURE_2D, texture = 145) > 100965 glTexParameteri(target = GL_TEXTURE_2D, pname = > GL_TEXTURE_MIN_FILTER, param = GL_LINEAR) > 100967 glTexParameteri(target = GL_TEXTURE_2D, pname = > GL_TEXTURE_MAG_FILTER, param = GL_LINEAR) > 100969 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_S, > param = GL_CLAMP_TO_EDGE) > 100971 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_WRAP_T, > param = GL_CLAMP_TO_EDGE) > 100974 glBindTexture(target = GL_TEXTURE_2D, texture = 145) > 100977 glTexStorage2D(target = GL_TEXTURE_2D, levels = 1, internalformat = > GL_RGBA8, width = 370, height = 72) > 100980 glBindTexture(target = GL_TEXTURE_2D, texture = 145) > 100983 glTexSubImage2D(target = GL_TEXTURE_2D, level = 0, xoffset = 0, > yoffset = 0, width = 370, height = 72, format = GL_BGRA, type = > GL_UNSIGNED_BYTE, pixels = blob(106560)) > 100987 glXWaitGL() > // right here the above ::Resize is called for the xwindow.. probably > confusing Mesa? > 100988 glXWaitX() > > Iirc from my last post, radeon_draw_buffer() does re-evaluate window sizes. > That's probably why the reverted commit makes things work again. 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. -- 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 mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev