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

[Boris Zbarsky]

On 11/22/10 12:22 AM, Charles Pritchard wrote:
> OpenGL has an immediate-mode which does not require a bitmap backend.

Sure.  But if it's going to be resolution independent, then there needs 
to be a retained mode somewhere in the stack, even if it's not exposed 
to the original caller (e.g. you GL could be outputting to postscript). 
  That is, to have resolution independence, you _have_ to retain more 
information about the logical structure of your image than just pixel 
color values.

> The bitmap backend comes in with ImageData and CanvasPixelArray, and CSS
> width/height.

None of those actually require a bitmap backend....  (though there 
aren't really very good ways to make putImageData 
resolution-independent, I agree).

> Most uses of canvas involve keeping state-info around in order to redraw
> the screen.

Quite a number do, yes.  A number don't.

> 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.

Sure.  This is the first mention of you resizing your canvas to use the 
full width and height of the window, which sounds like the sort of 
constraint I asked about in my previous mail....

>> 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.

Well, most of my work related to "the API" is on the C++ end of "the 
API", making it work (or more precisely, making it work faster).  The 
time I spend on that is far greater than the time I spend using it, for 
sure.  I _have_ used it, of course; just not for "my work".

But I'll note that an ad-hominem attack in response to a technical 
question doesn't really get us further towards mutual understanding.

>> 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.

Good for you.

> 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?

Your specific proposal is for achieving resolution-independent rendering 
by using canvas + fillText + DPI ratio + firing resize revents on zoom 
(and a few you left out, like firing resize events on non-zoom DPI 
change when I switch to an external monitor and so forth, but which are 
clearly needed to make this whole approach actually work well).

At the same time, there are existing web technologies whose entire 
reason for existence is resolution-independent graphics and text 
rendering (SVG, specifically).

What I'm trying to understand is what specific issues with SVG prevent 
its use in your situation, and whether those are "the implementations 
just suck" issues or whether they're intrinsic to SVG.  Understanding 
that would make it easier for me to balance the additional API footprint 
you seem to think is absolutely and unequivocally necessary, as well as 
the work needed in UAs to add the APIs you want and the resulting impact 
on sites that aren't yours and users of those sites against the pain 
that you would presumably need to endure to use SVG.

Again, if there was a description of this somewhere that I missed, I'd 
love a link.

> I haven't requested a whole bunch of new features. Just one.

At the very least, you want resize revents on zoom and an exposure of 
the "current DPI", whatever that means.

> One related to making text legible.

_This_ I agree is a worthwhile goal.

>> 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

Sure, but there are plenty of canvas uses that aren't animating all the 
time (I've seen image editing apps, sites that use canvas as their 
_input_, not their output, etc).

> I haven't requested that we change any behavior. What is going to get
> "broken" ?

You have requested a solution that works to make browser zoom work for 
your particular case.  I'm saying that it might be worth considering 
solutions that work for other cases too, assuming they actually work, 
rather than tailoring the solution to your situation and allowing other 
authors who have the same problem but aren't aware of it, due not having 
a detailed understanding of the SVG, HTML, DOM, and CSS specs, to 
inflict unreadable text on their users by accident.

Specifically, your proposed solution involves some fairly complicated 
manual rescaling of all your canvas drawing on zoom to achieve the 
desired effect.  This is something most authors just aren't going to do. 
  I'm glad you're willing to go to those lengths to make your content 
accessible, and if that's the only thing we can do, then so be it.  But 
if we can solve the problem in a way that needs less work on the author 
side, that seems strictly preferable.  Robert's made a suggestion along 
these lines in this thread already....

> Exposing that property changes nothing in existing zooming behavior.

Yes, that's a _bug_, not a feature, imo.

>>> 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.

That's what we disagree on.  You see a problem in your app and want to 
solve it in your app only and are willing to go to great lengths to do that.

I see a problem that is endemic to canvas-using apps, and would like to 
make it as easy as possible (ideally, requiring nothing at all) for app 
authors to solve this problem.

> 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.

Right.  I believe I understand the use case.

> I am frustrated, and it certainly shows through in my responses.

Fair enough; let's try to focus on the technical end of this, then.

-Boris