I’m getting a solid 60fps from those demos. I’ve downloaded them from github and compiled them but they seem to be running noticeably slower (around 40 fps or so).
I’m compiling in FlashDevelop’s ‘release’ mode, with the same project.xml mentioned in the readme of the examples.
I’m new to Haxe and OpenFL, so I’m aware I may be missing some final optimization steps I need to do to get it running smoother. I’ve seen ‘final’ mentioned a few places in templates and I’m not sure how to do a ‘final’ compile, or if that’s even a thing in Haxe? What were the settings used for the demos at the above URL?
The examples were built thorugh commandline in release mode (no debug param) and that’s all. The only other difference which could have an affect is the version of OpenFL. I must admit that the examples on the github.io page although tested locally haven’t been updated against the later versions of OpenFL.
I’ll run a quick comparison here and see if there are any differences when I try.
I’m afraid the issue might be my end though, I’ve been investigating further and it appears to be running fine (60fps) in Firefox and IE, but not great in Chrome (latest stable v41.0)
What’s really weird is that at first I get a poor frame rate in Chrome (between 35-40fps) and then if I go to other tabs in the browser and back it seems to improve performance a little. I’ve also had it so I returned to the tab and it was 60fps for a while.
This doesn’t explain why your compiled versions run 60fps straight away for me though, so there must be something I’m doing wrong? I’ve got it compiling on the command line now in lime and with openfl.
@Shrill
If you are talking about the SWF versions, well, try using the standard Flash web player, trash the Pepper version.
If you are talking about the HTML5 versions, well… WHY the HTML5 examples run so slow compared to Flash ones?! Flash runs 10 times faster the HTML5.
I’m talking about the HTML5 version that OpenFL compiles. As mentioned above the ones that are on the demo page definitely perform better for me. The compiled JS files also appear to be a different size, so I was thinking I wasn’t doing a ‘final’ build on my end and that was the reason for the difference in performance.
I’ve just tried the Basic_Load3DS demo locally and from the examples page and I’m experiencing only a slight improvment on the examples page, probably 2-3fps across Chrome, Safari & FF. So there is a difference but on my machine it’s not huge (MacBook Pro 13" mid 2009 - so quite old and being pushed to it’s limits with loads of other stuff running - I get closer to 25-30fps rather than 60fps best case).
Performance is something that needs work on but I’ve not had chance to play with much recently and narrowing these issues aren’t easy
I’m just using ‘openfl test html5’ to test and run the code - nothing special.
Thanks for checking Greg, I’m now also using ‘openfl test html5’ to build and run the code.
It’s strange that the performance seems to vary between my compiled code and yours. I’ll keep experimenting though and see if I can get to the bottom of it.
I have the same issue. The official HTML5 demo i have 60 stable fps. But if i compile the example from source code, i have 40-50 with Chrome 40.0, 35-40 with Firefox 37.0, 60 stable with IE11.
I am developing a simple project, it is a sphere with a texture to emulate a panorama 360 degrees. I have the same results about the poor performance with Chrome and Firefox. With Chrome Profiler, you can see that the problem is the idle time. Currently, the drawing takes between 6-10 ms, but the idle kills the performance with 30-40 ms.
Currently using openfl 3.0.0-beta.3 with lime 2.3.0. Command line is “openfl test html5”, and project.xml equals to away3d example.
I continue with the same problem using OpenFL 3.0.3 and Lime 2.3.3. I have tested with OpenFL 2.2.8 and Lime 2.1.3 with the same result. OpenFL 3.0.6 and Lime 2.4.1 produces a black screen with all demos.
Also, I think that i have this problem with Windows target. The counter indicates 60 stable fps with the away3d-examples, but some frames are dropped when the camera is rotated.
The github.io examples are based on much older code. I’ve been bad not updating them to run against the newer code however I do use those examples to make sure things still work.
Comparing the commit dates to OpenFL - it looks like they were based on OpenFL 2.0.1 (ish). As such there have been a LOT of architectural changes since then which will have had an impact (good and possibly bad from a performance perspective).
Hopefully, now that OpenFL and Lime are architecturally more stable (in my mind at least) it should be a case where I/we can start to iron out exactly what the performance issues are and get them sorted. With Haxe 3.2 introducing typed arrays, I’m keen to see the impact of that as there is a significant amount of array casting currently going on behind the scenes which I think is one big contributor to performance.
Just to follow up on my issue a few months later… I updated my version of Chrome, and the latest OpenFL and Away3D and I was back at a solid 60fps for everything I was creating, it was great for a few months but then just recently I think there has been a breaking change in the way ByteArrays are handled and Away3D is no longer compatible with the latest OpenFL/Lime?
I’m going to roll back to the working versions I had of Away3D/OpenFL and Lime, but the good news is the performance is great in Flash and HTML5 so things are looking promising on that front