I discovered the holy grail, the silver bullet that solves all performance problems.
Some of you will be impressed, others will throw eggs at me for cheating.
Post your sprite count when the demo starts lagging.
http://www.emaggame.com/
(top left button)
Boo!
I let it run up to 205k, and it didnât show any performance degradation.
But⌠when I closed the browser tab, it totally crashed the browser⌠man, I hate the plugin.
timinginfo 138 ms, ready at 11.34 loading: textures textures.txt [kdk.textures.n]
timinginfo 11545 ms, ready at 11.55 simpleinit() [kdk.aa]
java.lang.ClassCastException: sun.awt.image.DataBufferNative cannot be cast to java.awt.image.DataBufferInt
at kdk.bx.n(kAi:404)
at kdk.bq.c(kAi:22)
at kdk.bq.<init>(kAi:65)
at kdk.ak.b(kAi:47)
at kdk.dope.m.setSize(kAi:876)
at kdk.dope.m.<init>(kAi:120)
at kdk.dope.m.<init>(kAi:133)
at kdk.dope.j.<init>(kAi:23)
at kdk.aa.a(kAi:432)
at kdk.bf.start(kAi:184)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
So I think thatâs 0. Additionally I had to kill the browser because it wasnât responding.
Windows Vista QuaCore Q6600 (2,4Ghz) NVidia 8800GT, Java 1.6.0_07-b06
Getting bored after 100 000 ;D
But the applet version didnât work at all⌠nothing in the consol⌠juste de java sun logo.
Very strange⌠maybe the applet issues have something to do with parameters (-Djnlp.packEnabled=true) I pass there, or with some threads I spawn for parallel processing. I will remove both tomorrow.
I know even less about that [quote]java.lang.ClassCastException: sun.awt.image.DataBufferNative cannot be cast to java.awt.image.DataBufferInt
[/quote]
Exception. Is that Linux running some kind of open Java? Mrs Google could not help me.
You should put a FPS counter, it will be better to define when itâs beging to slow down.
Windows XP, Celeron 2,4GHz, Intel 82865G, Java 1.6.0_07-b06 :
It never seems to slowdown.
Must be a nice cheat.
Hm doesnât actually look like 10,000 sprites to meâŚ
Cas 
I think the cheat is that itâs just 5 sprites with about 3 backbuffers that are never cleared.
yes, looks more like 1 billion sprites if you let it run for a week.
here is the pseudocode: (slightly changed, I use rasters of BufferedImages and blit via loops)
Image pic;
Image[] buf;
int width=800,height=600;
int count = 0;
public void init() {
buf = new Image[10];
for (int i = 0; i < buf.length; i++) {
buf[i] = new Image(width,height);
}
pic = somePicture();
}
public void render() {
count++;
getGraphics().drawImage(buf[count % buf.length],0,0,null);
for (int i = 0; i < buf.length; i++) {
float frak = (float) i / buf.length;
float time = (count + frak) / (20f);
int w=width/2;
int h=height/2;
int x=w+(int)(w/2*Math.sin(time));
int y=h+(int)(h/2*Math.sin(time*2.1));
buf[i].getGraphics().drawImage(pic, x, y, null);
}
}
Funny that the applet works now, I did NO update yet. Java is great. 
Yeah, itâs an old trick. Iâm a bit amazed people fall for it.
* Markus_Persson does some palette shifting tricks
Yes, I expected more eggs and booâs
getGraphics().drawImage(buf[count % buf.length],0,0,null);
Please call graphics.dispose() ! Youâre leaking native resources.
donât worry, that was meant as pseudocode. And there is the main function missing. And 42 more things.
[quote=âRiven,post:15,topic:32915â]
Well, not leakingâŚ
[quote=""]
Not the same PC, not the same OS
Hmm⌠good to know, although in theory, you could run out of native resources before the GC is executed, as it doesnât grow the heap - but chances are slim.
Yeah, and itâll probably allocate more ram than needed if you donât dispose() as it has to wait for the gc.