Application.Rai seIdle

[=?Utf-8?B?Sm9uIEphY29icw==?=]

In VB I am doing an animation via Application.Idl e.

My idle routine is:
Private Sub Form1_Idle(ByVa l sender As System.Object, ByVal e As
System.EventArg s)
Draw()
Application.Rai seIdle(e)
End Sub

I use RaiseIdle so I don't just draw one frame and wait until I wiggle the
mouse or something so it can go back to idle.

The animation is very smooth, and I get about a 1000 frames per second (fps)
This works for a while, but my application is very unresponsive and quits
after about a minute. If I run in the IDE, it quits in only 5 seconds or so.

If I add Application.DoE vents right after Draw, the app is very responsive,
but I get a stack overflow.

How do I avoid these problems?

Thanks,
Jon

[Israel]

I'm not familar with the RaiseIdle() method but it doesn't sound like
the right place to put animation code. What if the user were moving
the mouse around or clicking on the window - wouldn't that make the
idle even called less? Also it sounds like the DoEvents() is
synchronously calling your Idle method and if you're then calling
DoEvents() within then you get into circular loop.
Why not use a timer? You can probably get 30 fps reliably enough with
that. 1000 fps is pretty rediculous since a human probably can't even
see anything beyond 50 or 60 if even that.
I'm not sure how your animation is generated but you could use another
thread to create frames at some constant and reliable rate (since the
timer thread is lower priority) and then use the timer events just to
display the "correct" frame for that time.

If you really want to do more sophisticated animation you'll probably
need to use directX.

[=?Utf-8?B?Sm9uIEphY29icw==?=]

I'm not familar with the RaiseIdle() method but it doesn't sound like

the right place to put animation code. What if the user were moving

In other environments the Idle event has been the recommended place to put
the animation code, but apparently, in the .Net environment, the way it is
implemented is problematic.

the mouse around or clicking on the window - wouldn't that make the
idle even called less?

Yes, that has an impact, slowing me down to 920 fps. Not bad at all.

Why not use a timer? You can probably get 30 fps reliably enough with
that. 1000 fps is pretty rediculous since a human probably can't even
see anything beyond 50 or 60 if even that.

Timers have other issues with respect to this kind of graphics. What I've
read recommends against them.

I'm not sure how your animation is generated but you could use another
thread to create frames at some constant and reliable rate (since the

Also gotchas when doing this with other threads, according to what I've read.
I use logic in the image generaion so the motion maintains proper speed in
spite of changing fps.

If you really want to do more sophisticated animation you'll probably
need to use directX.

I've been doing very sophisticated animation with OpenGL in other
programming environments. Now I am trying to port it into VB.NET. Just trying
to work through the issues for this particular programming environment.

Thanks,
Jon

[Israel]

On May 30, 4:17*pm, Jon Jacobs <JonJac...@disc ussions.microso ft.com>
wrote:

I'm not sure how your animation is generated but you could use another
thread to create frames at some constant and reliable rate (since the

Also gotchas when doing this with other threads, according to what I've read.
I use logic in the image generaion so the motion maintains proper speed in
spite of changing fps.

I guess that's sort of what I meant but I didn't know how you
generated the frames e.g. if your animation routine is a function of
an iterator you could keep a buffer of generated timestamped frames
and then when the timer comes back lookup the closest frame based on
the current time. Or your animation routine is a function of time, so
given an arbitrary time generate the appropriate frame.

I've been doing very sophisticated animation with OpenGL in other
programming environments. Now I am trying to port it into VB.NET. Just trying
to work through the issues for this particular programming environment.

My only experience with animation is either cheesy little cycling
bitmaps using a timer or writing direct show filters in C++ which is
really more video processing than "animation" except for some simple
diagnostic image sources which had to generate frames from nothing.

[=?Utf-8?B?Sm9uIEphY29icw==?=]

>Or your animation routine is a function of time, so

>given an arbitrary time generate the appropriate frame.

Exactly