Re: [Blockbuster-devel] Image cache changes

[Robert E. <pa...@tu...>]

>>> Along the way, I found quite a few bugs related to sub-image handling
>>> in the file loaders and ConvertImageToFormat().  I think there may
>>> have been a fundamental misunderstanding of how sub-images were to be
>>> handled.

I certainly coded for a different idea of sub-images, so I guess that
supports the "fundamental misunderstanding" hypothesis. ;-)

>>> The basic idea is this:
>>> 1. We always allocate image buffers which can store the entire frame.
>>> 2. When we do a sub-image load, we store the data into the
>>> corresponding sub-region of the image buffer (not at the origin/start).
>>> 3. The image->loadedRegion records which area of the image buffer is
>>> actually valid.
>>> 
>> My biggest concern is with (1).  If we have a 10kx10k framesize,
>> will this still work?  Also, the performance of drawpixels can drop (or
>> even crash on some machines) if the strides are large.  Is the thinking
>> here that the "mipmaps" will keep this size capped?  Consider the Sandia
>> wall that is 64Mpixels laid out as a 12x4 projector array.  That's a
>> pretty big chunk of memory to use as a cache.  Perhaps one could split
>> the difference and use a local, sliding window with valid subregions and
>> on a new rect, preserve as much of tha cache as one can as the cache
>> window slides to include the new subregion?
> 
> I think that could work (the sliding window).  It'll have to wait
> until the second delivery though.

As an alternative, how about:
- Add a field to the Image structure that indicates "Full frame allocated"
- On a new frame request (one that doesn't exist in cache), we allocate
memory sufficient to store only the desired subimage, and set
fullFrameAllocated to 0.
- On a new region request (i.e., when the desired frame is in cache, but the
desired region isn't included), we do something like:
  if (!fullFrameAllocated) {
     allocate a full frame image
     copy the contents of the old region to the new image buffer
     set fullFrameImage to 1
  }
  load the necessary additional regions into the image buffer
  reset the loadedRegion appropriately

This would minimize allocated memory while running a movie, and still allow
for nice panning & zooming.  We might even get better "panning while
playing" performance than we would in the other cases.

> When you get into 10kx10k images, you're probably just dealing with SM
> files, right?  The png and tiff libraries don't allow sub-region reads
> (at least not normally) so those libs might blow up before you get
> anywhere near that large.

The TIFF reader actually reads scanline by scanline, and can do a vertical
subset of the image (not as good as a true subregion, but not as bad as
requiring the full image).

>> FYI: a comment on frame sync.  So, nVidia has announced the FX 3000G
>> card, w/edge blending and genlock/framesync in HW (the physical card
>> has daisy chained RJ45s for the handshake and support for a "house
>> sync").  There is a simple X11 API for working with these features.
>> At some point (perhaps v2.0?) we should consider adding support for
>> this as an alternative frame sync in Blockbuster.  I got a couple
>> cards yesterday and will be trying them out soon.

Ooo!  Oooo!  New toys!  New toys! :-)

papillo the cache flow analyst
Bob Ellison, Tungsten Graphics