Development Update: OpenFL 9

Announcements
#1

Hi everyone!

Development on OpenFL 9 is moving forward!

Here’s a quick re-cap of the short-list I shared previously:

  • Stabilized new SWF format
  • Performance improvements
  • Maturing the auto-batcher in the OpenGL renderer
  • Integrated HW support for vector shape rendering
  • Finalizing the “Timeline” API for populating MovieClip instances
  • Maturity of scale9Grid and alpha-blended masks would be great
  • Also considering removing Lime as a requirement on OpenFL/HTML5
  • I want to try and move the rest of our devops to Github as well if I can
15 Likes
#2

For the last couple weeks I have been focused primarily on designing a new hardware renderer with automatic batching. Already it supports Bitmap + scrollRect in order to batch multiple sub-rectangles of a BitmapData in multiple Bitmap objects. Tilemap, Bitmap, drawQuads and other APIs are expected to batch together if the draw calls are similar enough. I’m currently working on multiple texture support so we can continue to batch even if the texture changes.

InnoGames has a version of OpenFL that has an added SubBitmapData class in order to assist with batching Bitmap display objects. Bitmap + scrollRect should accomplish the same functionality without adding a new type.

var bitmapData = Assets.getBitmapData("spritesheet.jpg");

var bitmap = new Bitmap(bitmapData);
bitmap.scrollRect = new Rectangle(0, 0, 100, 100);
addChild (bitmap);

// will batch into the same draw call
var bitmap2 = new Bitmap(bitmapData);
bitmap2.scrollRect = new Rectangle(100, 0, 100, 100);
bitmap2.x = 100;
addChild (bitmap2);

In some ways these features will make Tilemap obsolete, though Tilemap still creates structure that encourages batching while Bitmap and other display objects can quite easily add features that might break batching.

11 Likes
#3

There is a any SWFLite improvements?

#4

The unit and integration testing has been moved to Github but I’m not sure if we’ll also plan on moving our official builds to Github (from our own TeamCity servers) as well. Maintenance and costs would go down but we would also lose some flexibility for added software or older SDKs.

The groundwork for removing Lime as a requirement for OpenFL has been done. The goal is to allow OpenFL to run on its own when targeting HTML5 and to require Lime only for native builds. I hope that this will lead to also making the Lime tools more of an optional springboard and less of a requirement. Ultimately this makes OpenFL simpler to grasp and a bit more bulletproof.

Progress on scale9Grid or alpha masking has not occurred yet but is still something I want to see as a part of the current renderer work.

The SWF library has come back and OpenFL 9 will not support SWF timelines out-of-the-box. Instead the beta Timeline API adds the part we were missing in creating new MovieClip objects with labels and timelines. The beta Timeline API is likely mature but we will continue to listen for feedback so this can become set for the future.

I have a version of OpenFL with the OpenFL 3 HW vector renderer in place but it certainly falls short in certain cases. A stretch goal for OpenFL 9 includes either a rewrite of this functionality into the new renderer or (more likely) integration of this vector renderer and a flag internally that switches on or off the hardware renderer based on known feature support. I’m not promising this but I’d certainly love to see this at least for simple stuff like rectangles.

6 Likes
#5

Not directly but here are some indirect improvements planned:

  1. The Timeline API
  2. Render batching improvements
  3. The separate SWF library
  4. (Stretch goal) HW vector improvements

The Timeline API will separate OpenFL’s playback of MovieClip from the creation and population of the MovieClip timeline. This will create consistency between multiple inputs (whether a MovieClip comes from a SWF, SWFLite, XFL, etc) and reduce the overhead for new formats.

SWF libraries use a lot of display objects so render batching should help improve performance where refactoring as a Tilemap is impractical and undesired.

The truth about SWF libraries there are three problems to deal with – first how to parse the SWF, second how to package the SWF content and third how to playback the content.

I hope that the separate SWF library will help because parsing the SWF has not changed much (and I think is good already) but without requiring changes to OpenFL or the Lime tools I think that new packaging formats should be quick and simple to do. Lastly it also puts the emphasis playback on OpenFL’s renderer and subsequent performance and isn’t really a SWF issue. There is some frame-to-frame logic required in the SWF Timeline code but I hope this will be easier to work on separate from OpenFL.

HW vector improvements would also have a giant impact (potentially) on SWF performance so I also hope to see this.

5 Likes
#6

While the bundle is being processed, fps really drops a lot.
Also, when using cacheAsBitmap in movieclip loaded with bundle, performance decreases and graphical errors occur.

#7

