Compositing managers spec

[Lubos Lunak]

 Hello,

 I'd like to standardize few more things about compositing managers. Looking
at the spec, there are already few things in an added section, but it almost
looks like quickly hacked in and expecting that a WM and a CM have to be the
same (e.g. there should not be any _WM_ in the selection name). So I thought
the first thing to do should be to ask a couple of questions:

- Are people fine with having it in one spec or should it be a separate one
building on top of EWMH? Some things are shared (e.g. _NET_WM_WINDOW_TYPE),
but some are clearly separate.

- Are people fine with using this list or should a separate one be created?

- (Bonus question) Does somebody know how to achieve the creation of things
mentioned above if needed :) ?

- Are there actually any people caring about CMs here?

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Nathaniel Smith]

On Sat, Jan 26, 2008 at 09:00:29PM +0100, Lubos Lunak wrote:

>
>  Hello,
>
>  I'd like to standardize few more things about compositing managers. Looking
> at the spec, there are already few things in an added section, but it almost
> looks like quickly hacked in and expecting that a WM and a CM have to be the
> same (e.g. there should not be any _WM_ in the selection name). So I thought
> the first thing to do should be to ask a couple of questions:
>
> - Are people fine with having it in one spec or should it be a separate one
> building on top of EWMH? Some things are shared (e.g. _NET_WM_WINDOW_TYPE),
> but some are clearly separate.
>
> - Are people fine with using this list or should a separate one be created?

Well, it makes sense to me:
  http://www.mail-archive.com/wm-spec-list@.../msg00557.html

The consensus of implementations seems to be moving towards WMs and
CMs being the same thing anyway, and there's already at least one de
facto, undocumented standard for CM behavior that "illegally" uses the
EWMH-reserved _NET_WM namespace (_NET_WM_WINDOW_OPACITY).  Better to
bless such things and bring them into the spec than let them
proliferate.

(I think, though, that the _NET_WM_CM_Sn selection has "WM" in it
because "_NET_WM" is the EWMH namespace, not because it's the "window
manager" namespace, if that distinction makes sense.  So it doesn't
bother me.)

-- Nathaniel

--
Electrons find their paths in subtle ways.
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Dennis Kasprzyk]

Nathaniel Smith wrote:

> On Sat, Jan 26, 2008 at 09:00:29PM +0100, Lubos Lunak wrote:
>>
>>  Hello,
>>
>>  I'd like to standardize few more things about compositing managers.
>>  Looking
>> at the spec, there are already few things in an added section, but it
>> almost looks like quickly hacked in and expecting that a WM and a CM have
>> to be the same (e.g. there should not be any _WM_ in the selection name).
>> So I thought the first thing to do should be to ask a couple of
>> questions:
>>
>> - Are people fine with having it in one spec or should it be a separate
>> one building on top of EWMH? Some things are shared (e.g.
>> _NET_WM_WINDOW_TYPE), but some are clearly separate.
>>
>> - Are people fine with using this list or should a separate one be
>> created?
>
> Well, it makes sense to me:
>   http://www.mail-archive.com/wm-spec-list@.../msg00557.html
>
> The consensus of implementations seems to be moving towards WMs and
> CMs being the same thing anyway, and there's already at least one de
> facto, undocumented standard for CM behavior that "illegally" uses the
> EWMH-reserved _NET_WM namespace (_NET_WM_WINDOW_OPACITY).  Better to
> bless such things and bring them into the spec than let them
> proliferate.

I think that things like this should be standardized as _NET_CM_WINDOW_*.
>
> (I think, though, that the _NET_WM_CM_Sn selection has "WM" in it
> because "_NET_WM" is the EWMH namespace, not because it's the "window
> manager" namespace, if that distinction makes sense.  So it doesn't
> bother me.)

If we decide to use the _NET_CM namespace for composite managers, then I
think that it could be also renamed to _NET_CM_Sn, but this also depends on
how many applications already use _NET_WM_CM_Sn to detect that a composite
manager is running.

