[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 #44 from Heiko <lil_tux at web.de> ---
(In reply to Antoine Labour from comment #43)
> I see, the XResizeWindow would cause a DRI2 Invalidate event on the server
> side, and the XSync would make sure it's handled on the client before
> anything else happens. That seems like it would do the right thing (at the
> cost of a server round-trip).

Well, from what I figured, chromium gets about 2-5 XExpose events per tooltip
resizing after the XMapWindow call. As per XMapWindow manpage, the tooltip
window seems to get tiled into the original region plus horizontal extension,
plus vertical extension. Though, sometimes, there's additional XExpose for
another horizontal extension of the tooltip. Thus you get 2-5 Calls into
::ScheduleRedrawRect and probably also 2-5 calls to glViewport (I bet that's
the reason for the 'weird' values I found in apitrace). Also there are some
XExpose events with send_event true. 

Would it be possible to build a single (damage_)rect (for a time slice) to get
most or all parts of the tooltip into one draw call?

For the generic case: I thought one would need the round-trip to the server to
make sure X and GL are in sync. Or what would be some other way; short sleep,
some GL-Redraw? Not sure how the binary blobs handle this, but I bet they also
call XSync/XFlush.

-- 
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/20150804/3a8a6caa/attachment.html>