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

[Charles Pritchard]

> Message: 2 Date: Tue, 23 Nov 2010 21:53:15 -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: 
> <4CEC7E1B.8090000 at mit.edu> Content-Type: text/plain; 
> charset=ISO-8859-1; format=flowed 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 likehttp://detexify.kirelabs.org/classify.html
> under this classification?
Thanks for that link, that's super cool.

Here's something related to fonts:
http://mudcube7.blogspot.com/2010/11/unicode-profiling-project.html

I just bring it up to show that it's possible that detexify app could 
run as a client-side app,
and to share a link that I like. Cause I do really like yours.

Yes, I'd classify your link as keeping around the state info. It's right 
there in the SVG path.

>> >  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"?).
Your grabbing of the PNG data is based on window onload and other such 
events.
Your use of that PNG data would likely be passed through XHR, or an 
async file system call,
and you might use web workers to shift it off the main thread.

Yes, there are ways to use canvas that don't relate to visual processing 
at all.

You could use it for a finite state automata if you want.

I've certainly played around with packing a PNG with data, and using 
getImageData to pull the data back out.
And discovered in the process that putImageData can be transformed on 
the way, so that putImageData != getImageData.

But that kind of processing isn't really a strong-suit of Canvas, nor 
very relevant to our discussion
on enabling "zoom" to work for canvas based apps.

Yes, you can use canvas to apply filters on video. I get that. I've seen 
the mozilla demonstrations of it.
Believe me, you guys have made it known.

I'm a big fan of Vlad's work on typed arrays.

>> >  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).
>
Yes, I really understand how slippery-slope arguments work.

I'm sure you've gone through your fair share of traumas about scope creep.

We've got a _sane_ general approach that has nothing to do with canvas:
expose css pixel metrics to the scripting environment.

As a mature browser vendor, you have failed to do this, over the span of 
years.

You're ending up with a whole bunch of disregarded users worrying about
catching flees from dogs like me.

>> >  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?
Yes HTML is a document format. They use quite a few APIs in addition to 
the HTML format.

Gmail also happens to use Chrome, but that's another story.

>> >  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.
I'm not going to have you explain to me one more time why it is that I 
should be using SVG,
and that this accessibility defect is a non-issue.

>> >  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.
element.appendChild(document.createTextNode("Test"));
element.setAttribute('x', x); element.setAttribute('y', y);

>> >  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?
Again.. we're talking about a few floating point variables here. I've 
already got
resolution independence in Canvas on mobile phones, I've got it in IE9, 
and I've
got it in Chrome.

I'm talking about two variables. Lets stay technical here.

The issue isn't the variables. The issue is gaining an agreement between 
your team,
and the relevant WebKit and IE developers.

As IE has exposed the data, and Chrome devs are standing by, waiting for 
a standard,
I'd say the time-frame I'm looking at is the one in which you are 
willing to expose
CSS pixel metrics.

>> >  b: Because it's shorter
> It's pretty easy to set up a helper function...  But yes, the DOM does
> tend to be verbose.
Yes, it's very easy to setup a helper function.

>> >  and wrapping from Canvas to SVG automatically is inefficient.
> This I'm not sure I follow.
There are wrappers from SVG to Canvas. Like CanvaSVG.
There are wrappers in the other direction, from SVG DOM calls to 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.
> See link above.  I can dig around more if you do want more examples.
Rob did fine. Link above uses SVG.

>> >  2. Flash is a fine technology.
> No, not really.
I'd say as a browser vendor, you're a bit biased.

>> >  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?
>
You're correct, I grab DPI, lets call it xN and yN, I change the canvas 
width height.
Then I run   .scale(xN, xY) before my drawing calls. They're completely 
agnostic
to the change.

I'm going to go back to the ad-hominem. You have no experience to make 
judgments here.

If you'd like some experts to chime in, ones that aren't me, that's 
something that can be arranged.


>> >  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.
I'm going to argue the slippery slope on this one.

Consider it argued.

>> >  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 hope you have more respect for other parts of your user base.

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

It's perfectly simple to run ctx.scale(xN,yN) following the onresize 
loop. The state is reset when you resize the width/height of the 
canvas,  and it can be the first call following that resize.

Would you please hit Reply All, and Cc me and Robert on your future 
replies to this thread. Robert has been quite engaged,
and I've had some difficulties hitting reply in Thunderbird on your 
messages from the digest.

-Charles