surface buffer cardinality and outputs

[Pekka Paalanen]

On Mon, 25 Mar 2013 16:38:01 +0100
Renaud Hébert <renaud.hebert8 at gmail.com> wrote:

> On Fri, 22 Mar 2013 23:51:41 +0200, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> >This introduces temporary glitches, which we work hard to eliminate.
> >Unless you mean window outline moves instead of window content?
> >
> >(Window outline resizes are actually something I'd personally like
> >to see, would make Weston on Raspberry Pi a lot more smooth
> >experience.)
> 
> Be careful ;-) You start this way and then you will wonder if you cannot
> have the compositor ask asynchronously the clients to provide the content
> of the window, this way you have smooth resizing of the window outline and
> have still the content of the window displayed..

Hah, you know, the current protocol actually supports that
out-of-the-box, without any client side changes. All you need is a
little compositor hackery to additionally draw the outline or
equivalent. :-)

> More seriously, I don't see why optimising for "weird display" (transformations
> that are not representable by a matrix) should take precedence over
> sub-pixel aware rendering..

It is part of the greater design decision to not expose a global
coordinate system to clients. I also believe, that the compositor
should be able to move windows at will, while maintaining visual
quality.

I might pose the same question of why is sub-pixel rendering so
useful? But maybe that's because every time I actually see it, it
is done wrong. When it's done right, it I don't notice. :-)


Thanks,
pq