<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<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#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 <span class="vcard"><a class="email" href="mailto:lil_tux@web.de" title="Heiko <lil_tux@web.de>"> <span class="fn">Heiko</span></a>
</span></b>
<pre>(In reply to Antoine Labour from <a href="show_bug.cgi?id=90264#c37">comment #37</a>)
<span class="quote">> 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.</span >
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>
</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>