Finishing Composite to handle transformed windows

[Carsten Haitzler (The Rasterman)]

On Fri, 06 Jan 2006 15:35:09 -0800 Deron Johnson <Deron.Johnson at Sun.COM>
babbled:

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

does this client havs to walk the window tree (and get  window shape rect lists
etc.) to make this descision? (thats a nasty amount of overhead AND round
trips. sure it can incrimentally build a complete client-side representation of
the entire window tree and select event masks so it can track async - but that
is a fair amount of repetition client-side and still will require a few
round-trips to do evbery time something changes (shape changes, windows get
added etc.)

> 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 in the attached document, particularly sections
> 4, 5, 6, 9, 10, 11, and 12.

hmm - must read.

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

okj - the first cases are internal and no problem (in e17 we do a similar
thinjg except for client windows we leave it entirely to x atm as we arent
compositing or redirecting yet). so every mouse move on an x11 window you need
to query the topmost (inner most) child window at that point and ask for its
shape mask (and parent shape masks for clipping) and then once u knwo what
window the mouse is really in - u need to ask for its current cursor - then
display that. i think this needs to be done better.

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

sure - i agree. i do the same thing in evas for some cases (not the wm) -
client rendered cursors so we get alpha blended color cursors irrepsective of
what xserver you have and your hardware's abilities - also no flicker on screen
update as with software cursors in x. also works in all bit depths (even 8bpp
paletted) - so we have the same reasons you do to want to DIY cursors. but we
need an easier way when the renderngwindow is not root with include inferiros
(where x wont be modifying the cursor as it isnt over the real window. it's
indirected and is REALLy over the composite managers window). OR... now i think
of it - once the mouse coord-transform stuff is working... do we not want to
have 2 protocol requests to pass CONTROL of the x cursor TO a particular
toplevel window (and its children) so once the mouse enters an x11 client
window space within the compositor it passes control to x - when it exits this
region (goes ontop an overlayed 3d object, or some other composite system item)
then pass control back to the composite window, etc. etc. (the default
controller window is root)?. if wer add a xserver GLOBAL "hide" or "show"
cursor - the cursors can still change "virtually" behind the scenes, the client
can listen to cursor change events, on a change - fetch the new cursor shape
and then display the cursor within the compositor as it sees fit? (the default
display of the cursor is "show" - maybe again - set this per window and it
affects all children of that window, so the default window to set show/hide is
root and by defaults it is set to "show") ?

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

well its as real time as events and rendering allow - the shorter the rendering
pipeline/the less latency, the better :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)