Depending on the type of bundle you are loading, there may be a few steps in play:

  1. Downloading the bundle content
  2. Unzipping the bundle content
  3. Parsing the SWF data (JSON/Animate) or deserializing it (Haxe serialization/SWFLite)
  4. Instantiating the document class of the SWF

There are many ways this could improve

Most releases of OpenFL will use cacheAsBitmap in software or hardware. For a couple versions (8.9.4 and 8.9.5 perhaps) it was hardware only which made caching of HW shaders consistent but also had mixed performance on different devices. Multiple versions of the SWF library actually ignored cacheAsBitmap in SWF content because it caused more harm than good in most cases. That can easily be applied again within the SWF parser and may be a good thing to consider

EDIT: Try commenting this line if you are on 8.9.6: https://github.com/openfl/openfl/blob/cf5db8d4c19b1dbf1ebb5bc85313f49af750d4ba/src/openfl/display/MovieClip.hx#L950

3 Likes
#8

Thank you @singmajesty & all the contributors for the amazing works!

1 Like
#9

That sounds awesome! Tilemaps have always been a bit of an inconvenience, so having their performance available via the regular Bitmap system would be great. If I understood this correctly, it means that as long as a display tree subtree consists only of Bitmaps, and all of those Bitmaps share the same BitmapData, that entire subtree is rendered in one batch?

While this greatly simplifies code that has previously mixed Bitmaps and Tilemaps, it now becomes necessary to be careful not to break the automatic batching. For that purpose, I think it would be good to also have more ways to monitor that rendering is proceeding as expected. For example, DisplayObject could have a variable that tells the number of batches used to render the subtree it is the root node of.

#10

Hello Joshua, it’s interesting to know - does openfl 9 break compatibility with haxeflixel again? Because we are stuck even at openfl 7 still because of differences in versions openfl 4, 5, 6, 7, 8. And were mentally preparing to move to openfl 8, but now this post? :sweat_smile:

#11

I know that HaxeFlixel was stuck on OpenFL 3 for a long time until we added the drawQuads API but I was not aware that HaxeFlixel was not current on OpenFL now

Changes I’m discussing should affect under-the-hood behavior and should not affect any public-facing APIs that HaxeFlixel uses to my knowledge

#12

Not sure about current (that’s the reason behind my question), it’s on openfl 8 at least. But we’re using some feature from older openfl 7 compatibility haxeflixel branch, which we didn’t have time to implement yet on the (newer) engine side…

Changes I’m discussing should affect under-the-hood behavior and should not affect any public-facing APIs that HaxeFlixel uses to my knowledge

That’s great news, thank you!

#13

Here is the current progress:

  • Shader improvements are mostly stable to allow for GLSL array types
  • Batch rendering has passed milestones for the “proof of concept” and is pending architecture changes to support it
  • We’ve made big strides to develop the standalone OpenFL experience that supports HTML5 or Flash without Lime or Lime tools

There are two blocking issues which have slowed development but I am confident that the path forward will be positive.

There are a lot of exciting and positive changes coming in the pipeline for OpenFL, but many of these features require architectural changes that compromised the reliability of our development branch.

In response we reverted the primary development branch and hand-picked features to support in the 8.9.6 release. Now we have two major development branches – one with all changes (but not stable enough for all users) and one that’s stable but lacks the architecture changes needed to support the newer features.

In the interest of stability, we are currently favoring a solution where we stay with the stable development branch, then integrate features more slowly after they are fully mature.

The second problem is more embarrassing to discuss, but is another real limitation in development: mental overload.

OpenFL is an awesome project that targets web targets, mobile targets, desktop targets, C++, Neko, JavaScript, HashLink, AVM, with lingering support for Java and C#… all in one codebase.

All the features we’re most excited about require fundamental changes to the core architecture of the library. Personally, I load all of OpenFL (each language, each platform) into my head at once, imagine architecture changes and make changes with all the pieces in perspective, but I am reaching my limits lately.

They say that to “eat an elephant” you eat it “one bite at a time,” and that is how I would like to approach this problem. Allowing OpenFL to be used without Lime and without the Lime tools removes a lot of “cognitive load” by reducing the variables. Similarly, changes to SWF asset processing using the Timeline API.

The next wave of improvements we desire for OpenFL 9 shake the foundations of OpenFL’s architecture and stress the limits of my ability to handle complexity (in order to simplify it, of course).

As a result, this has led to a shift in attention. In order to finish the fun features planned, next we need to cut OpenFL into “bite size” pieces. “But can we please keep things stable?” Those are two different priorities – one to have stability and improved performance (so long as it does not introduce instability) and the other to have a laboratory where there is the mental room and agency to cook up the features and performance we need.

