Re: Rapid gfx display Qs

"Jim Mack" <jmack@xxxxxxxxxxxxxxx> wrote in message news:O5Q2O3etIHA.552@xxxxxxxxxxxxxxxxxxxxxxx

I have a task that involves getting still image files to the
screen as quickly as possible (20ms max). These images
are all equal size . . . for testing all I have is my pedestrian
2gHz, single-core with IDE drive and older graphics.
To get a baseline, I timed just getting (LoadPicture) random
1280x720 BMP files into a picture box with autoredraw off.
The average load time was about 65ms, with almost no variation
To my surprise, turning autoredraw ON reduced this to 60ms
on average. Any ideas why this should be so?

I think with Autoredraw False you are effectively timing the total time both of loading the picture from disk into memory (into the PictureBox's Picture property) and also the time taken for the OS to dump that picture to the screen. In contrast, with Autoredraw True, you are timing only the time taken to load the picture from disk into memory (into the PictureBox's Picture property) because the VB Autoredraw system itself will dump the property to the actual display just after your code has finished. You will probably get the same timings as you get with Autoredraw True if you instead load the picture into a StdPicture object rather than a PictureBox, because the StdPicture Object does not dump it to the screen at all. However, in order to both load the picture and dump it to the display you need to take account of both timings (the time to load from disk into memory and the time to transfer the memory image to the display) and the Autoredraw True is just making you think it is faster because it is really only timing one of those things. Does that make sense? It's all "off the top of my head" at the moment, but it seems to be the most sensible explanation? Anyway, on my system which is a fairly old AMD 2.2 Ghz with a Radeon 9600 card AGP graphics card and with no gdi32 hardware acceleration (because the gdi32 hardware acceleration has been "knobbled" by Vista) I get the following results (on a Autoredraw False PictureBox):

Picture1.Picture = LoadPicture("c:\settle.bmp") ' 39 msec

.. . . and (where p1 is a StdPicture object):

Set p1 = LoadPicture("c:\settle.bmp") ' 25 msec

.. . . and:

Set p1 = LoadPicture("c:\settle.bmp") ' a total time
Picture1.Picture = p1 ' of about 39 msec altogether

.. . .and (on an Autoredraw True PictureBox)

Picture1.Picture = LoadPicture("c:\settle.bmp") ' 26 msec

' but the above 26 msec is simply because the timer is not
' taking account of the transfer from memory to screen, as
' mentioned in the above paragraph, which happens after
' the time is read

So it looks as though on my machine it is taking 25 msec to load the image from disk into memory and a further 14 msec to transfer it from memory to the display (in XP the second figure would probably be less than 14 msec because gdi32 hardware acceleration works in XP).

So, to get less than 20 msec overall on this machine the very first thing I am going to need to do is to reduce the "load from disk into memory" time to a lot less than the 25 msec it is currently taking, which of course means reducing the file size. So that leads us to jpgs. If I do this:

Set p1 = LoadPicture("c:\settle.jpg")

I get a time of about 79 msecs (much longer than before) just to load the picture into a StdPicture object, even though the file size of the jpg is very much smaller, only about one tenth of the file size of the equivalent bmp. The LoadPicture (or any other similar function) does of course need to both load the jpg data into memory and then convert the jpg to a bmp (decompress it). The time it takes to load the jpg data itself will I imagine be only about 3 msecs (or possibly more because of the seek time) because the jpg data is only one tenth of the file size of the bmp, and so that leaves a massive 70 or more msecs which the machine is using just to decompress the jpg data.

With a bmp on disk you need to time two steps (load the data from disk into memory and then dump it to the screen) and with a jpg you need to time three steps (load the data from disk into memory and then decompress the data into a bmp and then dump the bmp to the screen). As things stand at the moment the second step in the jpg process (decompress the data) massively overwhelms any saving you might make from the fact that the file size on disk is much smaller. GDE+ will probably improve on the jpg decompression time quite a lot, but I still think it would account for far too much of the time (although I've never actually used GIDE+ so I cannot be sure on that). Howvere, GDI+ will probably give you a much wider choice of original image format, which may help things along when deciding what to do.

Unless you've got a machine that has very fast disk access then you're going to be in trouble reaching your overall timing requirement unless you reduce the file size, and if you reduce the file size in order to overcome the "load from disk" limitation then you're going to need to look for a very much more efficient (in terms of speed) compressed file format than a jpg, perhaps .png or .gif or something? Much of course depends on the nature of your images, and it is hard to comment any further really without knowing what sort of images they are.

Anyway, these are my initial thoughts, for what they're worth, and there is obviously a lot more to think about than the few points I have covered. Perhaps others here will pop in with some other suggestions. In the meantime, if you would tell us more about the nature of these images it may give us some more clues as to how best to proceed.

Mike




.

Relevant Pages