[PATCH 2/2] protocol: Support scaled outputs and surfaces

Jason Ekstrand jason at jlekstrand.net
Thu May 16 14:43:52 PDT 2013


On May 16, 2013 1:11 PM, "Bill Spitzak" <spitzak at gmail.com> wrote:
>
> Jason Ekstrand wrote:
>
>> I still think we can solve this problem better if the clients, instead
of providing some sort of pre-scaled buffer that matches the output's
arbitrary scale factor, simply told the compositor which output they
rendered for.
>
>
> That is equivalent to providing a scale factor, except that the scale
factor has to match one of the outputs.

What I didn't mention here but did before is that this could be combined
with an integer scale factor in case you want to render at a multiple.  If
you throw that in, I think it covers all of the interesting cases.

>
> A client will not be able to make a low-dpi surface if there are only
high-dpi outputs, which seems pretty limiting.

If you want a low DPI surface you can just not specify the scale/output at
all. Then it will just assume something like 100dpi and scale.

>
> You could say that the scaler api would be used in that case, but this
brings up the big question of why this api and the scaler are different
when they serve the same purpose?

The point of this soi is to allow surfaces to render the same size on
different density outputs. The point of the scaler api is to allow a
surface to render at a different resolution than its specified size. The
two are orthogonal.

--Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130516/ee772644/attachment.html>


More information about the wayland-devel mailing list