surface buffer cardinality and outputs

[Jason Ekstrand]

Ok, so allow me to try and sum up how I understand the discussion going so far.

It seems as if multiple buffers per surface is probably overkill.
However, we do want some sort of scaling support.  Scaling could be
used for things like videos or for a surface that needs to be
displayed at different DPI's.  One question to answer here is whether
this should be a surface-level thing or a buffer-level thing.  I think
you can make an argument in either direction, but it would be good to
try and figure out what the pros/cons of each direction would be.

A second problem here is that, right now, everything is specified in
pixels.  We need a way to rectify this if we want to be able to run at
different DPI's consistently.  Perhaps, if we have a "main" surface at
all times, we simply communicate in terms of pixels on that display
and expect the compositor to compensate.  If we do allow for a unified
desktop, this means we need to find a way to prevent things from
getting weird when a window is spanning displays.

We also have the question as to whether or not to allow a unified
desktop.  Allowing for a unified desktop makes for lots of issues
particularly if you ever want to use two GPU's at the same time.
However, people have come to expect it, so maybe we don't want to just
write it off.  Again, more discussion needed.

On Mon, Mar 18, 2013 at 12:50 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
> On Thu, Mar 14, 2013 at 3:38 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> On Wed, 13 Mar 2013 19:52:55 +0100
>> Sylvain BERTRAND <sylware at legeek.net> wrote:
>>
>>> The other option would be to ignore those output properties, and
>>> the compositor would manage something with an output agnostic
>>> buffer.  In that case, we would remove the subpixel property from
>>> the output to stay consistent (mode is used for shell surface
>>> fullscreen).
>>
>> Btw. the sub-pixel property has also other issues: if the compositor
>> does any surface transformations instead of pure translation, any
>> sub-pixel rendering will become incorrect. That's a gap we haven't
>> really tried to solve yet, either.
>>
>>
>> Thanks,
>> pq
>
> Sorry for jumping kind of late in the discussion. I think client
> should provide a dpi information with their surface telling the
> compositor for which dpi the surface was rendered for an allow
> compositor to upscale surface for higher dpi. That way application
> that care about dpi could do proper rendering while thing that can be
> upscale through overlay or other means are upscale (many thing on a
> desktop can't be rerendered in higher dpi video, picture, ...). This
> dpi property should be per sub-surface so an application can have
> sub-surface with different dpi, think something like a browser with
> text in high dpi and embedded video in original size.
>
> For sub-pixel rendering the solution i have been thinking for a while
> but still haven't had time to prototype on weston, is to have weston
> send the transformation matrix to the client have the client render in
> screen coordinate space and when commiting its surface the client
> would also tell which transformation matrix it did use. Again this
> should be per sub-surface so that one can render the text and ui in
> screen space and do proper anti-aliasing while just do nothing for
> picture or video and let the compositor do the transformation. This is
> i believe the cleanest solution for proper sub-pixel rendering inside
> wayland paradigm.

Yes, adding some support for that might be a good idea.  However, this
becomes a bit of an issue because the surface might not be rectangular
anymore or it might be rotated.  How do you recommend getting around
this?

--Jason Ekstrand