- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 23 Nov 2010 18:30:20 -0800
> Message: 1
> Date: Mon, 22 Nov 2010 15:27:40 -0500
> From: Boris Zbarsky<bzbarsky at MIT.EDU>
> To: whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Processing the zoom level - MS extensions to
> window.screen
> Message-ID:<4CEAD23C.1000405 at mit.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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.
>
Animated digital imagery usually requires retained data, otherwise it'd
be analog.
For the topic at hand, canvas, near-all canvas apps retain state data in
the scripting environment. They have to, to perform a repaint.
>> Most uses of canvas involve keeping state-info around in order to redraw
>> the screen.
>>
> Quite a number do, yes. A number don't.
>
I'll challenge you on this one: I don't think there are a number of them
that don't.
We may just have a different idea about what the state-info is.
The scripting environment likely keeps around a function, that, when
called, will re-draw to the canvas.
The output may change, based on environment, but the scripting
environment is a retained environment.
The browser event loop is intrinsic to the way canvas operates.
>> 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....
>
Sorry I missed that one... Resizing a canvas within an element is
another use case,
or otherwise animating the canvas in any way not covered by CSS.
>>> 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.
>
It is a legitimate statement, and relevant to the discussion, though I
could have phrased it more gently.
The 2D API, as it relates to implementation details -- is a very
different item than the actual use of that API.
You're looking at fill methods, path checking, clipping, masking, etc. I
understand that. I've produced several implementations.
I've also produced a substantial body of work using the API; and so,
speaking from that place, I can say with some credibility that
programming the API is radically different than using the API.
I appreciate your candor, and can now, better understand your
perspective/misunderstandings on some of the issues I've brought up.
>
>> 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).
>
I did consider that use case; it's a corner-case, and I don't think we
have the proper support in DOM Windows to even begin to support
multiple-monitors. I do have some ideas on it, but I think that there
are more important issues in the present.
In terms of "reinventing the wheel", we are talking about a minimum of
lines of code. We're talking about ~6 lines of code here.
Believe me, I've reinvented wheels. It takes a lot more work.
> At the same time, there are existing web technologies whose entire
> reason for existence is resolution-independent graphics and text
> rendering (SVG, specifically).
>
SVG is a document format. It is not reliably implemented. It's far more
expensive to implement SVG on a new environment than Canvas.
Disagreeing with my use case is your choice, but it's about as useful as
telling the Skywriter team that they're wasting their lives.
> 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.
>
The API footprint I'm requesting is about the size of a flea. I get that
there may be privacy concerns in exposing screen metrics, and I'm fine
talking about that; I don't "need" to know the actual dimensions of the
screen. I do need some scaling data.
There's zero impact on existing sites. I'm not requesting any behavior
be changed, I'm asking for additional variables to be exposed.
You're trying to understand why I'm not using SVG. That doesn't help me
at all.
Further, you're still thinking of SVG as though it's software... It's
not. It's a document format.
I can't do much for you here other than explain to you what I'm hearing.
a) Why are you using our Canvas implementation instead of our SVG
implementation.
b) Why are you using ctx.fillText('Test') instead of
element.appendChild(document.createElement('text')).textContent = 'Test'.
For answers
a: I'm using it because I work across a variety of browser platforms.
Canvas is far better supported.
b: Because it's shorter, and wrapping from Canvas to SVG automatically
is inefficient.
And if I could put this out there again: my output is not exclusive. I'm
perfectly happy to support an SVG profile.
I haven't had the resources to produce a pure SVG profile, so we are
currently using HTML+CSS profile, with
conditional SVG support for items like SVG FE.
>> 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.
>
Resize events on zoom are current de facto behavior. I want it
documented. It's already there. I want the ratio between a CSS pixel and
a device pixel, so that my output is crisp and clear on the device. I
want it exposed in a way that doesn't alter anything already out there..
Which is why I have reservations about using the two existing variables
exposed in mobile devices.
>> One related to making text legible.
>>
> _This_ I agree is a worthwhile goal.
>
My eyesight continues to decline. I agree.
More-over, we'll see more and more cases of people using a browser from
several feet away.
In those cases, they need zoom so they can read.
>>> 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).
>
1. Name one. 2. Flash is a fine technology. 3. Using canvas means having
an entry point;
typically in window.onload. They're authored to re-render based on user
input.
>> 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....
>
Robert's suggestion would radically alter the existing functionality of
canvas and require a whole lot of work from other vendors. I think his
suggestion has some great use cases, but I'm firmly against it replacing
existing html canvas behavior.
I've proposed a solution that doesn't alter a thing.
And, these aren't great lengths. It's about 6 lines of javascript.
Canvas programmers have, necessarily, an understanding of how Canvas
works. It's an API where nothing is done for you.
>> Exposing that property changes nothing in existing zooming behavior.
>>
> Yes, that's a _bug_, not a feature, imo.
>
The way canvas scales with css pixels is not a bug. It's fully
intentional and in line with img and video tags.
>>>> 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.
>
You've got great expectations for the great lengths I'm willing to go.
Wish you had some of that faith in other developers. Canvas coders work
very hard at their craft.
> 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'm all for easy, but I'm not for restricting users, nor breaking
existing apps.
And as I've said, the current functionality is darn-easy. The only hard
part is getting the variables that you haven't yet exposed to the
environment.
>> 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.
>
Technically: it would take very little time to expose the data I'm
looking for to the scripting environment.
Using that data requires very few lines of code.
Documenting the method, and why people would use it, would happen
quickly, and I'd be happy to contribute to that effort.
Does that cover the technical end?
-Charles
Received on Tuesday, 23 November 2010 18:30:20 UTC