[cairo] How to test the gl backend?

[Russell Shaw]

Bill Spitzak wrote:
> 
> 
> Russell Shaw wrote:
>> Bill Spitzak wrote:
>>> On 06/04/2010 05:53 AM, Russell Shaw wrote:
>>> 
>>>> If gtk only uses top-level X windows, that means gtk has to register 
>>>> for always-on mouse-motion events. Urgh...
>>> 
>>> I think you are seriously in error about guessing what is inefficient!
>>> 
>>> Believe me, creating and managing a hundred X windows requires ORDERS OF
>>> MAGNITUDE more communication to the server than an event every time the
>>> mouse moves 1 pixel. Besides it probably turned on mouse tracking for
>>> those individual windows anyway!
>> 
>> In a properly done widget tool kit, no events are emitted from the X server
>>  unless the mouse or keyboard button is pressed, or if the mouse crosses
>> the border of a window (only if the widget registered for those events). 
>> Continuous mouse-motion events are usually only used in drag operations 
>> when a mouse button is held down.
>> 
>> Continuous mouse-motion emission of events from the X server will make 
>> networked applications utterly unuseable on all but the fastest (ie local) 
>> networks.
> 
> That communication is trivial compared to other data. It is one event per
> pixel LINEAR, while many api's require drawing images, glyphs, or other very
> fine graphics that scale approximately by the AREA of the widgets.
> 
> Overlapping widgets can in effect double the time taken to draw the 
> overlapped area, especially in the worst case where an image must be sent for
> both. Probably more important is that expose event asynchronicity can cause
> many many more updates than should be necessary. There is also an ENORMOUS
> amount of data that must be sent to set up and take down an X window and to
> keep communicating with it, and to update it's position, etc. And there is a
> nasty amount of overhead in the X server itself to manage them.
> 
> Also everybody should be familiar with the horrible artifacts and slow update
> and flashing that this approach makes.
> 
> You also seem to be ignoring the fact that all toolkits I am familiar with
> turn on mouse tracking all the time, thus completely negating your entire
> argument, plus adding enter+exit events to the communication overhead.
> 
> The fact is that communicating the widget areas to the server is a losing
> propostion all around. It is losing on Windows too, even though they force
> synchronous update. That is why Qt and GTK and FLTK have all abandoned child
> windows, and why Microsoft is trying to force people off of MFC.

There is one big reason why sub X-windows is useful.

If you have an area displaying a 400x600 pixel page of eg a word processor
and scroll it up by 10 pixels, then you'd have to issue XMoveWindow(10 pixels) 
and redraw a 400x10 pixel area. Even better would be to have the X server cache
each sub-window, and so moving the window could make the X server redraw the
newly uncovered areas automatically.

With one top-level X window for the whole tree of widgets, every time you
scroll that area even by 1 pixel, you're forced to redraw a 400x600 pixel
area. Is doable on a local system, but hopeless on a slower network.