Release: OpenFL 8.8.0

Hi again!

As a team, we have been focused recently on expanding our unit, integration and functional testing for OpenFL. This is not reflected in the changelog, but my hope is that we will be able to increase our test coverage and to make it easier to ensure that we’re properly guarded against regressions, while also easing the way for more contributors to improve OpenFL.

Our extra testing recently has helped us resolve a number of minor issues we discovered, and is already improving the quality of the release. :grin:

OpenFL 8.8.0 (01/07/2019)

  • Added ByteArray.defaultEndian property
  • Updated canvas TextField renderer to use text baseline for more consistent rendering
  • Updated the types for KeyboardEvent on Flash to improve support for switch cases
  • Improved UncaughtErrorEvents handler to not run on debug by default
  • Initial support for mouse wheel support in TextField scrolling
  • Disabled some incorrect HTML5 canvas renderer blend modes
  • Fixed the behavior of ByteArray.defaultObjectEncoding
  • Fixed a possible infinite loop when applying word wrap to narrow TextField instances
  • Fixed a regression in marking scrollRect changes as dirty
  • Fixed a regression in HTML5 DOM rendering when objects are removed from the stage
  • Fixed dirty object calculation for removeChild in some renderers
  • Fixed issues in SWF processing to improve NPM/Haxelib release compatibility
  • Fixed Loader to dispatch an error if Loader.loadBytes returns a null BitmapData
  • Fixed some issues with multi-format TextField line breaking
  • Fixed some minor issues for users trying to use OpenFL with unsupported Haxe versions
  • Fixed some issues with Graphics objects being dirty when using cacheAsBitmap
  • Fixed missing Event.CONTEXT3D_CREATE event if requestContext3D is called again
  • Fixed support for using AMF0/AMF3 object formats in NPM ByteArray
  • Fixed the behavior of MovieClip with buttonMode but with enabled false
  • Fixed some issues when setting the CubeTexture sampler state
  • Fixed support for disabling the context menu on browsers that show on mouse down
  • Fixed unnecessary Lime version warning when running openfl create
  • Fixed a case where Stage3D could render when the context had not been cleared
  • Fixed Sound.getLength for sounds streamed from OGG Vorbis audio files

ByteArray.defaultEndian

Some versions ago (in OpenFL 6, I believe), we changed our endianness behavior to match the host platform. This was done because it matches the behavior on all our targets – C++, Neko, HTML5 (and other experimental targets) – while breaking from the behavior of Flash Player. This helps improve our performance, and helps improve interoperability between OpenFL programs and native extensions or other native applications.

ByteArray has a defaultObjectEncoding property that can be used to distinguish between AMF0 or AMF3 object serialization formats in Flash Player. OpenFL includes support for both AMF0 and AMF3 objects (if you have <haxelib name="format" /> in the project) but also has support for HXSF (Haxe serialization) or JSON object formats. Each new ByteArray object that is created will set it’s objectEncoding value to match this default. On non-Flash targets, this is already different than Flash (HXSF) but this also provides to easily match Flash without setting the field on every ByteArray you create.

We decided to add a ByteArray.defaultEndian property. Although this is not a part of the Flash API specification (which is always BIG_ENDIAN for “network byte order”) introducing this, we felt, was an important part of making it more clear (and easier to control) that OpenFL does allow different default endian values, and that by default, this varies between Flash and other platforms, which match the host. With the exception of some server backends which use BIG_ENDIAN, 99% of devices use LITTLE_ENDIAN instead.

More Testing

We’ve been broken our old Haxelib unit tests into two separate test runners, “unit” and “integration”.

The OpenFL unit tests run without Lime and should be platform-agnostic. We’re currently using a custom version of munit with fixes for better async test support. This is also running currently on the terminal using the Neko target only.

Using a development version of OpenFL, use hxp unit-test to run all of the tests, or hxp unit-test --filter=openfl.display (or another value) to filter the tests to run fewer at once.

