[Mesa-dev] [Bug 90264] [Regression, bisected] Tooltip corruption in Chrome

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=90264

--- Comment #37 from Antoine Labour <piman at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150722/707f0ede/attachment.html>