https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #44 from Heiko <lil_...@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.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
