[PATCH 00/15] weston scaling support

[Bill Spitzak]

Pekka Paalanen wrote:

> Bill Spitzak <spitzak at gmail.com> wrote:

>> I always figured that the transformation of a subsurface is multiplied 
>> by the transformation of the parent surface. For the scaler proposal 
>> this means the output rectangle is in parent-surface buffer pixels.
> 
> You are confusing things.
> 
> Sub-surface is relative to its parent surface, and therefore in the
> compositor implementation level, the surface transform of the parent is
> multiplied into the transform of the child surface. That you got
> correct.
> 
> However, we are not talking about surface transforms here.
> 
> We are talking about buffer transformations, which are private to each
> surface. A buffer transform does not alter or affect the surface
> transform.
> 
> The only thing a buffer transform does, is affect how the buffer
> contents and size are interpreted.
> 
> The wl_scaler proposal is similar to buffer transforms: it is private
> to a surface, and only affects the mapping between the surface and the
> buffer. It does not affect the surface transform, and hence it has
> absolutely no effect on any other surface, be it a parent surface or a
> child sub-surface, or my uncle.
> 
> Bill and John, please adjust all your suggestions to this principle,
> and we have one huge barrel of man-eating worms less.

No. Our proposal is that "pels" ARE EQUAL TO BUFFER PIXELS. This makes 
the term "pel" useless, but it may be easier to think of it that way:

In BOTH proposals the rectangle a subsurface occupies is specified in 
"pels". This is not different.

In our proposal pels are buffer pixels, therefore it is specified in 
buffer pixels of the parent.

In your proposal it is in the transform the compositor does to the 
outermost surface plus the xy offsets of each intermediate parent surface.

I think clients are going to want to align subsurfaces with features in 
their buffer, which is the primary reason I propose this, and I think 
why John is proposing it as well.

>>> 3. This makes the subsurface case of handing off to a library more 
>>> complicated.  In Alexander's implementation, the library would simply 
>>> render at native resolution or not.  With this, the client has to tell 
>>> the library what surface scale to use and the library has to *EXACTLY* 
>>> match.  Maybe this isn't a huge issue, but there's no opportunity for a 
>>> client to embed an older library.
>> This is true already for any third-party software called by a client 
>> that can draw directly into the client's output buffer.
> 
> Yes, which is why we have sub-surfaces, so that the third-party thing
> can have its own buffer.

I can certainly imagine drawing libraries that can either draw into the 
client's buffer or use a subsurface depending on how they are currently 
set, or maybe use both. To draw into it's own buffer the client will 
have to tell the library the scale.

In addition video players that just resize to whatever rectangle they 
are told will not care about the scale and will work exactly the same in 
both proposals (except they will get events in video pixels in our 
proposal, which I think would be a little easier for them).