Away3D OpenFL HTML5 performance

Hi there, I’m using FlashDevelop with Haxe 3.1.3 and OpenFL 2.2.4

I’ve got the Away3D examples up and running but the performance isn’t as good as the demos shown here:

http://away3d.github.io/away3d-examples-openfl/

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?

Thanks in advance for your help,

Greg

Hey,

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.

Thanks for looking into this Greg.

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)

I uploaded the compiled project here: http://waroo.com/openfl/

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.

here is the project.xml:

<?xml version="1.0" encoding="utf-8"?>
<meta title="Basic Shading A3D OpenFL" package="" version="1.0.0" />
<app main="Main" file="Main" path="Export" />

<window width="1024" height="700" if="desktop" />
<window width="0" height="0" if="html5" />
<window orientation="landscape" vsync="true" if="cpp"/>
<window fps="60" hardware="true" allow-shaders="true" require-shaders="true" depth-buffer="true" stencil-buffer="true" />
	
<source path="src" />

<haxelib name="format" if="html5" />
<haxelib name="away3d" />
<haxelib name="openfl" />

<assets path="embeds" exclude="away3d.svg" />

<icon path="embeds/away3d.svg" />

<haxedef name="source-map-content" if="html5" />
<haxedef name="dom" if="html5" />

<haxeflag name="--no-traces" if="html5"/>
<haxeflag name="-dce full" if="html5"/>

<!--<android minimum-sdk-version="10" />-->

@Shrill, i run your demo here in Chrome with solid 60-61 fps.

I’m using OpenFL 2.2.8 and Lime 2.1.3.

It’s possible that updating your libraries might solve this.

@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.

Have you tried compiling from the command line as Greg suggested?

so why do I have terrible performances in HTML5 version?

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’ve been having issues with the Basic_LoadAWD example. The HTML5 target runs on Chrome but causes an error in FireFox.

Have you got any details of the error?

Hi.

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.

What is wrong?

Kind Regards.

Hi again.

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.

Some ideas?

Kind Regards.

Are you using the -Dlegacy option? Currently Away3D doesn’t support ‘next’ which is the default architecture of OpenFL 3.x.

Have you tried the current git version of Away3D?

Work is still on-going but I’ve been busy with other things recently, sorry.

1 Like

Hi Greg. Thanks for your response.

Yes, i’m using legacy option. I have tested even with OpenFL 2.2.4 and Lime 2.0.3. I am using the git version updated.

What version uses the demos in github.io page?

Kind Regards.

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.

Any help is much appreciated :wink:

Hi Greg.

I understand. Yes, it is more stable and i think that it requires to move on with OpenFL 3. I will try to help/collaborate in any way possible.

Thanks for your great work :blush:

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 :smile:

1 Like

FYI - I’ve just released an update on haxelib for Away3D 1.2.0 which brings it in line with the latest OpenFL/Lime changes.

You might want to give it a whirl. :slight_smile:

1 Like