[compiz] [RFC] Draft for a compositing manager specification

[Carsten Haitzler (The Rasterman)]

On Wed, 18 Aug 2010 21:16:04 +0200 Martin Gräßlin <kde at martin-graesslin.com>
said:

hmmm aaah ok! got it. read it. summary:
  "eeek".

my simple view of this spec is that "almost all of it is highly kde/desktop
specific and is not supportable in a general sense".

now i hope you don't all hate me for this... but i'm going to have to do some
ripping and tearing. :) flame me if you must, but this is in the name of "a
spec others can actually use and follow". if you wish to keep a lot of thses
kde specific - then fine, but they don't belong in a generic cross-cm/wm spec.

(btw - e17 has had a gl and software compositor for a little while now :) if
you include bling - a xrender one for many years, so i'm in the same/similar
boat with you guys, but with a difference - same compositor works in both
software fallback client-side mode, opengl, with and without
texture-from-pixmap AND works in opengl-es2.0 so in some ways. just for
background as your document seems to not know about this).

1. properties on root listing what is supported. fine - but big hole. no way to
know if properties are valid. if cm crashes/exits and leaves them there, they
will be stale and invalid. need a validity check mechanism much like netwm - or
stick them on the validity check window (see netwm for what i speak of but it's
pretty much another unmapped window that has a root property point to this
window, and this window has a property pointing to itself of the same atom/type
- if this check passes then the cm is there and alive and you can rely on the
properties it presents. if this window is destroyed or doesn't exist with a
stale root property, then the cm died/vanished and any info you find floating
about is not valid).

2. i pretty much have to say no to most of the spec - it's HIGHLY specific. the
only thing i'd keep from it mostly intact is the shadow spec. and even then i'd
morph this into a VISUAL_HINTS spec for a property set on a client window. this
would be a property of type ATOM that would be a list of 32bit types (atoms) to
indicate suggested visual properties for the cm to use. a list of these would
possibly be:
  NO_SHADOW <- please don't provide any depth/shadowing/glow/other
effect "outside the window frame" - use this window as-is and let the client
just provide a set of raw (A)RGB pixels in a block. i dont think having clients
control precise shadow size, color, blurriness etc. is viable. just a rough
hint here is all that is needed.
  NO_TRANSITION <- please do not provide any transitioning effects (slide,
fade, zoom, rotate, whatever) as the client probably does some effect of its
own and simply is asking for a set of (A)RGB pixels within which to do its
effect so doing your own effect will probably interfere badly with the client's
rendering.
  NO_MODIFY <- never modify the pixel output of this client. sometimes the
compositor may "gray out" inactive windows, or when in "alt-tab" or "select a
client window" mode it may dim/fade etc. windows other than the selected one.
the window with this hint would like not to have this dimming/fading applied.
it may be a panel, or OSD window or maybe just some innocuous visual decoration
on the screen. (we can add more...)

these are hints - cm may choose to ignore them. as you suggested a list of what
the cm will honor in a root property (with validity check) will be good.

3. the "slide" interaction imho is way too basic and limiting. let's stand back
and think. what you are asking is for the cm to become a generic effects engine
with a bunch of apis for very specific effects that you control in pretty raw
detail. the api is a property on a window as such. let's stand back here and
turn this into something doable. let's combine this with the above visual hints
atom. let's add another type atom to the visual hints list:
  TRANSITION <- highly suggested you transition this window in (or out on hide)
somehow (fade, zoom, flip, slide, whatever). in additionally an extra property
will provide a suggested "source" for the transition. discussed next.

4. a transition source property on the client window. TRANSITION_SOURCE is a
hint as to a "source window id + optional rectangle within that window that
this one may come from. property format is CARD32 with the elements being:
  [SOURCE WINDOW ID] <- required. may be root window id or any other window id
on screen. the geometry of this source window id is used as the source of the
transition hint UNLESS another 4 members of the property (5 CARD32's instead of
1 total) are provided.
  [[X],[Y],[WIDTH],[HEIGHT]] <- optional extra 4 CARD32 members that define a
