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
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.
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++.
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
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
Hello! I have another problem with texts.
Clipboard does not work on html5 because of Feature Policy.
I’m trying to get clipboard data by clicking on a button.
How can I get around this?
I found an issue that explains some of the reason why this regression happened in Chrome and a new policy that is coming to the browser that allows the parent page to grant permissions to the child window:
I’m very interested in getting web assembly support again. Don’t suppose anyone has looked into it again recently? If not, can you point me to where things left off? Not at all my area, but I wouldn’t mind looking into it.
