[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.

I agree that mouse traffic is small for GUIs such as menus with
arbitrary coloured backgrounds and various icons.

For X apps that have plain backgrounds, the traffic is much less.

It just boils down that without X extensions to cache various
client-created graphic objects, current widget toolkits use
more bandwidth.

If the X server can cache polygon lists for everything, it could
help, but puts more performance problems into the server.

> 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.

Only if the full widgets are drawn and the clipping is done in the X server,
or if the overhead of sending two exposure updates is large compared to
the actual drawing payload.

 > Probably more important is that expose event asynchronicity can cause
> many many more updates than should be necessary.

Expose events should only happen when they are required. They may be
asynchronous, but they should only happen for areas that need to be
redrawn.

> 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.

There shouldn't be. XCreateWindow(), XDestroyWindow(), XSelectInput() etc.

> Also everybody should be familiar with the horrible artifacts and slow update
> and flashing that this approach makes.

I've seen it in various toolkits i've used. I couldn't fix them, so i don't use
them anymore.

> 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.

It doesn't negate the argument, because i've found all the "current" toolkits
are slow over non-local networks that i've seen.

> 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.

I have thought of abandoning child X windows, and doing the same functionality 
in the client. The network problems of X can be avoided if you can make other
non-visual parts of the application work over the network. That way, Input
devices can be accessed directly from the kernel. I never liked the network
getting in the way of a gui interface anyway.