We also use our unit tests in the integration test suite. The integration test is designed to include Lime, and to be tested in multiple environments. We can run both Flash and HTML5 side-by-side using the standard munit web runner, or test C++, Neko, AIR and Electron from the terminal.

In this environment, we can expand testing to features which address how multiple classes interrelate to each other, and test features which require a real window and real application to be running, but can still be tested in a headless fashion.

Using a development version of OpenFL, use hxp integration-test web to run Flash and HTML5 side-by-side in a browser window, or hxp integration-test neko (or another target) to run the suite on another desktop platform. We haven’t been testing against mobile platforms using these tests, but that may be possible as well.

Lastly, the functional tests for OpenFL are an OpenFL application which is set up to host a number of tests that must be verified manually. In the future, we’ll want to drive as much testing as possible back down into our unit or our integration testing, but the functional tests are helping fill in an important gap in our ability to validate OpenFL’s support of each feature – the reality that some features are hard to test automatically, and to help broaden the amount of code we test before each new release.

We’d appreciate any help in expanding our tests!

Setup for running tests requires 1.) OpenFL, 2.) munit (https://github.com/openfl/munit) and 3.) HXP

Other Changes

There are many things that could be said about this release, so please feel free and ask if there is anything else you are curious about!

Thanks to all our contributors and Patreon supporters.

Looking forward to a bright 2019! :tada:

8 Likes

Been away for a while, this is great !

I can confirm it solved .graphics issues when doing addChild => removeChild and addChild again, thanks for this !

Had 2 minor issues with Starling on flash target only (I use flash target and windows target) :

  • VertexData => set_numVertices triggering a compilation error about comparing Int and UInt. ByteArray.length seems to be considered UInt on flash target.

  • MiniBitmapFont.getBitmapData triggering a runtime error when doing a byteArray.uncompress : it says CompressionAlgorithm must not be null. Using ByteArray.uncompress(CompressionAlgorithm.ZLIB) solves the issue

Thanks!

1.) I patched the VertexData issue in Starling on the Flash target.
2.) I think I fixed this issue for the Flash target with a patch in OpenFL, I’d appreciate if you have a way to test and see if the fix works? I posted here: https://github.com/openfl/starling/issues/117

Just tried the OpenFL patch but byteArray.uncompress() still triggers the same error

Okay, it’s fixed now in OpenFL dev

1 Like

I have a question. Is it possible to catch Lime errors?
UncaughtErrorEvents only fires for OpenFL errors atm, while many occurring errors are Lime errors (like errors during assets loading).

Yes, I think UncaughtErrorEvents is designed to wrap around most user code, though if there is something asynchronous then it’s possible it will not be wrapped.

I think that (probably?) if an error is occurring from Lime (such as from asset loading) then we want to try and make those problems pass errors back rather than causing trouble. If we do so, then the code higher up the chain (in OpenFL) can handle the errors there. Is there something specific you’re running into?

Next time I run into those Lime errors, I’ll post here!

And another thing regarding text shifting and this issue https://github.com/openfl/openfl/issues/2101.
You made this commit which fixed shifting, and I was using that dev version of CanvasTextField.hx for proper text placement.

Now, after updating to 8.8, text has shifted again. No, it’s not shifted relative to itself in different browsers, but shifted compared to that dev version I was using. Joshua, do you know what other files affecting text placement have been changed after that commit? I’d revert to the old versions, otherwise it’s going to take me a few days again to reposition all the text.

The change does require a newer version of Lime, in order to properly export the font data for each embedded font.

The fonts that look incorrect, are they included in your project at compile-time, or included later through CSS?

I understand, still that version of CanvasTextField.hx worked for me without Lime upgrade.

Included in my project.

Do you think something can be done in Lime files locally to bring texts to their previous positions?

If you have a font without having the newer/improved Lime version, then the font will have no font metrics, and will be placed in the wrong location