> 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
