| When you say the 3500, do you mean the 3520/3540? I think a 3500 is also a
gpx, but with a cvax cpu chip.
Anyway, all dragon-based color workstations will work much faster if StoreColor
is done into contiguous, ascending pixel values. The driver wants them that
way, and if they are not, the server has to break them up into contiguous
packets. I believe that each packet waits for a vertical retrace before
updating the colormap. Thus, if you get the 16 colors contiguous ascending
the update will be done within about 16 ms. If you have them out of order,
it could take as long as 16*16=256 ms.
You can force planes to be allocated contiguously with a bit in AllocColorCells.
This does not help much, though, unless the planes you allocate start at plane 0.
You might think about some funny game where you get the colors from the colormap
for the values that fall between yours and update them all. This is very
dangerous (suppose someone changes one of those colors), but it might work as
a hack. Before you try it, the driver also requires the flags (DoRed, etc) to
be the same, so don't bother to make up a set of contiguous pixels with the
flags all 0 on the ones you don't want to change!
The other thing you could not is to not use the default colormap. If you own
the colormap, you can do anything you want. It has the disadvantage of making
other apps go technicolor, of course.
Not relavent to this question, but fyi, the GPX hardware can't completely update the cmap
in one vertical retrace interval, so to avoid screen glitches, it breaks long
updates up into pieces. I don't remember the size of the pieces, but the
point is that if you ask for more than some threshhold of updates per request,
you could also wait for more than 16ms.
Why other systems work better? The PMAX may be not waiting for retraces. This
could cause the glitches you see. VWS was a whole different world. I suspect
it made different tradeoffs. For example, the driver wants things contiguous
so that it can blast the values into the h/w registers with a MOVC3. That way
you get the maximum number of color updates in the vertical retrace. I don't
remember for sure, but VWS may not have used a MOVC, and moved individual colors
to the registers separately. That would trade of maximum number of updates per
vertical refresh in the best case with performance of non-contiguous updates.
For an idea of what speed is possible, look at cmap, a colorwheel program which
rotates using StoreColors. It is in the DECWINDOWS_PROGRAMMING conference.
Burns
|
| Burns, thanks for clarifying things - I just got a copy of colorwheel.c
and will do some experiments along these lines. It's more than likely
that my color cells were in an unfortunate order in the array passed
to store colors... too bad there isn't a clean way to get high speed
color map updates; it can be very useful on a pseudo color display at
times.
Yes, I have a 3500 (GPX with CVAX), and the problem is the same as on
the GPX. the 1/4 second you mention is about in the ballbark of the
glitches I see.
I'll follow up with what I manage to make work in case this comes up
again...
- Jim
|