[PATCH 00/15] weston scaling support

[Bill Spitzak]

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.

> 2. This restricts subsurfaces to the same scaling factor as the original 
> surface.  Probably not a huge problem, but I'm not convinced it's a 
> smaller restriction than requiring subsurfaces on pel-boundaries.

I saw the scaling factor as a scale by 1/N (followed by a scale of N 
inside the compositor to the output pixels so it is 1:1). If this is on 
a subsurface it would be multiplied by the parent's scaling factor. This 
is probably pointless unless one of the two scales is 1.

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

It seemed the primary use of this is to display videos which will likely 
scale to whatever rectangle is asked for, regardless of output scale.

> 4. If a client presents a scale_factor to the compositor that is not an 
> integer multiple of one of the output_scale factors provided by the 
> compositor, it should not expect the compositor to do anything 
> intelligent.  There are similar problems with integer proposal, but this 
> one makes it more interesting.

I think the compositor can adjust it to a scale the hardware can handle. 
It looks like there is hardware that can only handle 1, or integers, or 
for a source buffer of width W it can only do integer/W.