[whatwg] Processing the zoom level - MS extensions to window.screen

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.

Received on Sunday, 21 November 2010 21:22:28 UTC