John Kåre Alsaker wrote:
On Tue, May 14, 2013 at 2:51 PM, Alexander Larsson <[email protected]
<mailto:[email protected]>> wrote:
On tis, 2013-05-14 at 13:44 +0200, John Kåre Alsaker wrote:
> I'd only accept a proposal which makes the clients tell the
compositor
> how much they increased the size of their window. If the compositor
> wants to resize anything it should resize the entire window and not
> individual surfaces/buffers. This also avoids having to position
> subsurfaces and have configure requests at fractional surface pixels.
I don't quite understand what you mean by this (like, how is "window"
different from "surface"). Can you give an example of how the API would
look for what you mean.
A window can have multiple surfaces (see the subsurface extension).
I don't see any problem at all. Any scale being applied to a surface to
be applied to it's subsurfaces as well. And subsurface position is in
pre-scaled coordinates so if you want a subsurface to align with some
pixels in the main surface's buffer, the position is still in integers.
Yes the subsurface's destination rectangle is going to be scaled to
non-integers. I think you have to realize you are not going to avoid
this problem by your attempt to link the clipping rectangle to the
scaling factor. Clients should deal with it by rendering images such
that the result is not objectionable, mostly by forcing the edges to be
replicated on buffers, and filling the invisible areas with non-clashing
pixel values.
I now do very much believe that the scaler extension should be altered
so that surface size and events are reported in pre-scaled (ie in buffer
pixels) coordinates. This makes the transformation be done at the same
step as this scaler, reducing the number of different coordinate spaces.
You cannot do it the other way because that *does* require surface sizes
to be non-integers.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
