Slow animation of a lot of data

[AussieDave]

As we can see, the modelling doesn't change in speed much but the animation gets significantly slower. This is with the bitmaps prescaled and the background image on. I haven't changed the code to use a picture box yet.

[AussieDave]

@ NT

Yep, I'll do that next.

[AussieDave]

Okay, I'm finally back working on this. After NT fixed another issue I had (thanks heaps!) I am now back to checking the animation speed.

So far I have made the change to doing the animation on a picture box, not on a form. Changing the code for it was very simple. To be honest, I reckon it's actually performing slightly worse now. I haven't tested how the animation "decays" yet but it seems as though it is a bit...jerky, right from the start. It just jerks here and there, not consistently. When animating on the form it would be very smooth at the start.

[AussieDave]

I'm testing the "decay" now. The stutter that is present when viewing the stuff in a picture box, not the form, isn't consistent or very prominent but it is noticable.

[AussieDave]

Okay, it decays just as much when using the picture box. Next on the agenda is to test different aspects of the code to ifind where the delay is coming from!

[AussieDave]

Okay, I have done a little test.

I counted the time taken to run all of the stuff in the picturebox.paint routine. It consistently takes 0.016 seconds with very little variation and no decay whatsoever. Something else must be the cause!

[Milk]

I imagine your program should be structured like this...

Model --> Buffer --> Animation

The Model should only be concerned with the moment, i.e. current positions and other attributes of the particles.

The Animation should only be concerned the positions of the particles at a particular timeslice.

The Buffer stores all the positions of every timeslice and therefore grows as the model runs.

The most likely culprit of the slow down is the Buffer.

[AussieDave]

Hey Milk, thanks for the reply.

My only reason to doubt your suggestion is one of the tests I ran. I ran the model for a large amount of steps and stored everything into memory, so a huge buffer if you will.

I then stopped the modelling and ran the animation. It was fast at the start and then "decayed".

Maybe the computer finds it easier accessing data at the front of a very long array than at the end? That seems a bit weird though.

[NickThissen]

The fact that the Paint routine speed doesn't decay doesn't mean the problem is not with the painting. The problem I am talking about, and have been talking about since the start of the thread, is that you are simply drawing too much to the screen. The code to do that doesn't take long, but the actual drawing does!
Still, without seeing all your code I can't say much.

[Milk]

Fair enough observation, the computer does not find it easier to access from the front of an array (elementaddress = baseaddress + elementsize * index). It could still be the buffer that is culprit.

Can you show us how the buffer is structured and the code where the Animation part extracts the appropriate timeslice data?

Edit: Nick, I'm seeing the animation part as a trivial amount of drawing. 50 icon sized bitmaps? Something is very wrong if that is taking a long time to render. I had a play at the weekend animating a gravity model of 1000 particles with trails (like little comets) and it ran happily at 30 fps in a window of 1024x1024, the animation included over 1000000 per pixel calculations per frame (for the fading trails). This is on a 7 year old pentium.

[AussieDave]

@NT: I debate that too much stuff is being drawn on the screen because there are only every 50-100 atoms. You say that the code to do it doesn't take too long but the drawing does. If I set a start time at the top of the OnPaint routine and then a finish time at the end of it, and then print it to a log, does that interval not contain all of the drawing? Does the drawing instead get passed to a seperate thread perhaps and gets done in its own time?

@ Milk. The buffer is very simple. The model runs and outputs all of the positions at all time into some arrays. I wouldn't even call it a buffer, it just contains everything. The animation can start at any time and just plots what is available. The modelling is faster than the animation except when the animation is set to a very high speed (I can set it to only animate the nth step if needed) so there normally isn't an issue of running out of data to animate.

[NickThissen]

@NT: I debate that too much stuff is being drawn on the screen because there are only every 50-100 atoms. You say that the code to do it doesn't take too long but the drawing does. If I set a start time at the top of the OnPaint routine and then a finish time at the end of it, and then print it to a log, does that interval not contain all of the drawing? Does the drawing instead get passed to a seperate thread perhaps and gets done in its own time?

As far as I understand it, and that might not be 100% correct, the code in the Paint routine (code such as Graphics.DrawEllipse, DrawLine, etc) merely instructs the control what to paint. The painting itself is done by windows I guess.
There are 'only 50-100 atoms', true, but there are 50-100 atoms per time step. If yuo're doing everything correctly, you should only be drawing 50-100 atoms at a time. If you're not, you might be drawing an EXTRA 50-100 atoms every time step, resulting in 50-100-150-200-250-300-350, etc, and this number rises very fast.

Again, without seeing yuor code there is no way to tell, but I think it could explain why it is slowing down.

[AussieDave]

I appreciate that having every atom at every time step eventually being added to the page would slow things down but I can guaruntee that there are only every 50 or so at a time.

Not going to lie, I'm very tempted to say "**** it" to the whole thing and go with some graphics-based rendering like Open GL. Our model is currently in 2D but a 3D version could be easily made. Unfortunately I know nothing about anything other than GDI+, and I probably should fix this issue first.

[NickThissen]

I'm sure if you posted some code we can help you further. Without code it's just impossible. I can understand you're not allowed to post the model code but just post what you can. You can leave out the details if you are confident they don't matter.

[Milk]

Agreed, without showing us the code you will only get speculative answers.

[AussieDave]

Here is my attempt at posting the relevant code. It's just so big that it's not an easy task! The RunModel() routine is run over and over in a background thread.


Private Sub wrkModel_DoWork(ByVal sender As System.Object, ByVal e As System.ComponentModel.DoWorkEventArgs) Handles wrkModel.DoWork
Do While RunModel = True
RunModel()
If RunModel = False Then
wrkModel.CancelAsync()
End If
Loop
End Sub

Public Sub RunModel()
'run all of the model stuff here
'append the positions of each atom to the position vectors
timestep += 1
End Sub


That's basically how the modelling aspect works. For animation I have:


Private Sub timAnimate_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles timAnimate.Tick
ShowAnimation()
CurrentAnimationStep += AnimationSpeed 'AnimationSpeed = 1 by default
End Sub

Public Sub ShowAnimation()
PictureBox.invalidate()
End Sub


And in the OnPaint routine I have:


For i = 0 To NumberOfAtoms
intXposition = XOffset + ConvertScale(AnimationPositions(CurrentAnimationStep).X(i), "X") - 12
intYposition = YOffset + ConvertScale(AnimationPositions(CurrentAnimationStep).Y(i), "Y") - 12
e.Graphics.DrawImage(AtomGraphics, intXposition, intYposition)
Next

[AussieDave]

Hmm, the code seems to have come out looking rather red and ugly. Hopefully it is still readable though. It is such a long program but I hope I have pulled out the important bits.

The ConvertScale function is just used to convert the position of the atom from the model into a pixel coordinate to be drawn.

[NickThissen]

I wonder if the fact that you're drawing images could cause this, perhaps you're generating the image again and again (maybe not you but the program behind the scenes). Could you try replacing DrawImage with a simple DrawEllipse (or FillEllipse) to draw a circle?

[AussieDave]

I'll give that a shot.

[AussieDave]

The same decay occurs when using ellipses instead of bitmaps.