The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

What makes an animated gif animate?

I'm displaying an animated gif the start of a CPU intensive process. It animates briefly and then stops while the CPU intensive process does its stuff.

I was under the misguided impression that it would keep animating, regardless of what the CPU was doing, as I assumed the animation itself would be handled by the video card/system.

Can anyone shed any light on this, and offer any tips on how I might be able to keep the animation alive?
Neville Franks Send private email
Sunday, June 15, 2008
 
 
Obviously no way to assure it with a gif.

gif progress bars are stupid anyway. Make a real progress meter with a callback. That is, your worker process calls updateBar(double percent), and that re-draws the picture.
my name is here
Sunday, June 15, 2008
 
 
I think it must depend entirely on what is rendering that gif.  Since gif is just a file format that contains frames, some software is reading and displaying the frames.  I would assume it's not the video card.

I have an AVI that plays via a control on an MFC dialog.  Interestingly the AVI plays great, but if I lock the workstation, it stops playing, and when I unlock it's paused for a few seconds until it starts playing again.  I'm assuming the control/MFC detect whether the window is visible so it knows whether to render or not.
Doug
Sunday, June 15, 2008
 
 
If you're using Java, the rendering thread also takes care of animating gifs.  The correct way to handle this problem is to never do any computationally intensive processing in the GUI thread.  Spawn a new one that takes care of the processing and have it call back to the GUI thread.
Steve Moyer Send private email
Sunday, June 15, 2008
 
 
Re. the java advice.

True, you shouldn't put any real tasks in the EDT (the event handling thread which also does the rendering). But the EDT has to contend for CPU cycles just like any other thread. So for example, if your task-in-a-separate-thread is CPU-heavy and there's only a single processor, the animated gif may still not be displayed smoothly.

You can see this in Trace Modeler when you export a large diagram as a bitmap. The export itself is done in a separate thread, during which an animated gif is shown (to indicate the program is busy). You may notice it will sometimes skip a few frames.
Yanic Inghelbrecht Send private email
Sunday, June 15, 2008
 
 
Thanks for the replies so far. This is a C++ MFC Desktop which uses the MSHTML control. The animated gif is part of the HTML content. It is made visible and then more HTML content gets added. You can see the effect on sites like http://www.dzone.com when you scroll to the bottom of the page. I think this is a very effect user feedback mechanism.

I can't do anything useful in a separate thread in this specific case, as far as updating the HTML content. I'll probably end up putting a progress control on the status bar which is updated by a background thread.

That's said I'm simply trying to get an understanding of who is doing the video update with animated gif's.
Neville Franks Send private email
Sunday, June 15, 2008
 
 
If you are using the mshtml control then isn't it  internet explorer doing the rendering?
Martin Send private email
Sunday, June 15, 2008
 
 
>If you are using the mshtml control then isn't it  internet explorer doing the rendering?

Yes it is.
Neville Franks Send private email
Sunday, June 15, 2008
 
 
Well, it isn't at all unusual for a bitmap to reside in main system memory as a DIBSection, which will require the CPU to access it and send it to the video card for rendering.

That's actually a very common usage pattern because it is much easier for regular program code to access the bitmap bits and modify them with that type of structure.

Also if you're running under Vista, all of the old-style GDI 2D hardware acceleration was actually removed in Vista so you'll see more CPU use for sort of classic 2D only GDI operations over there.

So it isn't generally surprising or unexpected at all that old style 2D graphics work will involve a bunch of CPU activity and won't happen so much directly on the video card like 3D graphics tends to.
Michael
Sunday, June 15, 2008
 
 
>> It animates briefly and then stops while the CPU intensive process does its stuff. <<

If the CPU is busy doing other things, how can it show the next frame in your gif?

You could do something like make the thread the gif is being animated on higher priority (make your worker process a lower-priority thread, really) but that's just a hack.
xampl
Sunday, June 15, 2008
 
 
Likely an animated gif render implements its animation behavior using a timer. It asks Windows to send a WM_TIMER message at certain interval. To achieve animated behavior, the thread should not enter long processing, otherwise the message loop is blocked and the render routine does not have a chance to process the message.

If the thread must do some processing that takes long time to finish, in the process routine the program needs to check if message is available in the loop, and dispatch the message to the handler from time to time. A typical implement is like below:

this_process_takes_a_lot_of_time()
{
  for(;;) {
      ..do some processing...
      while( PeekMessage( &stMsg, hWnd_i, 0, 0, PM_REMOVE ))
  {
      TranslateMessage( &stMsg );
      DispatchMessage( &stMsg );
    }
  }
}
Glitch
Monday, June 16, 2008
 
 
> You can see the effect on sites like http://www.dzone.com
> when you scroll to the bottom of the page.

If the stinkin' browser can do it, why can't your app? It is probably an AJAX thing.
coder
Monday, June 16, 2008
 
 
>> You can see the effect on sites like http://www.dzone.com
>> when you scroll to the bottom of the page.

> If the stinkin' browser can do it, why can't your app? It
> is probably an AJAX thing.

This works because it does an Ajax call as you suggest and while it is waiting for the content to be sent back down the wire the Browser and CPU are idle and the GIF gets animated. As soon as the data arrives the animation stops while the content is added to the page.

In my case there is no delay waiting for the content to come back from the server, but it may take some time to add the content and have it displayed. It is during this period I want to let the user know the application is busy.
Neville Franks Send private email
Monday, June 16, 2008
 
 
> I can't do anything useful in a separate thread in this specific case...

if this is true (?) the options are probably limited to 2:
- lots of Application.DoEvents()
- ritual suicide
boo
Tuesday, June 17, 2008
 
 
[Michael : Also if you're running under Vista, all of the old-style GDI 2D hardware acceleration was actually removed in Vista so you'll see more CPU use for sort of classic 2D only GDI operations over there.]


Me:
That's pretty disappointing to hear because I just finished a 2D game on DirectDraw. Don't know why MSFT is downgrading 2D graphics because it really is a very important application area (not everything requires 3D - eg. plans, aerial views, side views, etc).
Ezani
Thursday, June 19, 2008
 
 
The point of downgrading 2D is that it is just a simplified case of 3D and the new 3D hardware is now faster than the old 2D stuff used to be anyway. So it is faster/easier to just use one model (3D) for both 2D and 3D stuff instead of trying to support two different models and having to figure out a way to handle the context switch.
2D is dead to me
Saturday, June 21, 2008
 
 
[Michael : Also if you're running under Vista, all of the old-style GDI 2D hardware acceleration was actually removed in Vista so you'll see more CPU use for sort of classic 2D only GDI operations over there.]


[Ezani:
That's pretty disappointing to hear because I just finished a 2D game on DirectDraw. Don't know why MSFT is downgrading 2D graphics because it really is a very important application area (not everything requires 3D - eg. plans, aerial views, side views, etc).]

He said GDI, not DirectDraw. And IIRC DirectDraw was removed back in DirectX 8. With newer versions I think you're expected to do 2D with Direct3D textures etc on a 2D plane with overhead camera. That or use/write a wrapper/framework that does that for you.

Or you can use WPF if approprate.

GDI acceleration was removed so the Vista graphics system could render GDI graphics to a texture that could then be composited by the new Direct3D-based Display Window Manager
Chris Altmann
Tuesday, June 24, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz