Hello.
In OS X 10.6.4, when I play the game in the Unity’s editor window, even “maximized on play” it runs fast, but when I play the same project in the browser window it runs much slower.
If it was related to the OpenGl problems in 10.6 than I suppose both, the editor window and web player would encouter slowdowns. But this is not the case.
Can you post some fix to this ?
Well the webplayer is going to be slower - it has to give time for the web browser itself to handle the web page, manage input events, update scrolling, process javascript, deal with user-interface buttons that are part of the browser itself, and also the rest of the o/s desktop environment has to be updated and managed.
I’ve heard some people say there is a 25fps cap on the webplayer, which I sometimes see, but sometimes I do not see that and get up in the 40-50fps range.
That’s not it.
The Web Player is as fast as the editor, sometimes even faster in the OSX 10.4 for example. In 10.5 it’s also fast, but in 10.6 it’s much slower.
So I presume that this has something to do with the OSX 10.6 support.
Can I do something about that? My first person view suffers heavily in the webplayer and drops from 300 (standalone) to 60 fps using IE8 and FF. 60 fps may not sound bad but it makes a huge difference, I need a superfluid game experience.
Brrr, I’m very afraid of that I can’t prevent this fps drop in a significant way. Would be a shame to abandon the webplayer cause of that 
The editor runs with 70 fps, faster then the browser! That can’t be standard =O
Thats no FPS drop
the webplayer will run at 60fps unless its fullscreen, thats a hardlock. Even if it internally could run at 500 fps
Oh, thanks for the information.
A hardlock is called hardlock cause it can be changed isn’t it? Hmm =(
right, you can’t affect it.
It would not be acceptable without it, cause if you would run at max performance the browser would not get its calculation time it requires with possibility of having the plugin crash and stuff like that.
But as mentioned, go to fullscreen and its no problem, in this case your plugin runs exclusively
Ok, so I will go fullscreen.
I’ve planed to have my game running on fixed 800x600 or a bit bigger, so my menu and other things are pretty well adapted to this size.
Is there a possibility to maintain this size and put a black border/background around it, if the fullscreen resolution is bigger then 800x600? Or better, would that be a “conventional” solution?
You can set the screen size if you want for the case there.
So you could set it to whatever and create a virtual rendering area of 800x600 in the middle.
but you will not find any friends if you make it fullscreen just to piss them off with a game boy sized window, leave it in non fullscreen then.
Yea, of course I will look for an appropriate resolution when running it in fullscreen. Thanks again!
GameBoy Classic would be 160x144 by the way Aaah, old good times 
yes but in relation to the 320x240 standard back then it was large. compared to the standard 1920x1200 or 2560xxxxx its that tiny that you can barely interact with it with a normal gamer mouse 
True true =)
1024x768 should piss no one off I hope! Needless to say that selectable size is the best though.
60 fps would be nice, and totaly anough. But it runs much slower, or it’s just an impression, nevertheless it’s bad.
I have an orbit camera looking around the project and in the webplayer camera moves like it was slowed down, it rotates with a delay, like it was moving in glue. Editor runs just fine though. Here is the problem.
I understand and agree with the 60 fps limit, but now it seams to work as a percentage of performance, not the fps limit. It works like the the top fps, let’s say 240fps=100% of performace, and than, in the webplayer it’s 60fps which equals 25% of performance. It looks like in the browser the game workes four times slower.
Something is not quite right, so I ask the Unity team to see about it.
perhaps your code is just faulty, like you didn’t do it FPS independent and things like that.
You have to code FPS independent as dreamora said.
Moving something FPS independent looks like this for example:
transform.Translate(Vector3.forward * Time.deltaTime);
The “Time.deltaTime” will slow down/speed up the movement so that, at different FPS, you get the same movement speed. More information:
Your code should run the camera at the same speed no matter what your framerate is (if done properly). Make sure you are basing the movement speed off of the elapsed time rather than a fixed amount per update.
Yes, probably this is the problem. Thank you mates.
That’s not it.
The problem is not related to fps independent code.
Besides, this problem does not exist in system 10.4 and 10.5. The same project runs smoothly in the same version of Safari in 10.4 and 10.5. In 10.6 I have slowdowns.
As I said before in all three systems Unity editor runs at fulll speed. Only in 10.6 the web plugin slows down the game.
Therefore I suppose that it has something to do with plugin vs 10.6 support, or the Safari itselve.
Did you update the web plugin since 10.6 was released?
in 10.6 the graphics performance generally is lower.
Also 10.6 has a 64bit plugin, not only a 32bit plugin and there might be some difference between their performance
I’m sorry, but I think you don’t understand, maby because of me being not too precise.
Graphic performance in 10.6 is OK. When I hit play in Unity editor the presentation runs fast, as it should . Than I quit Unity and open the game in the Safari, and the whole presentation slows down.
What is interesting that in FF the presentation runs OK.
So please, take a look at that.
Oh, and I don’t have any browser plugins installed, just pure Safari and FireFox.