[rescue] Sun 711

[Joshua D Boyd]

On Thu, May 02, 2002 at 08:03:42AM -0700, James Lockwood wrote:
> > It depends.  You don't want to open each file and close it while playing
> > I would think, but that would be a good place to start.  Assuming it
> > doesn't work, a possible next step would be to open all the files at
> > once, and keep them open the whole time.  That would save on all those
> > extra open and close calls, and might be good enough.
> 
> Speaking as someone who has written a playback interface (though on a
> somewhat less grand scale than this):
 
> You do not want to be opening a file for every frame, the overhead though
> less than it was years ago still exists.  Either access the data as one
> big uncompressed file/raw partition, or bunch the frames into "frameset"
> files.  1 second each at 300MB/ea would be a convenient size.

How bad is the over head if you open all the files at once?  Then are the
system calls going to add anymore overhead than having 1 file?
 
> You don't have enough time to do most lossless decompressions.  TIFF buys
> you nothing for your app except some extra parsing overhead, which can be
> significant.  Consider having an intermediate step (assuming your data
> comes in as TIFF) where you load each frame into a raster and then save
> the raster image into your file structure.
 
> You _must_ do readahead here.  The easiest way to do it is to use a shared
> memory ring buffer (600MB-1GB would probably be good here, 2-3 seconds)
> and either 2 processes or threads.  One constantly tries to keep the ring
> full of new data, pausing only when it has completely filled it.  The
> other process pulls one frame off the ring every $FRAMEINTERVAL.  If you
> have a couple seconds of readahead you do not need low latency, unlike
> what an earlier post claimed.

I thought of that, but didn't want to spit out something that complicated
if not needed.
 
> For extra credit, determine the exact byte requirements for your display
> and save your rasters in a format that can be directly blitted in.  This
> may well be the only practical way to do it.

Hmm, I'd assumed that letting GL sort it out would be the best way to deal
with that.  Perhaps not.
 
Baring a nice Solaris solution, the best solution would probably be to buy
an off the shelf NT or Mac machine that does the job.  If it doesn't, return
it and buy the next one.  Or, ask eyeon what they recommend for the job.

-- 
Joshua D. Boyd