HTML5, CPU usage

When I run the project in Chrome without any interactivity, with just few buttons and UI layout, CPU usage is %36

Is this normal? I use <haxedef name="webgl" if="html5" />
And I have:
lime: [3.3.0]
openfl: [4.2.0]

How are you measuring CPU usage?

I’m running PiratePig here (and this browser tab in the background) on Opera, using 1.8% CPU (according to Windows Task Manager), I know it may vary per machine and browser

I use Task Manager, in Google Chrome:

After some components on stage, CPU is %79 as above.
The same tab in the background, would get down to %0.9,

What I don’t understand, is how Chrome Browser task it self is less than the tab (%14.9)

Is there anything I can do?

Good morning Joshua & hopewise,

We have noticed this too, but the CPU usage is not as high as yours.
We were 2 weeks ago evaluating the possibility to port our Analytics platform to OpenFL & HaxeUI with Ian (the great HaxeUI guy) .

The main drawbacks we found is high CPU in what should be idle time,
and font rendering under webGL & Canvas (DOM was perfect).

Aside from that, OpenFL is great, and the amount of man hours that can potentially save us porting from AS3/Flex code is awesome. The other option is a complete rewrite in awful untyped JS.

About the high CPU use when nothing has to be redrawn, I understand that should be near 0% CPU consumption (may be a dirty flag not being set inside OpenFL)
Our users are sales reps using Laptops & iPads, so we can’t drain their batteries if it is not needed.

The problem gets worse if you add a bunch of sprites to the stage, so it seems that it is redrawing every frame when it should not.

Just a quick test on my Macbook Air running Win10 w/Bootcamp Core i5 1.8Ghz.
Openfl 4.4.1
Lime 3.4.1
Firefox 50.0.1 (CPU usage from Windows task manager)
Chrome 54.0.2840.99 m (64-bit) (CPU usage from Chrome Task Manager)

I have to test it also in Edge, IE11 and latest Safari.

AddingText Sample
openfl create addingtext

openfl test html5
Firefox -> 30% CPU use
Chrome -> “GPU Process” 5% “AddingText tab” 5%

openfl test html5 -Dcanvas
Firefox -> 32% CPU use
Chrome -> “GPU Process” 8% “AddingText tab” 7%

openfl test html5 -Ddom
Firefox -> 32%CPU use
Chrome -> 2% CPU use (NEARLY PERFECT)

openfl test flash
Firefox -> 0.2% CPU use
Chrome -> 0% CPU use (Tab & SWF plugin processes)

About the fonts rendering issue mentioned earlier:
If you reduce the font size from the sample to 16, strange things happen.
In firefox Canvas & Webgl, the font is shown bigger & rescaled, In chrome it is shown ok but not perfect as with DOM.

Using the DOM renderer, the font looks much better (IMHO sharper & nicer) in Firefox and also in Chrome.
It has the best quality, but it is a pity since I think DOM is almost deprecated, and there are some libraries not supporting it 100%.

Make no mistake, I think what Joshua and the team did with OpenFL is awesome,
but I don’t know if the idle CPU usage is important to them, as seems to be focused as a game creation platform, and not an app platform (where things like font rendering & cpu are important)

Best Regards,


Hi Marc,

Though i do totally agree about getting (or at least trying to get) webgl / canvas targets down on the high CPU usage, its also worth mentioning quickly that Joshua made some updates to openfl DOM and after some testing late last night its now compatible with haxeui2 (ie the scroll rect issue is gone)…

Its also worth mentioning that it wasnt a full test, just a test app that wasnt working and now does, so there may be other issues, but figured that its probably good to mention that it seems to be in a usuable state once again.


Hello Marc,

Yes, openFL is more than for gaming, with such great UIs like haxeUI and stablexUI, it can be used also in apps, I am using it for my virtual lab using webgl, however, I am looking for ways to make it possible to run on iPads and tablets in html5, however, CPU usage is high, making it a challenge to port the lab to iPads…

May be there are some tricks or tweaks that would lower the CPU usage…

Good to hear you Ian,

Very good news!
I can help you test it out,
Do I have to use the git version of openfl & haxeui, right?

Maybe it makes more sense using DOM renderer for apps, I don’t know, maybe Joshua can tell us what he thinks is the way to go with apps.

As we discussed weeks ago, there are potentially thousands of Flex/AS3 corporate apps that have to get rid of flash player and could be ported to OpenFL/HaxeUI :wink:

Only a few glitches need to be fixed to be more app oriented, and a reliable success story is a must to sell it inside the company.

Just my 2 cents.


1 Like

Totally agree, there is a huge potential for haxe/openfl (and potentially haxeui/stablexui) to punch a big hole into, as you mentioned, apps that are tied to the flash api but need to distance themselves from the EoL of flash player. Some might opt to go for a full rewrite, but often its not an option because of size of code base, or simply time / resources. OpenFL is a very big deal here.

I think it could be that DOM might be the way to go with apps (rather than GL) but thats assuming it gets the same maintenance and “love” as the other targets. A further discussion with Joshua might also yield interesting results by minimising the use of <canvas /> in DOM apps by using multiple child <divs/> and css for simple graphics (like boxes, circles, images, etc) - a similar idea to how haxeui-html5 works. Its a nice idea, but of course, its just an idea at this stage. :slight_smile:


PS: yeah, git version of everything :slight_smile:

Just updated OpenFL & Lime to the actual git version (Nov, 30 2016)

Same AddingText Sample

Firefox-> 30% CPU use
Chrome-> GPU 5% Tab 5%

Firefox-> 32%
Chrome -> GPU 5% Tab 4%

Firefox -> 10%
Chrome -> Between 0% and 1% !!!
Edge 38.14393.0.0-> 0%!!!

Awesome improvement in DOM, congrats Joshua.

I have also tested HaxeUI with a more complex project (Kaizen test), with DOM and no bugs found until now, good work!

The CPU use with DOM is around:
Firefox -> 25%
Chrome -> 5%
Edge -> Freaking awesome 0%!!
Flash-> 0.2%


Hey guys :slight_smile:

Our GL renderer is shared between desktop, mobile and WebGL on HTML5. On desktop or mobile, you must render each frame, or everything disappears :wink:

This might not be needed on HTML5, and optimizations for preserving the previous render frame if absolutely nothing changes could be great for idle use :slight_smile:

On the other hand, I think the DOM mode is suited best for optimizing CPU for most applications, while games are often focused on performance and not battery usage.

I have just finished doing a broad number of improvements to give the DOM target more love, I would appreciate any continued feedback on DOM, I do not test it as often, so it is helpful to know when there are problems :slight_smile:

On HTML5, I don’t think there is a “one-size-fits-all” solution that is best for everyone. I think DOM is going to be the winner for most websites or applications :smiley:

1 Like

If an app is an option, maybe you could compile to flash and deploy via Adobe Air.
On iOS, Air creates native code thru LLVM, so the performance is very good as long as you know what you are doing.
It works like a charm for us for our current Flex based project with thousands of iPad users.

Not tested yet with openfl, but it should work.


Thank you so much for the DOM improvements & for your guidance.
Definitely, it seems that DOM is the way to go for HTML5 apps.

As for mobile, if it has to draw every frame, the best option might be to get the output in flash and compile it to native ios code with Adobe Air.

Thanks again for your efforts on improving OpenFL/Lime and your advice.


My app is HTML5 based, should work in browsers, I am still not able to configure why %36 CPU usage in html5 while idle, I can’t make use of DOM, there is intensive graphics, but its not a game, its a virtual lab

Have you checked the performance with DOM?
Does it work?

I tried, but visual results are were not good and out of order.

Are the latest development builds better?

I am some how stuck at openFL 4.2, I have some problems beyond 4.2, I will investigate when I have time…