Dennis


_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Dennis Kasprzyk]

Lubos Lunak wrote:

>
>  Hello,
>
>  I'd like to standardize few more things about compositing managers.
>  Looking
> at the spec, there are already few things in an added section, but it
> almost looks like quickly hacked in and expecting that a WM and a CM have
> to be the same (e.g. there should not be any _WM_ in the selection name).
> So I thought the first thing to do should be to ask a couple of questions:
>
> - Are people fine with having it in one spec or should it be a separate
> one building on top of EWMH? Some things are shared (e.g.
> _NET_WM_WINDOW_TYPE), but some are clearly separate.
>

I think that we should try to build it a separate spec on top of EWMH,
because there still may be composite managers without a window manager
functionality. Having it in one spec can lead to a point where things get
mixed up, and it's not clear who (WM or CM), should be in charge for a
specific window property.

Composite managers will always want to have a finer differentiation of the
window type, than the current _NET_WM_WINDOW_TYPE types provide. I think
that something like _NET_CM_WINDOW_SUBTYPE could fullfill such task. If we
find a type description that makes also sense from the window manager point
of view, then we can define it as _NET_WM_WINDOW_TYPE window type.

Dennis


_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Nathaniel Smith]

On Sun, Jan 27, 2008 at 03:22:06PM +0100, Dennis Kasprzyk wrote:
> Composite managers will always want to have a finer differentiation of the
> window type, than the current _NET_WM_WINDOW_TYPE types provide. I think
> that something like _NET_CM_WINDOW_SUBTYPE could fullfill such task. If we
> find a type description that makes also sense from the window manager point
> of view, then we can define it as _NET_WM_WINDOW_TYPE window type.

_NET_WM_WINDOW_TYPE already has support for describing a single window
with multiple different degrees of specificity -- you can list as many
window type atoms as you like, in order from most specific to least
specific.  Trying to work out ahead of time which sorts of windows a
window manager "should" need to differentiate as opposed to those that
a compositing manager "should" need to differentiate seems like a
fool's errand to me.  The only time it would be obvious is when the
hint was a purely visually-oriented direction to the CM, and then we'd
just be reinventing Motif-style hints, which sucked the first time.

(As a more minor engineering issue, you also introduce the possibility
that the two properties could contradict each other, and have
different environments resolve the conflict in different ways,
creating incompatibility.  _NET_WM_WINDOW_TYPE does not have this
problem.)

-- Nathaniel

--
The Universe may  /  Be as large as they say
But it wouldn't be missed  /  If it didn't exist.
  -- Piet Hein
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Sanel Zukan]

Hi,

> I think that things like this should be standardized as _NET_CM_WINDOW_*.

+1

> If we decide to use the _NET_CM namespace for composite managers, then I

+1 too.

Following this, _NET_WM_WINDOW_OPACITY could be renamed to
_NET_CM_WINDOW_OPACITY?

> I think that we should try to build it a separate spec on top of EWMH,
> because there still may be composite managers without a window manager
> functionality. Having it in one spec can lead to a point where things get
> mixed up, and it's not clear who (WM or CM), should be in charge for a
> specific window property.

Quite true. At first I was more for integrating cm specs with EWMH
because, for me, it looked naturally. On other hand, people can ship
separate composite manager apps without bothering to add window
management support. Heck, current development EDE version have compositing
as separate application (althought that will be changed).

> Composite managers will always want to have a finer differentiation of
> the window type, than the current _NET_WM_WINDOW_TYPE types provide.
> I think that something like _NET_CM_WINDOW_SUBTYPE could fullfill such
> task. If we find a type description that makes also sense from the window
> manager point of view, then we can define it as _NET_WM_WINDOW_TYPE window
> type.

