- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sun, 21 Nov 2010 21:30:33 -0500
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
Received on Sunday, 21 November 2010 18:30:33 UTC