GIF animation problem
Mark.Powell at veritas.com
Fri Nov 7 16:35:06 EST 2003
Have you ever seen animated GIFs overlap in any other environment?
Without having tried anything like this in the past, I'd say this is the
behavior that I would expect. If two animated GIFs (or any other kind of
motion graphic) were attempting to occupy common pixels within the same
window, it seems that the OS would understandably protest. That one button
is masked behind the other perhaps doesn't "insulate" them in the same way
as if they were on different windows. I am only guessing.
If you want to have them both animate, maybe you'd have to somehow have them
within different windows so that dragging them around is not actually
dragging the icon, but dragging a stack window (the rect of the window
equalling the rect of the button, perhaps? Aargh). Another option may be
to test for overlapping and set the icon of the lower button to a static
image. Yet another option maybe to animate context-sensitive cursors while
dragging, instead of animating icons. All of these ideas are pretty
nightmarish, but it is the best I can think of, apart from abandoning
animation all together. Are you sure there is a compelling benefit in
trying to animate like this?
From: Graham Samuel [mailto:livfoss at blueyonder.co.uk]
Sent: Friday, November 07, 2003 1:13 PM
To: Revolution user discussion
Subject: Re: GIF animation problem
At 12:30 +0000 6/11/03, I wrote:
>In an app that is in an advanced state of testing, I have a couple
>of transparent buttons each of which has an icon which itself is an
[...] I didn't say clearly that the user is allowed to drag these
buttons around the screen.
>This generally works extremely well, but my beta tester has pointed
>out that just one of these animations stops working as soon as its
>border overlaps with the other one. It doesn't seem to mind
>overlapping with other, static, controls (images and grcs).
I have tried all sorts of stuff now, such as changing the size of the
GIFs, taking away other graphics and images, etc, but the phenomenon
continues. It seems that the GIF with the most frames is the one
which stops moving, while the one with less frames continues to
animate: if both have the same number of frames, or are derived from
the same image, then both stop. It doesn't seem to be an issue of the
relative level (layer) of each GIF, and the problem shows up in
I am now totally stuck - the only thing I can think of doing is to
rearrange the entire screen so that the buttons don't have to
overlap. It does begin to look like a bug in the engine's
GIF-animating routine (I guess it must have one).
Still hoping for some help.
Graham Samuel / The Living Fossil Co. / UK & France
use-revolution mailing list
use-revolution at lists.runrev.com
More information about the Use-livecode