Why need to duplicate efforts? Composite managers can regulary fetch
window type (which is related to wm) and do whatever they like with
them (in a sense of presentation; handling still should be done by wm).
If they want to paint the same type differently (e.g. menu), interested menu
can use "styled" properties, like _NET_CM_STYLE_SHADOWED or similar. At
the end, integrated cm/wm solution can combine them both removing potential
ambiguities or duplications.

Best,
--
Sanel Zukan
http://equinox-project.org
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Lubos Lunak]

On Monday 28 of January 2008, Sanel Zukan wrote:
> Hi,
>
> > I think that things like this should be standardized as _NET_CM_WINDOW_*.
>
> +1
>
> > If we decide to use the _NET_CM namespace for composite managers, then I
>
> +1 too.

 The _NET_WM_CM_Sn selection is already widely used and it's been in the spec
for a while, so it's a question if we want to break backwards compatibility
there just because the name doesn't quite look right.

> Following this, _NET_WM_WINDOW_OPACITY could be renamed to
> _NET_CM_WINDOW_OPACITY?

 I'm personally hesistant to give official blessings to this ugly beast. I
don't think clients should be allowed to control transparency of the whole
window (especially when that includes decorations) - that's none of their
business.

> > I think that we should try to build it a separate spec on top of EWMH,
> > because there still may be composite managers without a window manager
> > functionality. Having it in one spec can lead to a point where things get
> > mixed up, and it's not clear who (WM or CM), should be in charge for a
> > specific window property.

 This problem actually already exists in the spec and even separating the CM
part won't solve it completely. Current spec mixes things WM is reponsible
for, that the clients are responsible for and that other tools like pagers
are responsible for (and the bad thing is that this is often even not
explicitly specified). A separate CM spec probably makes sense, but it'll
have to share things with the WM spec anyway.

> Quite true. At first I was more for integrating cm specs with EWMH
> because, for me, it looked naturally. On other hand, people can ship
> separate composite manager apps without bothering to add window
> management support. Heck, current development EDE version have compositing
> as separate application (althought that will be changed).

 Agreed here. Just because people these days seem to think integrated CMs are
the way to go that doesn't mean that can't change their minds again, so we
should not prevent that.

> > Composite managers will always want to have a finer differentiation of
> > the window type, than the current _NET_WM_WINDOW_TYPE types provide.
> > I think that something like _NET_CM_WINDOW_SUBTYPE could fullfill such
> > task. If we find a type description that makes also sense from the window
> > manager point of view, then we can define it as _NET_WM_WINDOW_TYPE
> > window type.
>
> Why need to duplicate efforts? Composite managers can regulary fetch
> window type (which is related to wm) and do whatever they like with
> them (in a sense of presentation; handling still should be done by wm).

 Right. Where should _NET_WM_WINDOW_TYPE be insufficient for CMs?

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Sanel Zukan]

>  The _NET_WM_CM_Sn selection is already widely used and it's been in the spec
> for a while, so it's a question if we want to break backwards compatibility
> there just because the name doesn't quite look right.

Hm... currently this property (and/or _NET_WM_WINDOW_OPACITY) are
possible candidates for this spec (am I correct?). Anyone have
more proposals?

Just thinking; if there are only two properties for cm-s, I'm not sure
is it worth to write specific spec anyway. On other hand, it will be
much easier to add additional ones later :)

>  I'm personally hesistant to give official blessings to this ugly beast. I
> don't think clients should be allowed to control transparency of the whole
> window (especially when that includes decorations) - that's none of their
> business.

:) Then, how will external cm and wm/desktop/etc. communicate in uniform
way?

Regarding to this, for some time I was planning to propose something like
_NET_WM_WINDOW_REGION_OPACITY where some window parts would be
opaque/translucent; e.g. menu could be translucent but other parts
opaque.

But, if there are good reasons to remove it, I will not be the one who
will start to yell :)

