surface buffer cardinality and outputs

[Jerome Glisse]

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.

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.

> One thing I did want to point out though regards the details of
> subpixel rendering.  Right now the window has no knowledge at all of
> where it sits on the screen.  While I think this is a great idea it
> throws subpixel rendering off on some displays.  I was reading up on
> it last night and, on some panels, the client would need to know its
> position at least modulo 2 or 4 in order to render correctly.  For
> completely uniform subpixel layouts, it doesn't need to know this.
> However, some of the more clever pixel layouts are not uniform but
> rather have a pattern and where the buffer sits in that pattern is
> essential for proper subpixel rendering.
>
> See also: http://en.wikipedia.org/wiki/Subpixel_rendering#Checkered_RG-BW_layout

AFAICT different RGB layout is a dead end and no longer pursue by
anyone. Everyone seems to be moving toward higher dpi. None the less
providing the transform matrix will gave all information (from
position relative to RGB pixel) to the client for rendering.

I think the best solution inside the wayland paradigm is client
provide dpi in which its surface is rendered for and can render in
screen space using transformation matrix provided by the wayland
server. Both (dpi and transformed rendering) being client choice.

Cheers,
Jerome