- From: L. David Baron <dbaron@dbaron.org>
- Date: Fri, 29 Jul 2011 16:55:10 -0700
- To: Alex Danilo <alex@abbra.com>
- Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, www-svg@w3.org
On Saturday 2011-07-30 09:38 +1000, Alex Danilo wrote: > I very much doubt any capable implementer would find managing > the replay memory to be difficult or a source of leakage. The term "memory leak" doesn't only refer to memory that the implementation forgot to call free() on; it refers to memory that is being used unnecessarily. In that sense, which is the sense in which Boris is using it, the term can be applied to languages in which memory allocation and deallocation is managed by the language runtime. The key problem here is that canvases may have millions of drawing operations, some of which overlap others. Maintaining a data structure that maintains all drawing operations whose effects are still visible while discarding those that are not, at a small constant time (not amortized) per drawing operation, is not a trivial task, but I'd argue it's the minimum acceptable standard given the way canvas is used. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla Corporation http://www.mozilla.com/ 𝄂
Received on Friday, 29 July 2011 23:55:39 UTC