surface buffer cardinality and outputs

[Jason Ekstrand]

> 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.