[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 (社用) <email@example.com> wrote:
> On Sat, Jun 16, 2012 at 1:36 PM, Florian Bösch <firstname.lastname@example.org> wrote:
>> On Sat, Jun 16, 2012 at 10:30 PM, Gregg Tavares (社用) <email@example.com>
>>> 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"
> 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
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:
which will show up shortly as
Please review and comment.
>> 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.
>> Option #2: add this "allow this or that" attribute
>> Option #3: allow both (that could get kinda confusing)
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: