Now this one’s a little wooly - so to speak - but let me start from the beginning.
In our games we’re using swf assets, more precisely vector art. These are proportionally
scaled at runtime to fit the browser window. Well, we noticed that using those directly e.g.
var sprite:Sprite=Assets.getMovieClip(“assets:ID”); greatly reduces the framerate - depending on
the quantity and size of the objects as well as the size of the browser window. The obvious solution was drawing the stuff on individual bitmaps and use those instead of the vectors. (bmpData.draw(sprite)) So now we’re drawing all the vector assets to bitmaps at runtime. This works pretty damn good on Chrome. Unfortunately just Chrome! If we test the game on Firefox, the browser freezes during the vector->bitmap ‘conversion’, followed by an ‘A script on this page may be busy - CANCEL - Continue’ dialog. On chrome the
conversion phase takes maybe 3 seconds.
Obviously FireFox ain’t as fast as Chrome with this Bitmap drawing.
Did anyone else run into this problem?
The only workaround I can think of at the moment is adding a timeout of some milliseconds between
calls to bitmapData.draw().
That sounds right, also, try timing one
bitmapData.draw call, and see how big of a time difference there is on each one. Perhaps create a queue and a time limit before it stops processing for that frame?
I’m calling a function recursively using haxe.Timer.delay(paint, 20);
which will iterate over the ‘original’ sprite and draw each child to individual Bitmaps.
The delay of 20 milliseconds seems to be sufficient and the game doesn’t freeze on
Android’s FireFox anymore.
I’ve my doubts though if this is the best way to do this.
Can you (or somebody else in here of course!) think of a more elegant solution?
Also, do you have any insight what’s wrong with FireFox? It’s not only the freezing at
startup - the game itself runs much better on Chrome. It’s a rock solid 60fps vs 30-40 on
FireFox while both utilize WebGL.
How does Firefox perform if you use -Dcanvas?
There seems to be no difference while Chrome runs noticeably slower using -Dcanvas.
Ah, well that might be it – perhaps Firefox mobile is not running on WebGL mode? You can check using
trace (stage.window.renderer.type), or printing that value somewhere
I’ve just checked - it’s telling me ‘OPENGL’.
I’m not sure if it would matter, but you could also use
-Dwebgl1 to force it to not allow WebGL 2, Firefox mobile might support WebGL 2, but at a slower speed