- From: Dean Edwards <dean@edwards.name>
- Date: Thu, 16 Jun 2005 20:23:16 +0100
Sjoerd Visscher wrote: > Sjoerd Visscher wrote: > >> Dean Edwards wrote: >> >>> Charles Iliya Krempeaux wrote: >>> >>>> To be honest, the think the idea of "drawing transactions" is >>>> better. Here are the reasons: >>>> >>>> #1: It makes it so, if the develop wants it, that they can have things >>>> that are "drawn" show up immediately. (I.e., they aren't forced to >>>> use "double buffering" [or whatever].) >>>> >>>> #2: It makes it so you could have "long lasting" scripts execute. >>>> >>>> #3: It makes it so Java and C++ interfacing will work the same. >>>> (I.e., you don't have to give C++ and Java an API to effectively do >>>> "drawing transactions" without also giving this API to JavaScript.) >>>> >>>> So +1 for "drawing transactions" :-) >>>> >>> >>> +1 >>> >>> I'd hate to see them implied by script blocks though. That way lies >>> madness. ;-) >>> >>> -dean >>> >>> >> >> I'm just describing how it is currently implemented in Firefox. And >> how DHTML rendering has been implemented for years. I don't think that >> will change, and so canvas has to play with the same rules. >> > > I have been thinking about this, and I think there's no way to change > how this works. It would break a lot of existing content. And I don't > like a special case for canvas either. > > However, it would be nice to have a forceRedraw() method on window, like > SVG has. http://www.w3.org/TR/SVG/struct.html#InterfaceSVGSVGElement > I think (I might be wrong) that you are discussing internal implementation details of a UA (in this case Firefox). This is not what Charles and I are discussing. We are talking about how the implemented API would work in a browser environment. -dean
Received on Thursday, 16 June 2005 12:23:16 UTC