>  This problem actually already exists in the spec and even separating the CM
> part won't solve it completely. Current spec mixes things WM is reponsible
> for, that the clients are responsible for and that other tools like pagers
> are responsible for (and the bad thing is that this is often even not
> explicitly specified). A separate CM spec probably makes sense, but it'll
> have to share things with the WM spec anyway.

Yes.

--
Sanel Zukan
http://equinox-project.org
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Dana Jansens-2]

On Jan 30, 2008 9:02 AM, Sanel Zukan <sanelz@...> wrote:
> >  The _NET_WM_CM_Sn selection is already widely used and it's been in the spec
> > for a while, so it's a question if we want to break backwards compatibility
> > there just because the name doesn't quite look right.
>
> Hm... currently this property (and/or _NET_WM_WINDOW_OPACITY) are
> possible candidates for this spec (am I correct?). Anyone have
> more proposals?

This would go in the WM spec, but be related to CM managers..

Currently a WM can ping a window to see if it is alive or not.  When
it is no longer responding, it may want to provide different functions
on that window, such as killing it.  I noticed the cairo-compmgr has a
plugin to grey out windows which are not responding - similar to
compiz.  However, without some coordination, the timing for the WM and
CM changing their ideas about a window is going to be very awkward.

Therefore, I propose the _NET_WM_STATE_NOT_RESPONDING.  This would be
a state that the WM should probably ignore requests to set it entirely
(can anyone think of a time someone else might know an app is not
responding and want to report it to the WM?).  This state would allow
a CM to show visual feedback that the WM has considered a window to
have gone dead, and will be treating it as such.

This is my only thought irt CM support at the moment.  I think its
important to have a spec for CMs however, I don't really have a strong
opinion on having it combined with/separate from the WM spec.  I think
most of the hints may be, like this, informational hints provided by
the WM to the CM, and probably belong inside the WM spec at least, or
perhaps both.

Cheers,
Dana
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Denis Washington]

On Wed, 2008-01-30 at 15:02 +0100, Sanel Zukan wrote:
> >  The _NET_WM_CM_Sn selection is already widely used and it's been in the spec
> > for a while, so it's a question if we want to break backwards compatibility
> > there just because the name doesn't quite look right.
>
> Hm... currently this property (and/or _NET_WM_WINDOW_OPACITY) are
> possible candidates for this spec (am I correct?). Anyone have
> more proposals?

One thing I proposed before that I think would fit nicely into a CM spec
would be a flag to tell the CM "don't mess with this window (e.g. don't
do animations like fade-in on opening the window), just display it
as-is". Something like override-redirect for CMs. This would allow
developers to have full control of a window's appearance, for instance
if they want to use auxiliary windows for animations.

Regards,
Denis

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Nathaniel Smith]

On Wed, Jan 30, 2008 at 03:02:18PM +0100, Sanel Zukan wrote:
> Regarding to this, for some time I was planning to propose something like
> _NET_WM_WINDOW_REGION_OPACITY where some window parts would be
> opaque/translucent; e.g. menu could be translucent but other parts
> opaque.

Create a window with a RGBA visual and use the alpha channel; if a CM
is running then this will just work, no need for any extra properties.
(This kind of possibility is why gtk+ includes an api just to let apps
find out if a CM is running, for instance.)

-- Nathaniel

--
Electrons find their paths in subtle ways.
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Dennis Kasprzyk]

Sanel Zukan wrote:

>>  The _NET_WM_CM_Sn selection is already widely used and it's been in the
>>  spec
>> for a while, so it's a question if we want to break backwards
>> compatibility there just because the name doesn't quite look right.
>
> Hm... currently this property (and/or _NET_WM_WINDOW_OPACITY) are
> possible candidates for this spec (am I correct?). Anyone have
> more proposals?
>

- More color controls (BRIGHTNESS/SATURATION/GAMMA...)
- Taskbar preview handling
- _NET_CM_SUPPORTED to inform apps about composite manager features
- Give applications control to some features of the composite manager
- Maybe a desktop background spec to define pixmaps (and their properties)
for multiple viewports/desktops
...

