[PATCH 00/15] weston scaling support

[Pekka Paalanen]

On Mon, 03 Jun 2013 18:41:51 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> Jason Ekstrand wrote:
> 
> > I think I'm begining to see what you and John have been suggesting.  
> > While I think Alexander's proposal will work well enough for the 
> > standard case, I think this also has merit.  If I were to sum up, I'd 
> > say I was "cautiously supportive" of the above.  It does seem to solve 
> > some of the edge-cases.  That said, there are a few things I'd like to note.
> > 
> > 1. This requires a concept of a "window" which is one we currently don't 
> > have.  If we put it in wl_surface, we have to define how it works for 
> > subsurfaces.  We could say that the scale factor on subsurfaces gets 
> > ignored.  However, this means that we have defined an extension-specific 
> > exception.  What happens if we add another future extension that alters 
> > the window's size or orientation?  This will get messy.  We could put 
> > this in wl_shell_surface but then we are mixing the global (wl_output) 
> > with the desktop-specific (wl_shell_surface).
> 
> 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.

> > 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.

- pq