The result is that we are currently planning to let the stable development branch remain and will abandon most of the architecture changes in the v9 development branch. For the time being the stable branch will not allow use without Lime and the Lime tools. It’s stable and married to Lime forever.

The v9 development branch is going to develop into the standalone OpenFL and drop support for Lime, Lime tools or all platforms except HTML5.

This will let us make a stronger HTML5 target, simplify our code and create the workspace I need to cook up each new feature without being overloaded. Then new features can integrate back into “the everything” source code when they are good and mature

7 Likes
#14

Does this mean that OpenFL9 will no longer support platforms other than HTML5 in the future? I still need HTML5, Android, and IOS constructs.

#15

No, the plan will be to release OpenFL 9 from two different codebases.

The HTML5-only code will be simplified and refined and as the features mature we’ll bring them to the “all targets” codebase and release OpenFL 9 when both have the expected features.

3 Likes
#16

@singmajesty Sorry for asking the question in the wrong window but my question is for you only.
I am new in Flash/OpenFL development. We have one GUI product “Operator Conference Call/Operator GUI” in Flash. Now as you know Flash is going to be ended by 2020.we decided to migrate our flash code into another language. I did some research and found that we can Migrate our Flash code into HaxeUI+Haxe+OpenFl.
So I converted all ActionScripts into .hx.now I have some basic questions please answer.

  1. When we compile Flash code it generates .swf file that runs on browser and for that Flash Player is required.
    if we are moving in OpenFL(It’s a kind of mirror API of Flash), does Openfl also generates .swf file when we compile or how it is?
  2. Can we use the converted code(ActionScript to .hx) as it is in OpenFL?
  3. Is it possible to achieve same look and feel with HaxeUI compare to Flash?
#17
  1. OpenFl will generate swf files only if you target Flash. Otherwise it will be js for html5 target, etc. But you can still use Animate as a layout editor, compile it in swf, and use it in your OpenFl project thanks to the swf lib that will generate images from your swf (so the swf is kind of decompiled when you compile your OpenFl project).
  2. That depends on your project. In my own experience, I had to move TweenLite code to Actuate and BulkLoader to OpenFl own API, and I had to make some tweaks on filters.
  3. Yes, you can still use Adobe Animate for layout. Or you can use a UI lib like Feather or HaxeUI like you suggested. But you may have to make some tweaks on Filters because it doesn’t render the same.
#18

It’s been two weeks since the previous update and although progress has been slower than expected, things are still moving forward!

Many of the improvements in develop-v9 have now been moved into feature branches. These are not all stable as most of the features intertwined and depended on each other.

The goal is to let the Haxe develop branch remain stable and target all currently supported platforms. The features we wanted in develop-v9 will be integrated one-by-one as they are ready.

One thing I wanted in develop-v9 was a change to the internal architecture of the library to make a standalone HTML5/Flash release. Instead of forcing this on the develop branch I am in the process of porting that code to Typescript instead.

I feel that Typescript is a good choice for the goals I have for this standalone version of OpenFL which include the ability to use it from Haxe. When complete I expect Haxe developers to be able to use -lib openfl and reference OpenFL (for Flash or HTML5 only) without any requirement for Lime tools.

I also think that this will provide a better development path for our NPM users who may want to contribute and make OpenFL a true open-source Flash replacement.

My first pass for the port is complete but it will still be a week or so before I expect to see our unit tests passing.

As I continue to see continued focus from our community of developers on HTML5 as the primary and only target of interest, I also want to begin planning to add features that are easy to implement on HTML5 but lacking on native platforms like webcam integration. ES6 weak maps also should allow the weak references we need for proper addEventListener implementation

Thank you everyone for your support and feel free to ask questions on our Discord server

8 Likes
#19

Are you sure that DCE will still work when using -lib openfl in TypeScript ?
I’m asking because DCE didn’t trigger for my project when I was using my own Flash library : the full .swc file was included in the binary… Porting my library to haXe solved the problem, though :slight_smile:
So, since it’s important to keep HTML5 builds as small as possible, I think we should keep an eye on it.
At least, one solution (but not optimal) would be to let us disable/enable each “feature” with a specifc haXe define, e.g.-Dopenfl_video

#20

I’m currently using ES6 modules which should be able to map to Haxe extern classes individually, so mostly it will be a matter of how independent (or interconnected) the classes really are.

Ultimately I think things will get smaller when it’s stable because we won’t need the Lime abstraction layer in the middle

Lime is awesome for mirroring functionality across HTML5, alternative runtimes (such as Neko and HashLink) as well as native C++, but should not be necessary for HTML5 only

3 Likes