Dennis

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Carsten Haitzler (The Rasterman)]

On Wed, 30 Jan 2008 20:54:52 +0100 Dennis Kasprzyk
<onestone@...> babbled:

> Sanel Zukan wrote:
>
> >>  The _NET_WM_CM_Sn selection is already widely used and it's been in the
> >>  spec
> >> for a while, so it's a question if we want to break backwards
> >> compatibility there just because the name doesn't quite look right.
> >
> > Hm... currently this property (and/or _NET_WM_WINDOW_OPACITY) are
> > possible candidates for this spec (am I correct?). Anyone have
> > more proposals?
> >
>
> - More color controls (BRIGHTNESS/SATURATION/GAMMA...)
> - Taskbar preview handling
> - _NET_CM_SUPPORTED to inform apps about composite manager features
> - Give applications control to some features of the composite manager
> - Maybe a desktop background spec to define pixmaps (and their properties)
> for multiple viewports/desktops
> ...

composite manager flags properties array. flags such as:

* do not delay my output to try coalesce rendering updates (if the composite
manager is smart and tries to delay updates by like 0.1 or 0.2 seconds from
xdamage events to try and wait for more updates to occur so it can update to
screen in 1 go and not in lots of small updates, making window re-draw look
"smoother" as it happens at once and not bit by bit, but some apps - like video
players and games, will definitely not want this as they probably do whole
updates in 1 go anyway).
* please provide a solid background even if my window is ARGB because i am
allowing the wm border/decoration to define the backing of my window and the
contents should be composited over whatever backing the WM provides (the
problem with window decorations is that they are separate from window
background. it is impossible to reliably have a titlebar seamlessly continue
into the app window with textures, patterns, shading etc. without fastidiously
fixing up themes/widgets/whatever of every toolkit. if toolkits were to render
to ARGB dest windows and simply NOT render a background color/pattern for the
window, but leave it transparent with all buttons, other widgets, labels
rendered onto a dest-alpha transparent ARGB window, then the window content is
a composited overlay on top of a window frame "Decoration" that also defines
the decorations UNDER the window contents, allowing for smooth transitions from
titlebars and borders into the window contents).


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

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

On Wednesday 30 January 2008 23:41, Carsten Haitzler wrote:
[...]

> * please provide a solid background even if my window is ARGB because i am
> allowing the wm border/decoration to define the backing of my window and the
> contents should be composited over whatever backing the WM provides (the
> problem with window decorations is that they are separate from window
> background. it is impossible to reliably have a titlebar seamlessly continue
> into the app window with textures, patterns, shading etc. without fastidiously
> fixing up themes/widgets/whatever of every toolkit. if toolkits were to render
> to ARGB dest windows and simply NOT render a background color/pattern for the
> window, but leave it transparent with all buttons, other widgets, labels
> rendered onto a dest-alpha transparent ARGB window, then the window content is
> a composited overlay on top of a window frame "Decoration" that also defines
> the decorations UNDER the window contents, allowing for smooth transitions from
> titlebars and borders into the window contents).

I think this is a good idea, and it's a problem I've been thinking about
for a while myself.

One comment though is that I think the application still needs to be
able to specify an area (a rectangular one will probably suffice), where
the window background really should be transparent. An application like
konsole or gnome-terminal may want to be able to combine having a
toolbar that blends seamlessly with the window decoration, while at
the same time having a translucent terminal area.

Window managers will also have to advertise support for this feature so
applications can know if they can use it. I imagine that support for this
feature may also depend on the window manager theme being used.

Regards,
Fredrik

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Sanel Zukan]

