- From: Sjoerd Visscher <sjoerd@w3future.com>
- Date: Thu, 16 Jun 2005 22:28:34 +0200
Dean Edwards wrote: > 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. No, I'm talking about what you are talking about. -- Sjoerd Visscher http://w3future.com/weblog/
Received on Thursday, 16 June 2005 13:28:34 UTC