- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 23 Nov 2010 21:53:15 -0500
On 11/23/10 9:30 PM, Charles Pritchard wrote:
>>> 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.
Are you including things like http://detexify.kirelabs.org/classify.html
under this classification?
> The browser event loop is intrinsic to the way canvas operates.
Um... no. Not really, no. You can render stuff (e.g. incoming video
data) into the canvas, then grab out the resulting PNG data and move on
without ever keeping any of the state around in your script or the
canvas or painting it back to the canvas
Unless we're _really_ using different definitions of "event loop" and
"intrinsic" (or "operates"?).
> The API footprint I'm requesting is about the size of a flea.
The thing is, if we add one separate flea for every use case we end up
with a whole bunch of fleas... Even if the special API addition is
small, asking whether it's needed or whether a more general approach is
preferred is worth it. The answer will depend on the details, of course
(like whether there _is_ a sane general approach).
> Further, you're still thinking of SVG as though it's software... It's
> not. It's a document format.
SVG is just a particular retained-mode representation. In particular,
you can script it. What, precisely, is the difference between
"software" and "document format", here?
Heck, HTML is a document format; gmail is software that happens to use
HTML as a presentation layer, right?
> 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.
... for this specific use case of needing resolution-independent
rendering. That last part is key.
> b) Why are you using ctx.fillText('Test') instead of
> element.appendChild(document.createElement('text')).textContent = 'Test'.
You mean element.appendChild(document.createTextNode("Test")). But yes,
that's how you'd script SVG.
> a: I'm using it because I work across a variety of browser platforms.
> Canvas is far better supported.
OK. And you think the timeframe for getting convergence on the things
you need for resolution-independence in canvas is shorter than the
timeframe for better SVG support, presumably?
> b: Because it's shorter
It's pretty easy to set up a helper function... But yes, the DOM does
tend to be verbose.
> and wrapping from Canvas to SVG automatically is inefficient.
This I'm not sure I follow.
>> 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.
See link above. I can dig around more if you do want more examples.
> 2. Flash is a fine technology.
No, not really.
> 3. Using canvas means having an entry point;
> typically in window.onload. They're authored to re-render based on user
> input.
See link above.
> And, these aren't great lengths. It's about 6 lines of javascript.
Uh... That depends on how your drawing path is set up. If I understand
correctly what you're doing, you have to get the DPI ration (call it N),
change the canvas width/height by a factor of N, and change all
coordinates in all your drawing calls by a factor of N, right?
> Canvas programmers have, necessarily, an understanding of how Canvas
> works. It's an API where nothing is done for you.
This last isn't quite true (e.g. there are plenty of examples of Canvas
dwim that leads to some weirdness from my point of view). And it's not
clear that it must be true; if there are ways to make the API easier to
use, we should make use of them.
> 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'm sure they do.
I'm sure HTML coders work hard too. And JS coders, too.
I have approximately zero faith in JS coders and HTML coders doing
things "right", after fairly extensive exposure to the results of their
work.
My faith in canvas coders is closer to 0.2 (on a 0-1 scale), largely
because it's not quite as mainstream yet, so only the more competent
folks are doing it.
> I'm all for easy, but I'm not for restricting users, nor breaking
> existing apps.
OK, another point of agreement.
> Using that data requires very few lines of code.
Again, that seems to depend on how your drawing is set up, unless I'm
really misunderstanding what you're doing.
-Boris
Received on Tuesday, 23 November 2010 18:53:15 UTC