Dana Jansens wrote:
> Currently a WM can ping a window to see if it is alive or not.  When
> it is no longer responding, it may want to provide different functions
> on that window, such as killing it.  I noticed the cairo-compmgr has a
> plugin to grey out windows which are not responding - similar to
> compiz.  However, without some coordination, the timing for the WM and
> CM changing their ideas about a window is going to be very awkward.
>
> Therefore, I propose the _NET_WM_STATE_NOT_RESPONDING.  This would be
> a state that the WM should probably ignore requests to set it entirely

This sounds cool! :) Thinking about this... when wm set it to
_NET_WM_STATE_NOT_RESPONDING it will be much easier to write/add some
external monitoring apps to watch unresponsive windows/apps (at least a
little bit ;)).

Denis Washington wrote:
> One thing I proposed before that I think would fit nicely into a CM spec
> would be a flag to tell the CM "don't mess with this window (e.g. don't
> do animations like fade-in on opening the window), just display it
> as-is".

+1

Nathaniel Smith wrote:
> Create a window with a RGBA visual and use the alpha channel; if a CM
> is running then this will just work, no need for any extra properties.
> (This kind of possibility is why gtk+ includes an api just to let apps
> find out if a CM is running, for instance.)

Aaa, cool; thanks for the tip!!! I never tried via this way...

Dennis Kasprzyk wrote:
> - Taskbar preview handling

For minized windows preview? How about keeping preview images on server
side so they can be picked up by single property, like
_NET_CM_MINIMIZED_LIST (or with better name)?

> - _NET_CM_SUPPORTED to inform apps about composite manager features

+1

> - Give applications control to some features of the composite manager

Isn't this cm specific? IMHO, this will limit cm's to implement exactly
some features, althought author's intent is not to do so.

> - Maybe a desktop background spec to define pixmaps (and their properties)
> for multiple viewports/desktops

For me, this looks like a candidate for EWMH :)

Carsten Haitzler wrote:
> * do not delay my output to try coalesce rendering updates (if the composite
> manager is smart and tries to delay updates by like 0.1 or 0.2 seconds from
> xdamage events to try and wait for more updates to occur so it can update to
> screen in 1 go and not in lots of small updates, making window re-draw look

Hm... isn't the point of xdamage (and the family) to do a lot of small
but precise updates?

> "smoother" as it happens at once and not bit by bit, but some apps - like video
> players and games, will definitely not want this as they probably do whole
> updates in 1 go anyway).

So, you are proposing removing delay in updates or waiting for a larger number
of events and update everything in once or maybe signaling cm to do
update for the whole screen, e.g. when video player goes fullscreen?
(I didn't understaind this well)

> * please provide a solid background even if my window is ARGB because i am
> allowing the wm border/decoration to define the backing of my window and the
> contents should be composited over whatever backing the WM provides (the
> problem with window decorations is that they are separate from window
> background. it is impossible to reliably have a titlebar seamlessly continue
> into the app window with textures, patterns, shading etc. without fastidiously
> fixing up themes/widgets/whatever of every toolkit. if toolkits were to render
> to ARGB dest windows and simply NOT render a background color/pattern for the
> window, but leave it transparent with all buttons, other widgets, labels
> rendered onto a dest-alpha transparent ARGB window, then the window content is
> a composited overlay on top of a window frame "Decoration" that also defines
> the decorations UNDER the window contents, allowing for smooth transitions from
> titlebars and borders into the window contents).

But, this sound for me more like a toolkit issue. I'm not sure how gtk/qt/others
will adopt this, but I'm sure this will not go easily in FLTK (except if I create
my own branch).

Fredrik Höglund wrote:
> One comment though is that I think the application still needs to be
> able to specify an area (a rectangular one will probably suffice), where
> the window background really should be transparent. An application like
> ...
> Window managers will also have to advertise support for this feature so
> applications can know if they can use it. I imagine that support for this
> feature may also depend on the window manager theme being used.

Hm... why wm's have to do this? Like Nathaniel noted, window can use RGBA
visual. On other hand, supporting transparency in themes, at least for
me, looks like wm specific feature.


