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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
