[whatwg] whatwg Digest, Vol 80, Issue 31
bzbarsky at MIT.EDU
Sun Nov 21 18:30:33 PST 2010
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
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.
More information about the whatwg