nanogui: Thread: [nannogui] fast updating of (background) images

Hi all
We want to develop a kind of slideshow using nano-x. This slideshow must
refresh large background images a number of times, and we have problems
getting this done at a reasonable speed. 

At present we use GrLoadImageFromFile() to load an image into a GR_IMAGE_ID.
When updates are neded we use a call 
GrDrawImageToFit() to put the image onto the screen. The updating gets to be
very slow - line by line - and we don't have the possibility of just
updating the relevant part of the screen.

We have tried using GrCopyArea to move the image onto the screen from the
GR_IMAGE_ID. This call seems like it should do exactly what we want: copy a
rectangular piece of an image onto the appropriate place in an other window.
Howeever, it seems that we can only copy images from a mapped window on the
screen i.e. we can not copy from an off screen imagebuffer onto the screen
using GrCopyArea. 
Does anybody have experience with this problem - should GRCopyAre be able to
move images from offscreen locations to the screen - or is there an other
way to do the job of fast updating the screen.

It also seems that the basic drawing onto the screen using GrDrawImageToFit
clips around sibling windows. This may be nice - giving flicker free updates
when windows overlap. Since we are using windows that do not fill their
background color we need to draw images without clipping around the siblings
how can this be done? 

Our slideshow must also display animations - we would like to use animated
GIFs is that possible? - if not, we expect to do the animations by ourselves
- but then we need fast updating.

Finally a related problem. We are using several windows displaying texts,
again with no background drawn. We want to unmap some of these textwindows
and at the same time map other textwindows (displaying changes with mouse
over) We can manage to get this to function against a general background -
but when we unmap one window and map an other window and the two windows
intersect then the intersection of the two windows doesn´t get updated the
way we would like. It seems that the windows engine looks ahead and ony
updates the intersection once - can this look ahead function be controlled
in any way?


> Ib Jørgensen  Lead Technical Consultant
> --------------------------------------------------------------
> AGENCY.COM Interactive TV
> 
> Islands Brygge 57, DK 2300 Copenhagen S
> T: +45 36 93 60 00  F: +45 36 93 30 01  
> Direct: +45 36 93 60 88 
> E: ####@####.####  www.agency.com
> 
> 

See below for my comments:

> We have tried using GrCopyArea to move the image onto the screen from the
> GR_IMAGE_ID. This call seems like it should do exactly what we want: copy a
> rectangular piece of an image onto the appropriate place in an other
> window. Howeever, it seems that we can only copy images from a mapped
> window on the screen i.e. we can not copy from an off screen imagebuffer
> onto the screen using GrCopyArea.
> Does anybody have experience with this problem - should GRCopyAre be able
> to move images from offscreen locations to the screen - or is there an
> other way to do the job of fast updating the screen.

A GR_IMAGE_ID is not an offscreen imagebuffer (ie, the memory is not arranged 
as a "screen" of pixels),  it simply an index to a structure that holds all 
the image information (palette, size, data, etc, etc...).  What you want is a 
pixmap (an offscreen drawable), which you can then use with GrCopyArea() to 
get the proper effect.

Something like this (obviously psuedocode, check the documentation for the 
right parameters):

image = GrLoadImageFromFile(foo.gif);
pixmap = GrNewPixmap(image_width, image_height, 0);

GrDrawImageToFit(pixmap, gc, 0, 0, -1, -1, image);

while(something) do_something_else;
GrCopyArea(window, gc, 0, 0, image_width, image_height, pixmap, 0, 0);

> It also seems that the basic drawing onto the screen using GrDrawImageToFit
> clips around sibling windows. This may be nice - giving flicker free
> updates when windows overlap. Since we are using windows that do not fill
> their background color we need to draw images without clipping around the
> siblings how can this be done?

Whenever you have two overlapping windows (or a parent window with one or 
more children), the contents will be clipped to fit within their visible 
area.   This is one of the side effects of having multiple windows. 

But if I read you correctly, it seems that you want "transparent" windows 
that show any visible contents of the window below it.    At this point in 
time, this is not possible, mainly because we don't maintain a Z-order 
anywhere, and the drawing could get a little sticky (trust me - Greg and I 
have had more than one discussion on this issue.. :) )

> Our slideshow must also display animations - we would like to use animated
> GIFs is that possible? - if not, we expect to do the animations by
> ourselves - but then we need fast updating.

No animated GIFs, but if you use the GrCopyArea scheme above, then you can do 
the animation yourself with little trouble (we do the same thing for the 
throbber on ViewML).

 Finally a related problem. We are using several windows displaying texts,
> again with no background drawn. We want to unmap some of these textwindows
> and at the same time map other textwindows (displaying changes with mouse
> over) We can manage to get this to function against a general background -
> but when we unmap one window and map an other window and the two windows
> intersect then the intersection of the two windows doesn´t get updated the
> way we would like. It seems that the windows engine looks ahead and only
> updates the intersection once - can this look ahead function be controlled
> in any way?

I don't understand.  Could you give us some psuedo code to show us what you 
are dealing with?

Jordan

> It also seems that the basic drawing onto the screen using GrDrawImageToFit
> clips around sibling windows. This may be nice - giving flicker free
> updates when windows overlap. Since we are using windows that do not fill
> their background color we need to draw images without clipping around the
> siblings how can this be done?

: Whenever you have two overlapping windows (or a parent window with one or
more children), the contents will be clipped to fit within their visible
area.   This is one of the side effects of having multiple windows.

: But if I read you correctly, it seems that you want "transparent" windows
that show any visible contents of the window below it.    At this point in
time, this is not possible, mainly because we don't maintain a Z-order
anywhere, and the drawing could get a little sticky (trust me - Greg and I
have had more than one discussion on this issue.. :) )


No - this is incorrect.  A Z-order list is maintained.  The only issue is
that there isn't a "transparent" bit implemented that basically says to
the clipping routines to ignore this window.

There is the concept of an input-only window, which acts exactly as
wanted, except, alas, drawing isn't allowed!  Another option that
might work for you would be to set the GR_PROPS_NOBACKGROUND
property on the window, this will prevent nano-X from drawing a background
when updating exposed areas.


> Our slideshow must also display animations - we would like to use animated
> GIFs is that possible? - if not, we expect to do the animations by
> ourselves - but then we need fast updating.

I haven't implemented animated gifs yet - but they're not that hard.  Basically,
an animated gif is just a sequence of gif's decoded from the same file,
with a known timeout and x,y offset between images.

> Finally a related problem. We are using several windows displaying texts,
> again with no background drawn. We want to unmap some of these textwindows
> and at the same time map other textwindows (displaying changes with mouse
> over) We can manage to get this to function against a general background -
> but when we unmap one window and map an other window and the two windows
> intersect then the intersection of the two windows doesn´t get updated the
> way we would like. It seems that the windows engine looks ahead and only
> updates the intersection once - can this look ahead function be controlled
> in any way?

The window update engine "looks ahead" to determine the outermost
window, and only that window is updated, rather than, say, a partially
obscured window complete contents.  If this were not this way, then
all obscured portions of visible windows would flicker until the topmost
window contents were finally drawn.

It sounds like what you're looking for is perhaps the nano-X equivalent
of win32's BeginDeferWindowPosition - which allows several map/unmaps
to take place without any window system updates to take place until
EndDeferWindowPosition is called.

Regards,

Greg