[PATCH 00/15] weston scaling support

Pekka Paalanen ppaalanen at gmail.com
Mon Jun 3 23:57:31 PDT 2013


On Mon, 3 Jun 2013 16:21:48 +0200
John Kåre Alsaker <john.kare.alsaker at gmail.com> wrote:

> On Mon, Jun 3, 2013 at 2:22 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > On Tue, 28 May 2013 19:27:35 +0200
> > John Kåre Alsaker <john.kare.alsaker at gmail.com> wrote:
> >
> > > + Conceptually simple to implement. Compositors doesn't have to deal with
> > > scaling for subsurfaces and they are probably already able to resize
> > whole
> > > windows.
> >
> > Why would sub-surfaces have any effect here?
> >
> I have absolutely no idea how subsurfaces trees with different scaling
> factors on surfaces would work in Alexander's proposal. I simply don't
> allow specifying it on anything other than top level surfaces, which it
> uses for the whole surface tree.

The answer is: sub-surfaces do not interact with other surface's buffer
scaling AT ALL.

Everything except buffer sizes in the protocol are in pels. Sub-surface
positions are in pels. Sub-surface sizes are in pels. Whether a parent
surface or a sub-surface has some buffer scaling applied or not, does
not have ANY effect to anything else.

That's the trivial and obvious design. A buffer scale affects only that
one particular surface in how its buffer content is interpreted.
Nothing more.

It's the same with buffer_transform. If the parent had a transformed
buffer attached, it does not transform anything else.

This is actually quite vital. If there were any interactions, the use
of sub-surfaces would suddenly become extremely painful.


- pq


More information about the wayland-devel mailing list