<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:piman@chromium.org" title="Antoine Labour <piman@chromium.org>"> <span class="fn">Antoine Labour</span></a>
</span> changed
<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>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>piman@chromium.org
</td>
</tr></table>
<p>
<div>
<b><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#c39">Comment # 39</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 <span class="vcard"><a class="email" href="mailto:piman@chromium.org" title="Antoine Labour <piman@chromium.org>"> <span class="fn">Antoine Labour</span></a>
</span></b>
<pre>(In reply to Heiko from <a href="show_bug.cgi?id=90264#c38">comment #38</a>)
<span class="quote">> (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></span >
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
<a href="http://cgit.freedesktop.org/mesa/mesa/commit/?id=95073a2dca03a48f4c77bc846a4a6d1f0eb81ae6">http://cgit.freedesktop.org/mesa/mesa/commit/?id=95073a2dca03a48f4c77bc846a4a6d1f0eb81ae6</a>
, 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).</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>