Development Update: OpenFL 9

Announcements
22

Thank you EVERYONE who responded to the current OpenFL Developer Survey. If you have not already, please respond and help your voice be heard!

Your voices are being heard clearly that “Improved stability” and “Faster performance” are the top priorities for your needs.

There are two ways that I know to preserve stability:

  1. Limit changes
  2. Establish thorough testing

The previous work on OpenFL (before the 8.9.6 rollback release) began to increase our performance at the price of stability and edge-case performance regressions that became too difficult to track down.

The contributors in the OpenFL Discord and I have discussed strategies for increasing the ease of contribution and how to better isolate code testing and (in a worst-case scenario) rolling back portions of code instead of the whole. We are targeting a change internally to move OpenFL into multiple private packages or modules. This changes nothing about how OpenFL is used but lets us break OpenFL into smaller logical pieces such as “the OpenGL renderer” or “text” or “the event dispatcher”.

We also have these units of code isolated in order to be able to run tests independently. Herein lies another catch. Historically OpenFL has supported so many target platforms that it is difficult to test. Eventually it landed on manual testing to determine if OpenFL was operating properly before a release. As we seek to increase the number of direct contributors to the OpenFL codebase I want to more heavily on automatic testing.

Here are my current expectations for OpenFL and Lime:

  1. Lime will follow the “limit changes” approach for now to keep stability
  2. OpenFL will follow the “establish thorough testing” approach to preserve stability as we seek to improve the library

I also expect a shift in focus on OpenFL:

  1. OpenFL will focus on HTML5 as the primary platform
  2. Unit testing will be written around functionality before making changes
  3. Unit testing will be written and tested on the HTML5 target only
  4. We will try to keep other targets in mind and not break them purposely
  5. Native platforms will be a collaboration with the broader OpenFL community but will not be officially “rubber stamped” and guaranteed

#5 may come as a bit of a shock but this is actually an honest admission of where things currently stand. OpenFL lacks broad automated testing and the chaos of every supported platform is a mental drain that is slowing down the development of the project. I’m of the mind that developing a fast, stable, robust HTML5 target (then patching as needed) is going to produce much better results than stagnating with every platform officially supported.

These decisions aren’t final, and I’m happy to discuss them more on Discord.

6 Likes