java_arguments for applets on OS X problem

Newbie & Debugging Questions
#1

I pass -Xmx256m as java_arguments to the applet. That works fine on all systems, except on OS X.
Most poor apple users have versions below update10 - I know that it does not work there - but what about the other lucky 10% who have a higher Java version?
I searched a lot and did not find a solution. Then there is the mighty Minecraft. The java_arguments of the applet tag for Markus’ game look pretty similiar to mine (except that there is a capital M used: -Xmx800M, I tried that too: fail).
Or has an applet to be signed on OS X to profit from java_arguments ?

bonus question:
why is java performance so overwhelmingly crippled on OS X (no, I don’t use LWJGL) ?

#2

sorry to BUMP :persecutioncomplex:
but I’m helpless.
Can someone tell me why OS X ignores my -Xmx?
Mac users of the world! please click my sig and press F2, this shows the used and maximum ram.
On Win&Linux max is about 247, OS X 's max is at most about 90 (I think the default value)

#3

its my understanding (could be wrong) that only the java plugin2 support jvm arguments. On mac you need to enable java plugin2 by selecting out of process applets from the java control panel.

However for java plugin1 apple have backported some features to allow stuff like javafx to work, however I’m not sure if the jvm argument support was also backported, its unlikely it was.

By default (atm) safari and firefox use the java plugin1 (unless changed in the java control panel) and chrome uses (and only supports) java plugin2.

Apple have also recently crippled java performance on mac (when using java plugin2), this was done as they are trying to better integrate java applets with the web page, to allow other html stuff to overlap the applets they render the graphics offscreen and then draw it using their own CoreGraphics api. This does make the applets fit better but kills performance. You can read more about it in the change log here, this change not only crippled java applets performance (including stuff like pulpcore) but also broke lwjgl and jogl applets.

#4

Wow, thanks a lot kapta.
That makes me feel like this guy:

Seems like the only solution is a webstart link for apple boys?

#5

could also try a pop out JFrame if you still want to use applet.

#6

But that gives me no jvm arguments (I need more ram)

#7

Well surely your game can’t be using that much ram (or need to) at any one given time. Maybe you can optimise it to unload resources that are no longer needed for a certain level and reload them when needed or other tricks to make it use less ram.

There is always the secret method to store an unlimited amount of stuff in ram with applets (i.e. no limit) using the AppletContext.(set/get)Stream method, however not sure it’ll be useful enough for realtime, might work if you switch stuff between levels though (credit to Riven for discovering this).

#8

I was laughing tears

#9

There is not much to do about the ram usage. 85% are used in int[], there is a rather high fix cost in my engine. One 960600 image takes up 2,25m and I use several of them as buffers plus the model data. Each level all the images for the entities are re-rendered (because of different resolutions of the levels) and discarded afterward. Maximum used ram after gc’ing is about 45m. I produce extreme amounts of garbage e.g. 42.25m for blurring the channels of a pic, but it runs smoothly with about 70m. I could rewrite lots of stuff to use less ram but it is just not worth it. 100m or even 256m is nothing today (my Eclipse atm uses 400m). On macs - I don’t know what is happening there - the game crashes even with 90m available. I don’t have a mac to profile what is going on there, so I just keep hating macs :slight_smile:

#10

Hi, I do a bit of applet Dev on Mac (snow leopard).

A few notes that I have found.

while loops are EVIL!!!. try use “for” instead when it is most logical.
if you use a small while loop (calculation time) you will need to make a call to Thread.sleep(1); to prevent your applet from using 100% of a single CPU.
this can still happen with for loops, yet i find its less likely.

BufferedImage (maybe Image aswell) doesnt release itself from ram (yet it isnt classified as a memory leek).
instead of creating a whole new BufferedImage, try use setData(raster) instead.

Im not sure if this is also true for 32bit java

#11

this would explain a lot. But what do you do if [all] images have different sizes? I need a mac…