[whatwg] whatwg Digest, Vol 80, Issue 31

[Boris Zbarsky]

On 11/21/10 8:31 PM, Charles Pritchard wrote:
> Canvas is an immediate mode rendering framework. I realize that it uses
> a bitmap backend,

Isn't that more or less a requirement for "immediate mode"?  After all, 
the whole issue is that when resolution changes you need to rerender 
from some sort of state you have around, which is precisely what 
immediate mode doesn't have.

> but the drawing itself works very much like vector imaging. The scene
> graph is built in the scripting environment instead of an ML file.

Right, so you're trying to build a retained-mode something using canvas 
as the rendering backend, no?

> Canvas is a low level API, SVG is a serialized format of a scene graph.
> They're not the same thing.

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

> While Apple has certainly worked in supersampling, it's completely
> unnecessary.

Well, it's unnecessary if we introduce a whole bunch of other features 
and extra work, right?

> I don't see why expecting a page to re-render is unreasonable.

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.

> Stated succinctly: It is entirely reasonable to re-render canvas when an
> "onresize" event is received,

It's reasonable to do it.  It doesn't necessarily seem reasonable to 
_force_ everyone to do that to get reasonable zooming behavior...

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

> My evidence is essentially nullified when you make broad statements
> about how there are better tools and better formats.

I'm saying that if we're going to add features to the web platform we 
should be making sure they're the right features to add and that they're 
the best ways to solve the problems that need solving.  Maybe adding 
information about the number of canvas backing store pixels per CSS 
pixel (which may NOT be the same as the number of screen pixels per CSS 
pixel, note!) is the right thing to do.  Maybe we need to expose both 
numbers (e.g. exposing the canvas backing store resolution will do 
nothing for your server-generated PNGs).  Clearly just exposing the 
screen resolution doesn't work for canvas in a world where we don't 
guarantee that canvas and screen resolutions match.

> I don't doubt your good intentions here, but I am suggesting
> that you've made an error in judgement.

I think you mistake an attempt to understand the use cases based on the 
limited information I've seen presented in this thread for "judgment". 
If there' some massive amount of background information I'm missing 
here, which is what it feels like, I'd appreciate a pointer to it so I 
don't have to keep asking questions that make you all defensive.

-Boris