[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] How to set a canvas backing store to display units?



On Sat, Jun 16, 2012 at 1:58 PM, Gregg Tavares (çç) <gman@google.com> wrote:
>
>
> On Sat, Jun 16, 2012 at 1:36 PM, Florian BÃsch <pyalot@gmail.com> wrote:
>>
>> On Sat, Jun 16, 2012 at 10:30 PM, Gregg Tavares (çç) <gman@google.com>
>> wrote:
>>>
>>> It will break because you have to test. That's what I mean by automatic.
>>> Lots of programmers will add "allowHighRes" either by using a library, by
>>> copying boilerplate code or just by not understanding theÂimplications. They
>>> won't personally have an HD-DPI machine so their app will work. They'll have
>>> no idea of all the rules they broke. Hence, it will break automatically when
>>> put on an HD-DPI machine.
>>
>>
>> The exact same will be true for those same programmers who copy&paste or
>> use an engine that does the window.devicePixelRatio for you, their apps will
>> break if they are not aware that their canvas size != backing store size.
>
>
> I don't know why I can't convey this in way that sticks.
>
> What I'm suggesting is
>
> Â Â Â Âcanvas.size == backing store size
>
> Period. Always. No Options. ÂThat's what it is today and I want to see that
> added to the spec that HD-DPI machine don't change that.
>
> Â Â Â Âcanvas.size = desiredSize * window.devicePixelRatio
>
> is still
>
> Â Â Â Âcanvas.size == backing store size
>
> You ask for a certain size, you get it.
>
> That's separate from the size it's displayed. That's true today, it was true
> 2 years ago. It will be true tomorrow
>
> Â Â Â <canvas width="4" height="3" style="width: 400px; height: 300px"
> id="foo"/>
>
> Â Â Â gl = document.getElementById("foo").getContext("webgl");
>
> requested size = 4x3
> canvas size = 4x3
> backing store size = 4x3
> display size = 400x300

I agree that this is the best approach. It is unnecessary to add
another WebGL context creation attribute indicating high-DPI
awareness. Because the canvas's intrinsic dimensions are its width and
height interpreted as CSS pixels, WebGL applications not specifically
written for high-DPI displays will just work. They'll render at a
lower resolution and be scaled up. The canvas's relative size on the
web page, and how it participates in layout, will be unchanged on
high-DPI displays.

A WebGL application desiring higher resolution on a high-DPI display
can scale canvas.width and canvas.height by window.devicePixelRatio
(or whatever the standardized solution ends up being), leaving the CSS
width and height as they were originally. As a benefit, applications
can see roughly what they would look like on a high-DPI display just
by scaling canvas.width and canvas.height. This wouldn't be possible
if a context creation attribute were added, since that attribute would
only take effect on high-DPI hardware.

I've added normative text to section 2.2 indicating no automatic
scaling of the WebGL drawing buffer is allowed:

https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/specs/latest/index.html#2.2

which will show up shortly as

http://www.khronos.org/registry/webgl/specs/latest/#2.2

Please review and comment.

-Ken


>>
>> The effort to make your app compatible is identical in either case, and
>> the breakage is identical in either case as well. Both are an opt-in
>> mechanism and both dismarry canvas dimensions from backingstore dimensions
>> withoutÂnecessarilyÂthe average developer being aware of it. Even the
>> educational effort is the same, I really don't think it matters. I also
>> think I don't care:
>>
>> Option #1: Slap Apple on the wrist never to do the automatic thing, and
>> add an addendum to the specification stating that backingstore == canvas
>> dimension and that devicePixelRatio has to be queryable for everybody who
>> implements webgl.
>
>
> This.
>
>>
>> Option #2: add this "allow this or that" attribute
>>
>> Option #3: allow both (that could get kinda confusing)
>
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------