[whatwg] Processing the zoom level - MS extensions to window.screen
Charles Pritchard
chuck at jumis.com
Sun Nov 21 21:22:28 PST 2010
On 11/21/10 6:30 PM, Boris Zbarsky wrote:
> On 11/21/10 8:31 PM, Charles Pritchard wrote:
>> Canvas is an immediate mode rendering framework. I realize that it uses
>> a bitmap backend,
>
> Isn't that more or less a requirement for "immediate mode"? After
> all, the whole issue is that when resolution changes you need to
> rerender from some sort of state you have around, which is precisely
> what immediate mode doesn't have.
OpenGL has an immediate-mode which does not require a bitmap backend.
The bitmap backend comes in with ImageData and CanvasPixelArray, and CSS
width/height.
I'm not proposing altering any of those specs or behaviors.
Most uses of canvas involve keeping state-info around in order to redraw
the screen.
It's a requirement for apps which use the full width and height of the
window,
as the canvas state resets when the element size is changed.
>> but the drawing itself works very much like vector imaging. The scene
>> graph is built in the scripting environment instead of an ML file.
>
> Right, so you're trying to build a retained-mode something using
> canvas as the rendering backend, no?
I'm getting the impression that you don't use the API in your work.
>
>> Canvas is a low level API, SVG is a serialized format of a scene graph.
>> They're not the same thing.
>
> Yes, but if you're trying to build SVG-like features on top of canvas
> one has to stop and ask whether just using SVG might be a better idea.
> The answer might still be "no", of course. But reinventing wheels
> usually needs a pretty strong motivation...
I've a deep and detailed understanding of the SVG, HTML, DOM and CSS specs.
In this thread, I've only brought up the fact that using <canvas> with
fillText requires fetching the current DPI ratio,
so that the text is clear and crisp. How is that reinventing the wheel?
>> While Apple has certainly worked in supersampling, it's completely
>> unnecessary.
>
> Well, it's unnecessary if we introduce a whole bunch of other features
> and extra work, right?
My comments about Apple unnecessary.. Apple's work on supersampling is
related to some of their use cases in their platform ecosystem.
I haven't requested a whole bunch of new features. Just one. One related
to making text legible.
>
>> I don't see why expecting a page to re-render is unreasonable.
>
> Because most authors don't think about things like that and won't do
> it? So you'll get "broken" behavior for users in most cases.
Most authors re-render their canvas: all authors which use animation
re-render their canvas,
I haven't requested that we change any behavior. What is going to get
"broken" ?
>> Stated succinctly: It is entirely reasonable to re-render canvas when an
>> "onresize" event is received,
>
> It's reasonable to do it. It doesn't necessarily seem reasonable to
> _force_ everyone to do that to get reasonable zooming behavior...
There seems to be some misunderstanding. Nobody has proposed a change to
the existing spec,
nor forcing anyone to do anything. I've pointed out a defect, a missing
property which should be exposed.
Exposing that property changes nothing in existing zooming behavior.
It permits management of resolution targeted bitmaps.
>> it's a standard practice. There's no reason for the UA to handle it any
>> differently than it does now (scaling the CSS pixels).
>
> Well, no reason other than making all pages accessible when zoomed and
> not just the rare few that go out of their way to jump through hoops
> to handle it, right?
>
I don't understand your statement. UA behavior should not be changed.
>> My evidence is essentially nullified when you make broad statements
>> about how there are better tools and better formats.
>
> I'm saying that if we're going to add features to the web platform we
> should be making sure they're the right features to add and that
> they're the best ways to solve the problems that need solving. Maybe
> adding information about the number of canvas backing store pixels per
> CSS pixel (which may NOT be the same as the number of screen pixels
> per CSS pixel, note!) is the right thing to do. Maybe we need to
> expose both numbers (e.g. exposing the canvas backing store resolution
> will do nothing for your server-generated PNGs). Clearly just
> exposing the screen resolution doesn't work for canvas in a world
> where we don't guarantee that canvas and screen resolutions match.
This is helpful. Now we're moving forward.
Your team has made certain that the information exposed in
"window.screen" matches CSS pixels. I understand that was a design
decision. Other vendors have opted to have screen match OS settings.
Currently, window innerWidth/outerWidth and window.screen are
implemented in too many different ways. Perhaps in the future there will
be some agreement about it.
I'd certainly like this particular defect re: canvas/pixel density to be
addressed right the first time, and I know that may mean waiting for
other issues to be resolved.
Microsoft's proposal hits the issue with six variables; it may be
enough, it may not.
http://msdn.microsoft.com/en-us/library/ms535868(VS.85).aspx
Robert has put forward that the two properties which emerged from mobile
phones, are implemented in 4.x, and that they may be sufficient.
He doubts the need for distinct x and y scaling, wondering if there are
devices which would use it.
I'd imagine somewhere deep in Microsoft's lab, there is a use case, but
I can't speak to consumer devices.
I've spoken to my current use case: When a user zooms in, I need to
readjust my bitmaps, primarily for written text, to serve users who may
need zoom for accessibility reasons.
If we're looking to the future, where the browser window may pass
through a heterogeneous system of displays, with differing resolutions,
pixel density, etc: that may be premature. I believe Robert has made
example of a "lense" display, as something a little too-far into the
future to try to target.
>> I don't doubt your good intentions here, but I am suggesting
>> that you've made an error in judgement.
>
> I think you mistake an attempt to understand the use cases based on
> the limited information I've seen presented in this thread for
> "judgment". If there' some massive amount of background information
> I'm missing here, which is what it feels like, I'd appreciate a
> pointer to it so I don't have to keep asking questions that make you
> all defensive.
I'll grant that I may have misinterpreted "devil's advocate"-style
responses, slippery-slope arguments and dissociated generalizations as
outright dismissal of use cases.
I am frustrated, and it certainly shows through in my responses.
More information about the whatwg
mailing list