<p dir="ltr"><br>
On May 16, 2013 1:11 PM, "Bill Spitzak" <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<br>
><br>
> Jason Ekstrand wrote:<br>
><br>
>> 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.<br>

><br>
><br>
> That is equivalent to providing a scale factor, except that the scale factor has to match one of the outputs.</p>
<p dir="ltr">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.</p>

<p dir="ltr">><br>
> A client will not be able to make a low-dpi surface if there are only high-dpi outputs, which seems pretty limiting.</p>
<p dir="ltr">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.</p>
<p dir="ltr">><br>
> 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?</p>
<p dir="ltr">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.</p>

<p dir="ltr">--Jason Ekstrand<br>
</p>