| Title: | DECWINDOWS 26-JAN-89 to 29-NOV-90 |
| Notice: | See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit |
| Moderator: | STAR::VATNE |
| Created: | Mon Oct 30 1989 |
| Last Modified: | Mon Dec 31 1990 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3726 |
| Total number of notes: | 19516 |
I spoke with a workstation specilaist about the fact that applications on the VS 3100 run much, much slower for the VR290(color) versus VR260(monochrome). He says the problem is going from 2 bit plane to 8 bit plane and the fact that the dragon color chip set can only take 64K byte data chunks. When I told him the prototype application the customer ran took 24 seconds in B&W versus 15 minutes in color, it did not surprise him. The customer is Hughes Fullerton,Ca and they are prototyping an Air Traffic Controller type of application. They time how long it takes to do 40 iterations of screen updates. For the B&W, it takes 24 seconds(80 direct I/O's). For the color it takes 15 minutes(5700 direct I/O's). They are running VMS 5.1-1, DECwindows 1.0, and Ada 2.0. They are issuing X calls instead of using the DECwindows toolkit for speed. The application is memory resident, no paging, and the only I/O is to the monitor during the run. My only recommendation at this point is to dig up the UIS docset where it explains how to issue QIO's directly to the graphics controller. However, the improvement in performance would not nearly compensate for the degradation they are experiencing when going for B&W to color. What, if anything can they do?? Are we we stuck with the answer, Mr. customer, you have the wrong hardware platform to get the kind of performance you desire?? What if anything can we do. Thank you, Ben Bradley
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1592.1 | FK::FRED | So sue me. | Wed Oct 18 1989 13:49 | 9 | |
The UIS docset won't help much unless you want to load the UIS drivers
and program a standalone graphics application (no window system).
And in fact, depending on the operations that they are doing, even
doing direct addressing of the hardware might not help. You may
indeed need a different graphics controller...
| |||||
| 1592.2 | STAR::MCLEMAN | Jeff McLeman, VMS Development | Wed Oct 18 1989 14:54 | 2 | |
Is this customer doing alot of direct pixel addressing? | |||||
| 1592.3 | Probably pixmaps | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Thu Oct 19 1989 22:59 | 36 |
My guess is that they are using either a lot of pixmaps or several big
pixmaps. There is only room in a GPX for about the same size of pixmap
as the screen. When all the pixmaps can't get layed out on a rectangle
the size of the screen without overlapping, some have to be kicked out
into virtual memory. This is slow.
The monochrome system, on the other hand, has everything in virtual
memory to begin with. It is more cpu intensive to do drawing (since
the cpu is setting all the bits), but it is much more general.
I think the I/Os confirm my theory. Normally, you should not see many
I/Os. Graphics output generally uses a different mechanism.
What to do? If I am right, there are some possibilities:
1. Try to reduce the use of pixmaps
2. Try to do lots of access to one pixmap before going on to the next
one (to reduce thrashing)
3. Don't use fulxD depth pixmaps when you could use depth-1. If the
data being stored is only two colors (even if they are not black and
white) you can use a depth-1 pixmap and a CopyPlane ri]ather than a
full depth pixmap and CopyArea. The depth 1 pixmaps can be stored
on top of each other, multiplying the number of pixmaps you can have by
8.
4. See if it makes sense to use several small pixmaps rather than one
big one. This may seem backwards, but if you are doing a lot of
drawing one corner of several different big pixmaps, it might make
sense to divide the pixmaps into pieces and let the infrequently used
sections get "paged out". Also, you might fit more small pixmaps into
"nooks and crannies". This last measure is a bit more iffy than the
first 3, btw.
Burns
| |||||