Jerome_V_Vollborn@cup.portal.com (06/28/89)
I am building an application that needs to have variable size (up to
full screen) windows with the background developed off line by the
user. I tried using a bitmap file loaded by the ReadBitmapFile call.
For a full screen this took approximately 5 minutes on a microVAX GPX.
I consider this to be unacceptable. If you have a suggestion, please
read the following description and comment. I will, of course,
summarize any mail replies for the net.
GORY DETAILS:
Hardware: DEC microVAX GPX with 9 mb of memory, 360 mb disk, TK50 tape
Software: VMX 5.1 with DECwindows, LAVC (remote boot) and DEC Ada 1.5
Application: Graphic user interface for a shop floor automation system
where the user can configure all of the background, icons
representing production equipment, pop up windows with
equipment information, etc through a graphics editor and
requiring no programming knowledge. Background and icons
to be developed using either "bitmap" or DEC's PAINT (in
either case a bitmap file is to be saved).
Problem: At present, the prototype application program reads the bitmap
file using the Read_Bitmap_File call from DEC's DECW$X_.ADA
specification (the DEC people at the Colorado Springs help
facility say this is an immediate call to the XLIB ReadBitmapFile
call). For a full screen file (1200 by 800 pixels) this call
takes at least 5 minutes to complete (30 seconds might be
acceptable). The following Copy_Area call completes almost
instantly as expected. So the basic problem is how to speed
up this process by an order of magnitude.
Proposed Solutions:
1. Compile the bitmap file, link the file to the application, and use
the Create_Bitmap_From_Data call. It appears that this should be
much faster (no opening files, translating the source into bits)
and uses standard X calls. It would require the shop floor systems
to have C compilers and would require the operators (who could be
production people and therefore untrained in computer operations)
to select the correct runnable images.
2. Learn how the bitmap (or pixmap) data is stored in memory, save the
pertinent information (size descriptors, bitmap strings, etc.) in
a binary file at generation time, and fake the X calls (and write
directly to server memory) at run time. This should be fast excepting
the file I/O time. It is also one of the less portable, disgusting
hacks I've heard of in a long time. The source of this suggestion
shall remain nameless.
3. Create a list of foreground pixels instead of the bitmap file at
generation time and use the Draw_Points call to put them into the
map at run time. For sparse backgrounds this should be faster than
the Read_Bitmap_File and does use standard X calls. For dense
backgrounds the overhead could be prohibitive.
4. Create a list of graphic tokens at generation time and use the
graphic primitives at run time to put the data in the map. This
should be faster than saving pixels and would use standard X calls.
This would require a significant amount of work to generate the
graphic tokens from an arbitrary background or a new graphic editor.
5. Have all of the available bitmaps loaded into the server when the
system boots up or a new map becomes available (using a detached
process) and load the map by name. This masks the load time and
does use standard X calls but would use a lot of server resources.
SUMMARY:
I need to load some, possibly, large bitmaps in a reasonable amount of
time. I have some possible solutions but none of them seem elegant. Do
you know why any of these should be rejected out of hand or do you know
of a really elegant solution?
Thanks for your time. Again I will post a summary of responses to the
net.
Jerome Vollborn
(Jerome_V_Vollborn@cup.portal.com)michaud@decvax.dec.com (Jeff Michaud) (06/30/89)
In article <19946@cup.portal.com>, Jerome_V_Vollborn@cup.portal.com writes: > SUMMARY: > > I need to load some, possibly, large bitmaps in a reasonable amount of > time. I have some possible solutions but none of them seem elegant. Do > you know why any of these should be rejected out of hand or do you know > of a really elegant solution? The problem is that X Bitmap files were designed to be portable, and not for speed. Every time you read one you have to parse it in ascii. What you want to do is convert the bitmap file to a raw binary form with a min. header of a couple of words that give the dimensions and then the raw data. Then modify xsetroot to read this new format. Or better yet (ie. w/out having to write/modify any code), use one of those pbm or fbm packages that have been posted to convert/display the images. One of them must have an option to display the image on the backround. -- /--------------------------------------------------------------\ |Jeff Michaud michaud@decwrl.dec.com michaud@decvax.dec.com| |DECnet-ULTRIX #include <standard/disclaimer.h> | \--------------------------------------------------------------/
rws@EXPO.LCS.MIT.EDU (07/03/89)
For a full screen file (1200 by 800 pixels) this call
takes at least 5 minutes to complete (30 seconds might be
acceptable).
Do you know why any of these should be rejected out of hand or do you know
of a really elegant solution?
Use The (MIT R3) Source, Luke? I consed up a random 1200x1000 bitmap source
file, and it took about 8 seconds to read it on a VAXstation 3200 (calling
XmuReadBitmapDataFromFile, which is the same as the parsing part of
XReadBitmapFile).