Finishing Composite to handle transformed windows

[Andy Ritger]

Don't underestimate the value of a hardware cursor.  A software
cursor, rendered by the X server whenever X thinks the cursor needs
to be re-rendered, does not interact well with direct rendering
clients, such as OpenGL or XvMC, since X does not normally know when
the direct rendering client has rendered over the software cursor.

Granted, in a composited environment, perhaps your direct rendering
clients are only rendering to redirected windows, and thus cannot
render over the sw cursor, but if the user disables the compositing
(say, because they want to trade eye-candy for raw direct rendering
performance), it would be a shame to doom them to a sw cursor.

I agree that some cursor effects where the cursor interacts with
the windows in the scene (eg: if the windows reflect back onto
the cursor) might only be possible if you render the cursor as part
of the scene.  But if its only a matter of getting the appropriate
pixels into the hw cursor image, then we should find a way to do
that so that the hw cursor can be utilized.  Heck, we could do an
FBO-style GLX_render_to_cursor extension :)

- Andy


On Fri, 6 Jan 2006, Deron Johnson wrote:

> Carsten Haitzler (The Rasterman) wrote On 01/06/06 12:53,:
> 
> 
> >> 1. input event transforms/translations (ie all input events go via
> the WM and
> >> then get somehow translated to account for 2d scaling - much like
> your usage
> >> keith).
> 
> 
> Keith and I have been discussing for some time having an extension which
> will hand off raw device events to an external client which will make
> the event/window containment decision, namely: what is the window which
> encloses the current mouse position.
> 
> I have implemented a prototype type of this. It currently supports only
> one level of redirection--so it uses an external client to decide which
> top-level window is the enclosing window and uses the normal X server
> code to find the deepest enclosing subwindow in the window tree. My
> prototype is described my LG event document, particularly sections
> 4, 5, 6, 9, 10, 11, and 12. (See the "Looking Glass Event Pipeline"
> link on http://xorg.freedesktop.org/wiki/LookingGlassIntegration).
> 
> Keith is currently working on a different prototype of this idea for his
> magnifier in which he is trying to find a cleaner way to send the raw
> device events to the external client and receive them back again. He is
> experimenting with a way that uses less ifdefs.
> 
> 
> >> 2. mouse cursors - the big pain. what will we do with mouse cursors for
> >> sub-windows if the windows now are basically not visible and only the
> >> compositing system's output window is visible and it may have
> twisted, bent,
> >> curved, scaled and translated windows anywhere. do we really want to walk
> >> window trees and watch all levels of the trees for sub windows
> looking for ones
> >> with special cursors and watching when they change? or should there
> be a way to
> >> feed a new mouse co-ord to a window and we then may get a mouse
> cursor change
> >> event if the cursor moves toa  new-coord within that window in
> pre-transform
> >> co-ord space?
> 
> 
> LG deals with this problem by always rendering it's own cursor. When the
> pointer is over a 3D object, if that object has a special 3D cursor
> registered for it, that cursor is rendered. If there is not special
> registered cursor then a default 3D cursor is rendered. If the pointer
> is over the 3D "avatar" of an X11 window then the cursor is rendered
> with a flat 2D quad which contains the X11 window's cursor image (we
> use the XFIXES extension to get this image).
> 
> Since LG needs to figure out which 3D object silhouette encloses the
> pointer anyway, we use that opportunity update the cursor visual
> representation to be appropriate for that object.
> 
> The advantage of handling the cursor in this way is that it allows us to
> draw all kinds of interesting cursors: they wobble, cast shadows, etc.
> This gives our environment a more life-like feel which many users enjoy.
> The key point here is that in the LG environment the cursors can have
> arbitrarily complicated visual attributes and hardware-based cursor
> rendering features cannot render them.
> 
> The downside of rendering the cursor in this way is that it is not
> a real-time cursor like a kernel-rendered cursor is. I am hoping that
> in the future Linux will have real-time features added to it and that
> will provide a tool for solving the problem.
> 
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>