rectangle (top-left at 0,0 in source window id, all CARD32's are signed 32bit
integers and width and height must be greater or equal to 0 (values less than
0 are reserved for future meanings).

5. EFFECT_NOW atom property. this is a property on a window that contains 0 or
more values of type ATOM (32bit) that request an effect to be applied on the
given client window. highlight, unimportant, urgent etc. etc - yes i know this
overlaps netwm. i'm not totally done thinking this over, but it's me trying to
do your "highlight windows" thing in a more generic way where a client requests
to be made visually prominent (or the opposite) at some point.

6. present windows... i think this just is better left to be entirely up to the
cm+wm to do at its leisure. the only thing i'd suggest here is perhaps the cm
being nice to external processes that want to do ushc "task manager" things -
same with window preview etc. etc. - cm sets a property on the frame window
with the current pixmap id of the composited/redirected pixmap. any client can
pick up this property and the pixmap id, and follow the property as it changes
to implement this themselves in whatever way they want using the pixmap id.
(the window its on itself provides for visual id and thus argb vs traditional
"solid" pixmaps).

now what i'd like to throw into this pool is the need of a few other things
that cm's have:

1. ability to "lock" compositing of a client window. client wants to be able to
request a lock while it busily re-configures things (resize window, redraw
contents, move, change shapes, etc. etc.). the cm may treat this how it wants -
stop compositing entirely, just stop compositing that client etc. etc. - and so
this requires a round-trip for the client to obtain the lock. cm may time locks
out if it wants and cm may drop its lock any time. if the cm times out a lock
it sends a message - specifics here are up for grabs, but this would be easily
done as a xclientmessage from client to root window with client window id to be
locked, client message back etc. etc.

2. client-side pixmaps. instead of forcing a window to be redirected by
xcomposite a client can already be composite-aware and just allocated and
render its own pixmap. it can set this as a property on its window. this is
SEPARATE to the window itself in that pixmap dimensions may not match window
dimensions. compositor will have to interpret this how it wants, but cm may
stretch pixmap to fill the window or do other things. but like normal
compositing cm can select for damages on this pixmap  (or should we have the
client send xclientmessages with damages so a client can hand-craft their own
damage notification - i actually prefer this considering the nature of the
idea).

3. compositor rotation. combined with #2 above this allows a client to request
an orientation (90 degree only) for its client-side pixmap. now the logic falls
into place. the window may be 480x800 BUT the pixmap be 800x480. this allows
the client to piggy-back on the compositors existing ability to composite,
rotate, stretch etc. - this is much more "embedded ui" related as here you want
to be able to allow per-window rotation and be able to accelerate the rotation
via 3d hardware and yet still have the client able to render in whatever
toolkit they like (eg software sdl or whatever) with no "cost" for the
client-side rotate. this also allows for the cm to do nice effects when going
between rotations. up for discussion. of course

4. the ability for cm to tell app "you are transitioning now" vs "you have now
finished transitioning and are now visible/invisible". this is especially
important when apps map and unmap windows or the wm/cm does (minimisation,
iconification, destkop switching etc.). the client NEEDS to do nothnig, but it
may may use of this hint. for example. when a window shows, the client may
choose to only do a basic ui initialisation and delay the rest until show
transition is done, or to drop framerate of video playback while transitioning,
to give up more gpu/cpu cycles to the compositor for a smoother transtion (eg
drop video playback from 30 to 15fps while transitioning out, then on becoming
invisible (since cm's now have to use the trick of never unmappping windows
apps have to have an extra message/state to be told when they are invisible to
the user, but still logically mapped - so the app may now drop updates to 2fps
as you still want some updates should the user try to use "exposé" or some such
browsing mechanism - and if they do all the hidden windows can be messaged and
told they are "partly visible" - another state that is the same state as during
a transition - but you never finally make it to being visible or invisible -
you just enter the partially visible state and thus should keep your window
updating, but can reduce quality a bit as you may be miniaturised).

5. cm provided window backgrounds. this one is controversial. this means that
toolkit and wm and cm have to all agree. but the idea is so that you can have
consistent frame + window backgrounds and transitions (ie smooth title+menubar
etc. etc.). the client now always provides an argb window that has no
background at all - always transparent where it used to have the base window
background. it lets the cm provide this and the cm composits the client app
window on top. problems here are: a) agreeing on background color and texture
etc. so it doesn't interfere with widgets (eg text labels etc.). up for
discussion but some kind of hint here with "light", "dark" or specific rgb
colors that the cm or the app use to say "keep clear of these please if you
want to be readable". not sure which way around it should go (ie should cm
define the "keep clear" colors and toolkit obey, or vice-versa). this opens up
a can of other worms - like cm and app agreeing on the cm providing things like
resize handles on the bottom-right that the app "keeps clear of" when filling
content or.. vice-versa? maybe some kind of hints the app can provide as to the
edges of its inner window and how much u'd like "frame" to stretch into the
app by (to make sure the menubar or statusbar etc. are always nicely filled in
like the title would be) etc. etc. up for debate. this also opens up the can of
worms that was canonicals "window indicators" - but providing a nice clean
protocol for these in much the same vein as a proper systray spec, would be
nice. though at this point i think we may have exited the cm spec and entered a
netwm spec.

let the flames... begin! :)

> On Tuesday 17 August 2010 05:00:19 Carsten Haitzler wrote:
> > wm+cm now provides both frame AND window background (or is able to via its
> > own frame styles) and application + toolkit now provides ARGB windows with
> > what used to be the "window background" be transparent "assuming" it is
> > composited onto the wm+cm provided background. so this means that wm+cm
> > and toolkit need to at least agree on some content matters - like
> > "contrasting colors" of wm base and toolkit widgets (labels etc.) and of
> > course agree on how toolkit/app is to know this feature exists and can be
> > provided, and then how the app will request it for the purpose of getting
> > a "seamless" frame+title+app+bg experience. (the rest is just mechanics on
> > agreeing on atom names to use, where to stick properties and what they
> > mean and which data to expose/fetch where in what way).
> > 
> > am i on the same page?
> No :-) The idea is to get a standard on how clients and wm can activate 
> effects, animations and so on.
> 
> I put a very first, very KDE-centric draft online: 
> http://blog.martin-graesslin.com/blog/wp-
> content/uploads/2010/08/compositing.pdf.tar.gz


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com