[whatwg] Processing the zoom level - MS extensions to window.screen
bzbarsky at MIT.EDU
Mon Nov 22 12:27:40 PST 2010
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
> The bitmap backend comes in with ImageData and CanvasPixelArray, and CSS
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.
More information about the whatwg