nanogui: [nannogui] fast updating of (background) images
Subject:
Re: [nanogui] [nannogui] fast updating of (background) images
From:
"Greg Haerr" ####@####.####
Date:
9 Aug 2001 15:41:27 -0000
Message-Id: <04b901c120e9$6ab4ff00$3aba46a6@xmission.com>
> 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
