surface buffer cardinality and outputs

[Pekka Paalanen]

On Wed, 20 Mar 2013 13:09:48 -0400
Jerome Glisse <j.glisse at gmail.com> wrote:

> On Wed, Mar 20, 2013 at 4:32 AM, RenoX <renozyx at gmail.com> wrote:
> >
> >
> > On Tue, Mar 19, 2013 at 11:34 AM, Jason Ekstrand <jason at jlekstrand.net>
> > wrote:
> >> I'm not sure exactly what I think of all this surface transform
> >> passing.  I'll get back to that once I get a chance to think about it.
> >>  Part of the problem is that you don't want to try and make your
> >> animations subpixel-perfect because that would require a lot of
> >> round-trips to make it right.
> >
> > And you(Jerome Glisse) replied:
> >> It doesn't add more roundtrip, client will get next matrix like a
> >> frame event, client then draw in screen space and then draw with new
> >> transformation matrix. If client can't keep up it wouldn't either keep
> >> up in the non screen space rendering case.
> >
> > I disagree: currently Weston move windows server side only, that is to say
> > without roundtrip,
> > if you want to be 'subpixel perfect' then moving a window imply to re-render
> > it from the client, which will add a lot of roundtrip in this case.
> >
> > So the current design is 'pixel perfect', but not 'subpixel perfect', and
> > cannot be without big changes..
> >
> > regards,
> > renoX
> 
> What i propose is an extension ie application can still render non
> subpixel and can still render non subpixel when moving/resizing. Note
> also that moving a window around is not so much different then
> resizing a window in which case wayland will round trip with the
> client. So really if a client want subpixel rendering at all time it
> just add roundtrip in the window is moving case.

The server can also move surfaces on its own, without the client
initiating the move. This is move by hotkey. Therefore you would
incur at least one extra roundtrip during the beginning of such move.

> Again i stress it's not a lot of roundtrip it's the same amount of
> roundtrip as with resize window.

Resize is actually a huge deal. It is very very heavy. At least I
do not want to incur the same penalty to moving, now that using a
compositor has finally made moving a very cheap operation.

> Change i propose are not big, it's a fairly small contained change, i
> will try to hack something over the weekend.

This discussion is has lead me to conclude, that it is
near-impossible to reliably support and present sub-pixel rendering
in general without telling clients where their surfaces are on an
output.

Not telling clients where their surfaces are has been a major
design decision in Wayland this far, so it seems Wayland is somewhat
incompatible with the concept of sub-pixel rendering. Feasible
cases are limited to just some special cases, where the output
device has a translation-invariant pixel pattern, and the
compositor does not apply any other transformations than
translation.

With that in mind, I think it's ok to enable sub-pixel rendering
where it is feasible, but I would not expose surface positions or
transformations to clients for it.

Therefore I'd simply propose for compositors to advertise outputs
with sub-pixel order as unknown or none, unless the output is known
to be translation invariant and surfaces are only translated.


Thanks,
pq