- From: Glenn Maynard <glenn@zewt.org>
- Date: Sat, 1 Jan 2011 23:27:05 -0500
On Sat, Jan 1, 2011 at 9:52 PM, Roger H?gensen <rescator at emsai.net> wrote: > Charles, you initially said you where worried about this since you used undo > buffers. > Why not simply add undo buffers to the Canvas spec? That way the browser can > start tossing away the oldest undo buffers automatically when it starts > getting memory anorexic. > And depending on the browser implementation and the OS and hardware support, > on some systems the Canvas undo buffers could even be in graphics memory. > It's wrong for Canvas to have undo stuff in active memory, most graphics > programs store the undo on disk or it's paged out to a swapfile at the > least. > So if you have to make your own undo buffers for Canvas, then I'd say that > Canvas is lacking and might need undo buffers as part of it's spec. Concepts like "undo buffers" are high level application behavior--that doesn't belong in Canvas directly. A "discardable" flag is the right level of abstraction, though. It's definitely not simple. It also would be needed in many separate APIs--Canvas, WebGL, ArrayBuffer, HTMLImageElement, and anything else that can store large blocks of data (directly or indirectly). I started suggesting the same thing, but stopped since I don't see that ever happening. For what it's worth, Windows used to have an API to allocate "discardable" memory, which could be deallocated under memory pressure; it required locking and unlocking the memory, so when unlocked the memory essentially operated as a weak reference that could be deallocated as needed. I think this was only supported in Win16 (the GMEM_DISCARDABLE flag to GlobalAlloc); I mention it only for reference. -- Glenn Maynard
Received on Saturday, 1 January 2011 20:27:05 UTC