OpenFL 8.9.6 Release

We have gotten reports of regressions in both performance and functionality that occurred after OpenFL 8.9.1 when we made changes to the renderer, TextField and some filter changes.

We integrated these changes into OpenFL, expecting that these would be stable incremental steps as we have undertaken larger performance optimizations and feature changes for the next major release. However, with OpenFL 9 needing time to mature and develop and the desire for the releases to be stable, we are making a new release with additional feature fixes but with some of these internal changes reverted.

I’ve created a v8.9 branch which can be used to pull in changes for the stable 8.9 series of OpenFL while work continues on the develop branch for OpenFL 9.0.

Please help us test this release and let us know if you still see regressions. Meanwhile Lime has been released, which includes some important changes for high DPI on macOS, root path values on iOS and other stability improvements.

I’ll have more updates in the future on 2020 and our continued plans for making OpenFL solid, fast and a worthwhile platform for both porting old Flash content as well as developing new content!

8.9.6 (01/27/2020)

  • Update to allow Lime 7.7.*
  • Reverted TextField, filter and renderer changes made in 8.9.2 through 8.9.5
  • Suspended these improvements until the next major release
  • Forced NPM versions of the library to use WebGL 1
  • Improved SWFLite libraries to use a UUID and have a more reliable root value
  • Improved the behavior of textField.mouseWheelEnabled
  • Improved the behavior of context3D.totalGPUMemory
  • Improved NetStream to allow HTML5 MediaStream instead of a URL
  • Fixed an issue where MovieClip would behave like a button when buttonMode was disabled
  • Fixed a possible crash issue with multi-line text selection
  • Fixed textField.setTextFormat when the TextFormat object has null values
  • Fixed some missing methods in openfl.utils.AssetManifest for parity with Lime
  • Fixed soundTransform.volume when playing HTML5 video
  • Fixed support for event.preventDefault on MOUSE_WHEEL events
  • Fixed texture flush for AGAL shaders that do not have an alpha texture
  • Fixed key modifier values for mouse events when coming back to the window

Thank you! I was waiting for this updated and was like loosing hope already… :heart_eyes:

1 Like

I updated from OpenFL 7.2.0 and came upon 1 new bug with htmlText formatting (see how the word “link” is colored and underlined).


You can reproduce the bug with code similar to this one:

var t:TextField = new TextField();
t.defaultTextFormat = new TextFormat("any font", 20, 0xFFFFFF);
t.width = 400;
t.multiline = true;
t.wordWrap = true;
t.htmlText = "A post with a <a href='http://localhost'><font color='#FFFF00'><u>link</u></font></a>.";

There’s also an old bug remaining with text scrolling (regardless of numerous fixes to scrollRect). The text on the screenshot is located in Sprite container, scrollRect property or which is changed for the scrolling effect.
In 8.9.6 scrolling will only happen if the mouse cursor is over the Sprite! If it is outside the container’s borders, the scrollRect values will still change, but no visible scrolling will occur (something with text renderer not updating?).
This is only the case for TextFields, scrolling for other objects in the container (like Bitmaps) will perform normally.

EDIT: This only happens for TextFields with filters! TextFields without filters scroll fine.

Try this: :slight_smile:

Nope, doesn’t help :frowning:
Testing on HTML5 WebGL.

And regarding the formatting bug: this commit is what broke it.
Specifically this code:

else if (textFormatRanges.length > 0)
	textFormatRanges[textFormatRanges.length - 1].end++;

hello, does anyone know if the compilation to webassembly is in the openfl roadmap?

1 Like

We used to support Emscripten and Web Assembly but stopped trying to maintain it because it kept breaking, was very difficult to debug, slow to build and actually slower than vanilla HTML5 output.

I’ll help anyone interested in getting this going again but it’s not the “magic pill” it’s made out to be

Long-term I would like to see support again if it could be stable

Hello @singmajesty, I know there have been starts of wasm compilers and other player to replace that of Adobe, demos showing a certain efficiency because the webassembly would be machine code … there is the Ruffle project written in Rust, but, they are still far from the end, I don’t even know if they started the AVM2.

I don’t understand Haxe well, it is said that it can compile to other languages, it is rather to transpile in this case, if haxe has its own language, why can not we directly create a haxe project, but that we should use a sub-language like C ++, JS, OpenFL, …?

WebAssembly has theoretical benefits with the following caveats:

  • The file size for WebAssembly projects may be MUCH bigger
  • WebAssembly may not run well (or at all) in browsers beyond Firefox or maybe Chrome
  • WebAssembly may not be viable for projects accessed from mobile browsers
  • Performance for WebAssembly breaks down if you have to transfer information in/out of WebAssembly regularly. I think this also applies if WebAssembly has to access APIs such as typed arrays, WebGL, DOM, etc.
  • Compile-times for WebAssembly are significantly longer than Haxe-based JavaScript
  • Debugging is much harder
  • The toolchain is a lot more complex and (in my experience) brittle

Haxe does compile directly to C++ and JavaScript, so a Haxe-based project for the web can compile to JavaScript (which gets anecdotally better performance than hand-written JavaScript) and has been compiled to WebAssembly before through C++.

This is what many companies have done:

I don’t know much about javascript and emscripten. But is it possible to have a c library ported to emscripten and use it in a normal haxe to javascript game ?

Sure, anything you can write in JavaScript you can include in a Haxe/JavaScript project, including calling out to an Emscripten-compiled script. In fact, OpenFL uses an Emscripten version of zlib for handling compression

1 Like

Just to clarify, OpenFL isn’t a language. It’s a framework built in the Haxe language, with similarities to the Flash API.



My game crashes while closing native keyboard on android.
lime 7.7.0
openfl 8.9.6

This is patched in the development version:

Sorry for the trouble! We recently made updates to a newer SDL library version and need more time to test it before we’re ready for a new Lime native release

Thanks! Good luck in your work!