--
Sanel Zukan
http://equinox-project.org
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Carsten Haitzler (The Rasterman)]

On Fri, 1 Feb 2008 16:37:33 +0100 Sanel Zukan <sanelz@...> babbled:

> Carsten Haitzler wrote:
> > * do not delay my output to try coalesce rendering updates (if the composite
> > manager is smart and tries to delay updates by like 0.1 or 0.2 seconds from
> > xdamage events to try and wait for more updates to occur so it can update to
> > screen in 1 go and not in lots of small updates, making window re-draw look
>
> Hm... isn't the point of xdamage (and the family) to do a lot of small
> but precise updates?

the point of xdamage is simply to deliver events stating which rectangular
region(s) of a drawable have been drawn to - when they are drawn to. it is up
to the CM as to what to do with them. generally speaking the CM will then
pretty much instantly queue up redraws for he corresponding regions on the real
screen.

a lot of apps will update their window by drawing all the parts that change. if
they do not double-buffer theme selves they will draw directly to the
front-buffer. this means that to draw a button that goes from light red to deep
pink and looks pressed-in, it may very easily draw a new base color, then draw
the lines surrounding the box to make it look indented, then redraw the label
in the middle. in theory this can easily be half a dozen or more damage events
for the same region. if the CM simply draws on every damage event - u'll get
lots of extra compositing going on. if its smart it will queue updates and wait
until all damage events have been read then update. if it gets really smart it
may even delay a bit then as more damage events may be on their way but not in
the buffers yet. it may also wait until vsync

sometimes such extra delays that are artificially added beyond draining all
damage events could lead to bad sync. situations - eg - video players. they
will update the whole video at once anyway. so for apps hat are "smart" about
drawing and double-buffer themselves, and care about getting updates up ASAP -
set a property. for "legacy" or "stupid' apps - the CM can play some heuristics
games by adding small delays to gathering all damage events to make sure it
queues up as many as it can for 1 on-screen update to improve smoothness of
screen updates as much as possible.

> > "smoother" as it happens at once and not bit by bit, but some apps - like
> > video players and games, will definitely not want this as they probably do
> > whole updates in 1 go anyway).
>
> So, you are proposing removing delay in updates or waiting for a larger number
> of events and update everything in once or maybe signaling cm to do
> update for the whole screen, e.g. when video player goes fullscreen?
> (I didn't understaind this well)

no - see above. it's a hint that says "if you have some smart stuff that may
delay an update more than it could be delayed, to try and reduce updates,
please don't do this as it's pointless for me because i already am smart about
drawing". :)

> > * please provide a solid background even if my window is ARGB because i am
> > allowing the wm border/decoration to define the backing of my window and the
> > contents should be composited over whatever backing the WM provides (the
> > problem with window decorations is that they are separate from window
> > background. it is impossible to reliably have a titlebar seamlessly continue
> > into the app window with textures, patterns, shading etc. without
> > fastidiously fixing up themes/widgets/whatever of every toolkit. if
> > toolkits were to render to ARGB dest windows and simply NOT render a
> > background color/pattern for the window, but leave it transparent with all
> > buttons, other widgets, labels rendered onto a dest-alpha transparent ARGB
> > window, then the window content is a composited overlay on top of a window
> > frame "Decoration" that also defines the decorations UNDER the window
> > contents, allowing for smooth transitions from titlebars and borders into
> > the window contents).
>
> But, this sound for me more like a toolkit issue. I'm not sure how
> gtk/qt/others will adopt this, but I'm sure this will not go easily in FLTK
> (except if I create my own branch).

it is a toolkit issue. *IF* the toolkit renders ARGB and is expecting the CM/WM
to provide a backing image that is part of the frame/border, then the CM/WM
knows to provide this as opposed to thinking the ARGB window is intended to be
transparent over other windows.

this allows for the background to be seamless with the window frame and match
properly. nothing does this (yet), but it'd be very useful if available and
later used by toolkits. adopting is easy if ARGB visual window, draw background
with alpha of 0x0, instead of 0xff+color. the rest is the same :)

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

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Lubos Lunak]

