Pekka Paalanen wrote:
Bill Spitzak <[email protected]> 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).
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
