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

[bugzilla-daemon at freedesktop.org]

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

Antoine Labour <piman at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |piman at chromium.org

--- Comment #39 from Antoine Labour <piman at chromium.org> ---
(In reply to Heiko from comment #38)
> (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

Maybe, I'm not a DRI2 (or 3 or n) expert.

There is fundamentally a race between X and GL during resize, because the back
buffer is supposed to be the same size as the window, but the window gets
resized on the X server, whereas the back buffer is a property of the client
and/or the GL stream. So, at some point, the client needs to take a "snapshot"
of the window dimensions to operate, and problems come up if the window gets
resized between the time the snapshot is taken and the time glXSwapBuffers
occur. I think that's what's happening in this bug. It sounds like the
referenced commit changes when the snapshot is taken.

>From my quick reading of the radeon driver (sorry, I'm absolutely not familiar
with the codebase), if I understand correctly, it looks like that snapshot is
taken with the DRI2GetBuffer{,WithFormat}, via radeon_update_renderbuffers,
which is called in a few places, notably in radeon_viewport, which was always
called on every glViewport before
http://cgit.freedesktop.org/mesa/mesa/commit/?id=95073a2dca03a48f4c77bc846a4a6d1f0eb81ae6
, but after which is only called on non-redundant glViewport.
radeon_update_renderbuffers is also called on radeonMakeCurrent, which is
called on non-redundant glXMakeCurrent, and on radeon_prepare_render when dri2
stamps don't match which I think is meant to capture querying new buffers after
glXSwapBuffers. There's a couple of other places too, but they may not matter
for this.


So, I guess there could be a couple of workarounds in chrome to force
radeon_update_renderbuffers (e.g. non-idempotent glViewport or glXMakeCurrent),
but they're hacks. Or the driver could make sure it invalidates whatever is
needed in glXWaitX, because that's what the user uses to synchronize between X
and GL (i.e. you can assume that something in X has changed).

-- 
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/e9ffecab/attachment.html>