surface buffer cardinality and outputs

[John Kåre Alsaker]

I don't see why we'd want to remove properties from the output object.
They are still useful for the very common case where a surface is on a
single output only. For example, if a surface is on multiple outputs
with mismatching subpixel layouts, it could turn off subpixel
rendering.

Having clients render in different color spaces for different outputs
is another reason to use a buffer per output. I have some elaborate
plot to avoid this requirement in my Wayland CMS protocol suggestion,
but that won't well for other properties.

Clients will want to align drawing to pixels, so a simple multiple
wl_buffer per wl_surface scheme won't work well for subsurfaces. That
would require an wl_surface per output.

We can question how important the case of dragging a window across and
letting it display properly until it's completely on the other screen
is.
- for subpixel rendering, clients can disable it. Subpixel rendering
is becoming less important with high DPI display and turning it off
isn't very intrusive.
- for the DPI differences, clients can render in the highest DPI and
let the compositor scale down on the other outputs it's on. This means
it will always look good on one output atleast. You'd see a jump in
quality as the client renders for the new output.

I'd say these workarounds works for most applications and is
preferable over the complexity and performance loss of using multiple
buffers. We may want a solution for applications with a single window
spanning multiple outputs, but I'm not sure those exists.

Anyway I do prefer the one workspace per output approach where you
can't see these race issues at all :)

On Thu, Mar 14, 2013 at 4:36 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>> Your proposal is middle ground: a set of buffers, and some
>> heuristics applied on their properties to combine those in the
>> compositor space. For simplicity, I dare to think one buffer for
>> one output is quite clear cut and easier to deal with.
>
> As a word of clarification,  I said " keyed to output properties" in
> an attempt to be general.  The heuristic used to select the exact
> buffer could be any number of things.  One possibility is to have it
> keyed to the exact output (what you are suggesting).  For a multi-gpu
> setup, you might have it keyed to the GPU.
>
> The real point of my example was the following idea:  A buffer
> represents the back-end data to be drawn to the screen.  Why does that
> back-end data have to mean a single grid of pixels?  Why couldn't it
> be an SVG image? Why can't it be a grid of pixels that is
> smaller/larger than it will actually display on-screen and should be
> scaled? Why can't it be multiple grids of pixels, one for each display
> that may or may not be the same size depending on screen densities?
>
> This different way of thinking about buffers is just one possible way
> to handle it.  Perhaps it should be handled at the surface level
> instead (although I don't like that as much).
>
> Working with multiple screens, subpixel formats, densities, etc is a
> huge issue.  We are no longer in the era where every screen is a 96DPI
> CRT and we need to find a way to handle that.  When it comes to
> densities: what if have a window on my 2880x1800 laptop display and
> drag it onto my 1280x1024 external monitor?  I really don't want that
> window to more-than-fill the external monitor and have huge text.
> Instead, the toolkit should rescale for the lower density and it needs
> to be able to do that while the window is still half on one monitor
> and half on the other.  Like the subpixel issue, I don't think this
> can be properly fixed without multiple images per buffer or multiple
> images per surface.  The question is how best to handle it at the
> protocol level.
>
> Part of the problem is that we're breaking new ground here.  As far as
> I know, no one currently handles this well (particularly screen
> densities).  Android handles things fairly well but they don't really
> support multiple monitors and I don't think they care about subpixel
> stuff on the second (cloned) monitor.  Apple handles this by cheating
> and making their retina displays basically identical except that they
> have exactly 4 times as many pixels.  Microsoft "handles" this by
> simply scaling all of the non-compliant apps by 1.8 on denser screens
> (yes, really, 1.8) and doesn't handle multiple-monitors well either.
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel