[cairo] How to test the gl backend?

[Russell Shaw]

Benjamin Otte wrote:
> On Fri, 2010-06-04 at 23:28 +1000, Russell Shaw wrote:
>> 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.
>>
> A mouse motion event is ~50 bytes. With roughly 100 motion events per
> second (timed with moving the mouse over xev) that's 5kB/s and works
> fine over a modem. _If_ you frantically move the mouse.

Maybe so, but it seems unneccessary to do so.

> Also, every browser has been using the single-window approach with
> motion events since forever (otherwise hover wouldn't work) and I
> haven't seen people complain about it.

You mean hovering over a menu item in a javascript-created menu on
a web page? That case is ok, because the JS application is running
locally on the pc.

> But feel free to prove use wrong.

All i can prove is that selecting for continuous mouse events uses
network bandwidth unneccessarily, however small.

For 99.9% of adsl users it may not matter.

However, i think of the users that have multiple sessions happening
over a dial-up modem plus a remote X app.

Selecting for continuous mouse events and doing all the windowing
stuff on the client side is neccessary if you want to use Input
devices provided by the kernel directly instead of via the X server.
That can be a significant advantage, because the X server is then
out of the way of input-device innovations.

I should have qualified previous posts that when using the sub-window
widget approach, flickering can also be reduced by using the X-shm
extension to avoid socket traffic on a local system.