Greenfoot itself limits the drawing to a certain number of frames-per-second (about 75 I think). Maybe the problem is that you're trying to draw the image too often (every act).

I am not sure why you are using Jpanel. I would use And then just draw onto that using a single graphics2d object.

@davmac Well if that is the problem I will have to draw less images. May only every second or third act. I'll try to fix it different but if I don't find another way I'll use less images. Thanks. @MatheMagican Now that you say it ... I haven't got any idea why I dont' use this method. The simplest things are almost the last that I think of. But I don't get what you mean by "draw onto that using a single graphics2d object". I think the problem is that I have to draw the whole picture onto a buffering JPanel. I use this panels to have a buffer for all these images I have to draw (one every act). Anyway, thanks for the advice.

@davmac You said Greenfoot would draw about 75 frames per second. How do you do this??? I'm only able to draw much less images (about 20 fps). Is it just that I haven't got enough RAM or am I doing something wrong? I'm currently trying to draw the images on 5 buffering JPanels and seting them as the content panel of my full screen frame. No matter what I do it doesn't seem to be possible to me to have more than about 20 fps. But maybe there is a better way to handel this.

What exactly is the purpose of having 5 JPanels? Regardless of how many frames you're buffering, you still have to do just as much rendering. To limit the rate, I tried this in my world class, which seemed to work fine: On linux, setContentPane appears to have no effect on a full screen window (possibly this is a Java bug), so using multiple JPanels as buffers actually reduces the number of frames you see rendered to the full screen window.

The purpose of the 5 panels is that I can show the first while drawing on the second ... So I don't have to wait for the image that is drawn, displayed, cleared, drawn again, ... Without using these buffers I have bugs while displaying the images (sometimes just an empty panel). When I use multybuffering there are less bugs. I also tried to lime the rate of images that are drawn using an fps variable: But still it doesn't realy look like a animation. It's still buggy. I'm currently not working on my computer but on a laptop (which is not realy the fastest one) so maybe I just haven't got enought RAM or CPU for a better animation. I'll go on working on this problem. Maybe I'll find a better way. But to me it would be very interesting how greenfoot itselves draws 75 frames per second. Is there any trick I don't know? I'm currently trying double buffering and multithreating which are the only tricks for doing this I know.

I've double-checked and the maximum frame rate in Greenfoot is 65fps. The relevant code is in the Simulation class (greenfoot.core.Simulation), if you want to look at the source code it is available from the download section of the site, although I'm not really sure if you'd understand it. There's no magic to drawing this many frames. Greenfoot just requests repaints for the world only (a maximum of) 65 times per second. Repaint requests are issued from the simulation thread, actual painting always occurs on the Swing Event Dispatch Thread (EDT) and the code for that is in WorldCanvas class. When the repaint is requested in Simulation, paintPending is set to true; when the repaint actually occurs it is set back to false. This is used to monitor the actual repaint rate. See the repaintIfNeeded() method in Simulation. Note, this doesn't guarantee 65 frames per second, but I'm pretty sure on most machines that it can achieve close to this rate.

I now improved my code so that about 25 fps work without any bugs. But I think I must be able to make it work even better. Thanks for all these advices davmac but I can't find a API or the source code for greenfoot.core.Simulation. Where exactly is it to be found?

I think I now got the mayor part but there are still a fiew things I need help. First: Does Greenfoot know when it's frame is not activated or even not visible? When I try to hide the greenfoot frame using setVisible(false) the execution seems to stop. Second: When I try exporting the scenario to an executable jar file it doesn't work because I don't even have a world. There only is the application frame without any worlds and so my fullscreen window also has no image. Could the problem be that my world subclass (FullScreenWorld) is a abstract one? Or are there other known reasons that can cause this problem?

Well, it doesn't specifically check for that; but if the frame is invisible, it won't be repainted, and repaint algorithm might stall then. If your only world class is abstract, then yes, you won't be able to export.

Ok so hiding the greenfoot frame will probably not work. To the abstract world class: It's not the only class but the only direct subclass of greenfoot.World. All other classes are subclasses of this class and not directly subclasses from greenfoot.World. (May there also is a problem with an older greenfoot version. I'm currently working with 2.2.1. May that be a problem?)

It doesn't matter if the other classes are indirect subclasses of World, that should still be ok. Greenfoot 2.2.1 was fairly stable so I don't think there's an issue there.

I've double-checked the code, and I don't think making the frame invisible should cause the simulation to stop running (at least with Greenfoot 2.3.0). Maybe there is something wrong with your code.

Well I'm not quite shure if the whole application stopps running. But my fullscreenframe does. Maybe greenfoot still runns but doesn't paint the world. Or like you said my coding was wrong. These are the methods I used: To the exporting problem: Well I'll try some things to fix this problem. May I find a way.