Conference bulova::decw_jan-89_to_nov-90

    There is an internal application called FILM that might be of interest
    to you! 
    
    See ELKTRA::DW_EXAMPLES note 186 for details.
    
    I am not saying this will resolve your problem but it ought to show
    you whether it is possible or not!
    
    Gerry

How are the screens built? Are they dynamic? How dynamic?

You may be better off creating a pixmap for each frame and using XCopyArea
to update from the pixmap to the screen. If the frames change each time they
are displayed then this won't work. if they change infrequently then it might
work. How large are the frames? How many bits-per-pixel is the data? How many
frames are there?
						Bill

If this is doable (and it may be just on the edge of doability), it will most
likely need gobs and gobs of memory. To meet a 20 hertz requirement (50ms/frame)
you will have to at least double buffer, so you can be displaying from one
region while filling the other region with (say) the next second's worth of
images from disk. Depending on how quickly the disk can move all that data, 
you may even need to triple, quadruple buffer.

- George

    To put the problem in more detail:
    
    The requirement is to display 768 by 800 pixel static images 4 bits
    deep and to rotate somewhere in the order of 30 such images in a loop
    (or possibly only once, this is still unclear).
    
    The proposal is to use a firefox 24-bit plane machine running vms to do
    this.
    
    My thoughts on this were that it would be do-able in a three stage
    approach.
    
    1)rotate 6 4-plane images round the 24-bit frame buffer by changing the
    colour map entries(?)
    
    2) move new bit planes from off-screen graphic memory into the frame
    buffer.
    
    3) move new images from vax memory to off-screen graphic memory.
    
    I have not had much time to play with either colour or a firefox and so
    am not familiar with the details of the hardware, but from a first look
    at the problem, I believe that the above approach may work.
    
    The animation is part of a larger control screen, but is perceived as
    the most difficult part of the display to achieve.
    
    It would be most helpful if someone familiar with the firefox could
    comment on whether the above scheme is close to the mark or if this
    kind of animation is impossible with today's hardware.
    
    Mike

    Isn't this a task for ELN? V4 supports DECwindows, if I've interpreted
    what I've heard right.
    
    ...petri

You have a good plan in theory; unfortunately, you won't be able to do the
colormap playing that you want to do with a Firefox.

The problem is that you need a "Pseudocolor" display (i.e. one where you can
do anything you like with the colormap). Unfortunately, the FF only supports
Pseudocolor with 8-bit depth.  If you want 24-planes, you have to use
either DirectColor or TrueColor, which won't work well enough, I'm afraid.

Note that if you had full 24-bit pseudocolor, you would need a colormap
with 2**24 entries.  As it is, the colormap has only 3*(2**8).  Actually,
it has 3*(2**10) since there are 4 separate colormaps.

This is not to say it is not possible in some way, but I am not the person
to answer you that.

Burns

You could still create 24 bit deep pixmaps for storing bit planes offscreen
and copy them into a pseudo color window. An 8 plane pseudo color window
could hold 2 of your 4 bit plane images and color map changes could be used to
switch between 2 4 bit images in an 8 plane pseudo color window.
							Bill

    Hi there!
    
    	If you need VMS for this solution, then definitely go for the
    	Firefox. I played around with the Firefox when I was doing the
    	'film' program mentioned in .-4 and you can get some fairly
    	good results if you use the gobs of offscreen memory that the
    	Firefox has. I loaded stacks of 24 1-bit 640x480 images into
    	offscreen memory and then did XCopyPlane onto the screen and
    	achieved frame rates of about 30 frames/second. The Firefox
    	didn't do too well when I tried to go from VAX memory into
    	the framebuffer, but the limiting factor was SOFTWARE (the
    	X5.0-mumble server chewed up one CPU). I have heard the new
    	V2 Firefox server is much faster than my crufty old fieldtest
    	version. I only got about 12 frames a sec, same as on a VS3500.

    	You have 768x800x4x30 which comes out at about 9 megabytes if
    	I did my sums right. I seem to remember the Firefox has about
    	8.5 meg of offscreen memory (2048x2048x24/8 total memory, of
    	which 1280x1024x24/8 is onscreen) so you look to be just over
    	the limit (remember other people, such as DECterm, need pixmaps).
    	If you allocate a 24 deep 768x800 pixmap, and create a 768x800x8
    	window, you can pile up 6 of your 4-bit images in the pixmap
    	and then CopyPlane them back out. Note that if you can't get
    	ALL of your sequence in offscreen memory then you need a different
    	strategy as the server will page your pixmaps in and out of
    	VAX memory and you get thrashing. Your program can probably load
    	the images faster than letting the server try to figure it out.
    
    	If you need to go from host memory into the framebuffer (and
    	you don't need VMS) then you could try experimenting with the PMAX.
    	It doesn't like 4-bit images (all that XORing) but goes quite
    	fast with 8-deep images, although you would not get anything like
    	30 frames a second (maybe around 7-10 maximum?) with 768x800 images
    	from host memory.
    
    Regards,
    Paul Tallett,
    CEC Karlsruhe

    Thanks for all the replies.
    It sounds like this way well be possible with a bit of effort.
    
    Mike

    Also the Firefox has support for hardware double buffering, but you've 
    got to set a few logicals to get it turned on.

RE:<<< Note 1390.10 by IO::MCCARTNEY "James T. McCartney III - DTN 381-2244 ZK02-2/N24" >>>
                    -< Firefox has hardware double buffering. >-

>>    Also the Firefox has support for hardware double buffering, but you've 
>>    got to set a few logicals to get it turned on.

  Not quite.

  I think you are refering to a PHIGS capability.  PHIGS with WSTYPE of 221
can make use of double-buffering by either a logical or an ESCAPE call.

  Double-buffering is the process of drawing to an off-screen pixmap (window)
and then copying the off-screen area to on-screen memory.  When this happens
fast enough the effect is smooth graphics/animation.

  The client is responsible for 'double-buffering'.

  Double-buffering is somewhat related to backing store in which the server
would do the work of 'fixing' exposed areas.

  Currently our server does not support backing store.

					-=> Jim <=-