Re: Whiteboard cacheing

[David Malcolm <dmalcolm redhat com>]

On Fri, 2005-04-29 at 11:25 +0200, Alexander Larsson wrote:
> On Fri, 2005-04-29 at 10:20 +0200, Alexander Larsson wrote:
> > The whiteboard cache changes didn't build for me, so i commited a fix
> > that I think will work. Its untested though, because i can't seem to
> > deploy without getting an OOM error atm.
> > 
> > Also, thinking about the caching during the night, wouldn't it make more
> > sense to actually cache the png images on disk? That way we'd use less
> > memory, let the kernel handle when and what to cache, and its still
> > faster to read the thumbnail file from disk than regenerating the full
> > image and then scaling it down. Especially since every client will be
> > reading every thumbnail.
> 
> Also, looking at the current code it seems to not also create the
> thumbnail when rendering the full image. It really should, because if
> you load the full image you will always also need the thumbnail one, and
> having to render the fullscale image twice (with the 1 megabyte
> temporary buffers and other stuff being generated) is bad.

It _was_ using the cache of the drawn fullsize BufferedImage when
generating thumbnails; I checked the debug logs.  But your approach is
probably better.

> 
> In fact, since after drawing a stroke the client is guaranteed to
> request it i think it would make sense to render the initial versions in
> the addStroke method call to avoid races for in what order to draw
> thumbnail/full image.
Were there really races?  I thought I'd made all of the whiteboard
methods that accessed the cache synchrnoized