Xgl/Xegl future?

[Dave Airlie]

> Actually, I think the problem there is that we rely on the process
> scheduler to sort out who gets the lock after contention. AFAICT it
> would be possible to share the lock in a perfect round robin manner
> between processes. The drawback of that might be excessive context
> restoring overhead though.
> 
> Also, Xgl per se will have zero impact on this specific case with direct
> rendering. And even indirect rendering won't guarantee that the GLX
> requests are processed evenly between clients, will it?

If everything goes via Render via Xegl then you don't have GLX
requests in the common case, the X server just draws things in
whatever order it sees fit, I don't really like the idea of all my
individual applications being direct or indirect rendering clients,
the 2D apps should take the standard route and the X server should
decide how to draw them,

Xegl won't fix two glxgears or two gtk apps or whatever, but I think
that is actually a lot harder problem to fix than getting Xegl running
and keeping direct rendering to being the exception rather than the
rule..

Dave.