On Saturday 02 of February 2008, Carsten Haitzler wrote:

> a lot of apps will update their window by drawing all the parts that
> change. if they do not double-buffer theme selves they will draw directly
> to the front-buffer. this means that to draw a button that goes from light
> red to deep pink and looks pressed-in, it may very easily draw a new base
> color, then draw the lines surrounding the box to make it look indented,
> then redraw the label in the middle. in theory this can easily be half a
> dozen or more damage events for the same region. if the CM simply draws on
> every damage event - u'll get lots of extra compositing going on. if its
> smart it will queue updates and wait until all damage events have been read
> then update. if it gets really smart it may even delay a bit then as more
> damage events may be on their way but not in the buffers yet. it may also
> wait until vsync
>
> sometimes such extra delays that are artificially added beyond draining all
> damage events could lead to bad sync. situations - eg - video players. they
> will update the whole video at once anyway. so for apps hat are "smart"
> about drawing and double-buffer themselves, and care about getting updates
> up ASAP - set a property. for "legacy" or "stupid' apps - the CM can play
> some heuristics games by adding small delays to gathering all damage events
> to make sure it queues up as many as it can for 1 on-screen update to
> improve smoothness of screen updates as much as possible.

 There is _NET_WM_SYNC_REQUEST, which is a way to detect when the client has
finished doing a repaint. It is unfortunately bound to ConfigureNotify
events, but I think that's not a real problem in practice.

--
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
Lihovarska 1060/12   tel: [phone]
190 00 Prague 9      fax: [phone]
Czech Republic       http//www.suse.cz
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Carsten Haitzler (The Rasterman)]

On Tue, 5 Feb 2008 14:23:47 +0100 Lubos Lunak <l.lunak@...> babbled:

> On Saturday 02 of February 2008, Carsten Haitzler wrote:
> > a lot of apps will update their window by drawing all the parts that
> > change. if they do not double-buffer theme selves they will draw directly
> > to the front-buffer. this means that to draw a button that goes from light
> > red to deep pink and looks pressed-in, it may very easily draw a new base
> > color, then draw the lines surrounding the box to make it look indented,
> > then redraw the label in the middle. in theory this can easily be half a
> > dozen or more damage events for the same region. if the CM simply draws on
> > every damage event - u'll get lots of extra compositing going on. if its
> > smart it will queue updates and wait until all damage events have been read
> > then update. if it gets really smart it may even delay a bit then as more
> > damage events may be on their way but not in the buffers yet. it may also
> > wait until vsync
> >
> > sometimes such extra delays that are artificially added beyond draining all
> > damage events could lead to bad sync. situations - eg - video players. they
> > will update the whole video at once anyway. so for apps hat are "smart"
> > about drawing and double-buffer themselves, and care about getting updates
> > up ASAP - set a property. for "legacy" or "stupid' apps - the CM can play
> > some heuristics games by adding small delays to gathering all damage events
> > to make sure it queues up as many as it can for 1 on-screen update to
> > improve smoothness of screen updates as much as possible.
>
>  There is _NET_WM_SYNC_REQUEST, which is a way to detect when the client has
> finished doing a repaint. It is unfortunately bound to ConfigureNotify
> events, but I think that's not a real problem in practice.

we could recycle that - didn't think of that actually.

> --
> Lubos Lunak
> KDE developer
> --------------------------------------------------------------
> SUSE LINUX, s.r.o.   e-mail: l.lunak@... , l.lunak@...
> Lihovarska 1060/12   tel: [phone]
> 190 00 Prague 9      fax: [phone]
> Czech Republic       http//www.suse.cz
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list@...
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>

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

_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list