Re: Rapid gfx display Qs


"Jim Mack" <jmack@xxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:%23BEQTejtIHA.748@xxxxxxxxxxxxxxxxxxxxxxx

I found that I can reliably load a random image file (BMP)
into a byte array in about 8ms, with enough images that on
average I will swamp the file system cache at least some of
the time. In any case it's how I'll be operating, so it matches
reality. (-:

Think you will have to consider compression in either way,
if you want to load and show these images with ca. 50Hz
randomly.
At this frequency (50Hz), your Disks would have to work
with a sustained throughput of ca:
135MB/sec (for 24Bit-Images)
or ca.
90MB/sec (for 16Bit-Images)

These transferrates in read-direction are only achievable
with a (serialized) stripe-set of two modern disks (a single
disk has only ca. 70-100MB/sec with sequential reads).

But what makes this worse again is, that in your scenario
you have no sequential reads, so you cannot rely on pre-
reading the next few sectors and also not on the systems
filecache.
I'd say, with ca. 30000 files, accessed in more or less
random order you will be hit with the positioning-time
of the Disk-Heads in ca. 90% of all Image-Reads.
That would add ca. 8-9msec waittime (given a 7200RPM
SATA-Disk) or a ca. 4-6msec delay (given a 15000 or
10000RPM SCSI-Disk), before the Read-transfer from
the Disk can start at all.

Ok, using the asyncread FileAPI-Flags you can work around
that RandomAccess-DiskHeadPositioning-problem, if
you give the command for the next filename, before you
start to display your current image on the screen, so that the
rendering and the waiting for the DiskHead-Positioning
(and also the transfer) can take place at the same time.
But beside that (as already said on top), as long as you
work uncompressed, even your ideal disk-transferrates
cannot match with your 50Hz requirements.
Maybe you only want to show these images with 25Hz,
but even that would make problems, as long as you
don't have your Data on a stripeset of two serialized Disks.

Long story short, work with JPGs (if your images are
true-color-images from a VidCam) or work with zlib
or some faster losless compression-algo, if your images
are more "plain-colored" (e.g. screenshots with a low
percentage of color-gradients).

And yes, the VB-LoadPicture-function is really slow if you
need to work with JPGs, but there are much faster JPG-libs
out there. With the ijl15.dll (the intel-jpeg-library) I
just did a small test with an 1280x720.jpg (ca. 140kByte
in size using 85%JPEG-Quality) - and such an image
can be decoded into a 1280x720x3 (24Bit-DIB)
in ca. 9-10msec here on my 1.8GHz Mobile-CPU.
Finally StretchDIBits, drawing from the 24Bit-DIB to the
Form.hDC takes only 4-6msec here.

With JPG-compression you can reduce your disk-
transfer-sizes/times by ca. factor 10-15, working in a
much more comfortable range.

Currently your worst-case with a 16Bit-DIB looks
this way (assuming 80MB/s Disk-Read-speed):
Head-Positioning ca.: 9ms
Transfer 1.75MB imagedata from disk into memory: 22ms
Visualizing of this memorybuffer to screen using
StretchDIBits or SetDIBits: 6msec
Sum: 37msec

You cannot get faster (even with async reads) than
9ms+22ms = 31ms, even on your more capable
CPU-System - maybe you can reach 8ms+20ms=28ms
if it has fast, modern SATA-disks, but not much faster.
As said, maybe with a stripe-set, doubling your sequential
read-speed, you could get down to: 8ms+10ms, but not
much faster.
Diskaccess-time and -diskread is the limitation in your case.

With Jpg-encoded images you will get (even on a
single-disk system):
8-9ms accesstime+2msec for the transfer from disk into RAM.
If done async, you can use these 11msec for decoding
the image and visualizing it (ca. 6-7ms on a fast CPU
for decoding with ijl15.dll + 5-6ms for visualizing per
Set- or StretchDIBits) - so both async-processings need
approximately the same amount of time (ca. 11-13ms).

This way (async read of the next Jpg-Bytes, whilst
decompressing and visualizing the current Bytes)
you can work far below 20msec, giving you some
more time to wait for e.g. the vertical blanc.

If you are interested, I could post an example for the
ijl15-related code.

Olaf


.

Relevant Pages

  • Daily #4116
    ... Resovled Images of LMC Microlensing Events Observed by a Telescope at ... caused by faint LMC stars. ... Testing the Stellar Coalescence and Accretion Disk Theories of Massive ...
    (sci.astro.hubble)
  • Sharpest Image Ever Obtained of a Circumstellar Disk Reveals Signs of Young Planets
    ... SHARPEST IMAGE EVER OBTAINED OF A CIRCUMSTELLAR DISK REVEALS SIGNS ... are signs of unseen planets. ... has acquired high resolution images of the nearby star AU ...
    (sci.astro)
  • NIB to Disk!
    ... portable) for the PC that splits the .nib image into tracks, marks sync bytes, makes sure the track start is at the start, removes garbage and shortens inter-sector gaps, all to fit the 53248 bits per track of a ..nib image into the merely 51024 bits per track of a well-adjusted Disk II drive. ... tracks as files from a DOS 3.3 disk and then writes them to a new disk. ... and transfers the track files to the disk images. ... the game: the demo program, the player disk copier, the start of the ...
    (comp.sys.apple2)
  • Re: Cromemco CP/M 5 1/4 disk
    ... My recollection is that the source code has conditional assembly in it for persci/stepper motor drives, and also for 8"/5.25", but the 5.25" was never tested. ... I don't think I supplied disk images, per se, but rather source and object code for the files. ...
    (comp.os.cpm)
  • Re: SVD 1s on eBay
    ... >>> am selling original SVD 1's on eBay with and without Apple dongles. ... I wanted an SVD for a long time but couldn't get ahold of Eric ... To sum it up the SVD let's you run disk images on your Apple computer ... You upload your disk images to the SVD and hook the SVD ...
    (comp.sys.apple2)
Loading