W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

[whatwg] Low Memory Event

From: Glenn Maynard <glenn@zewt.org>
Date: Sat, 1 Jan 2011 23:27:05 -0500
Message-ID: <AANLkTi=xEVUek0GihMYJLUxeocEqj3eDTfJv_ibLRW1b@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:29 UTC