[HTML5] Starling 2.2.1 Update vs OpenFL masks


Hey guys,

I’ve been forced by dragonbones skeletal animation to update Starling from old 1.8 to 2.2, because meshes in dragonbones are supported only in Starling 2+. So i’ve gone through all the struggle to change a lot of things to match new structures ex. implementation of custom FragmentFilters and I’ve noticed that my OpenFL sprite masks disappeared all at once. It looks like Starling renders on top of these making them invisible but I can still easily click on each element of a masked clip (while it is invisible)(buttonMode shows different cursor) and it can be moved around or be interacted with in any other way.

I currently cannot provide any code sample to recreate this but maybe someone has encountered a similar issue and found a nice solution?



Also, I’m not 100% sure but out of the box, performance-wise it is slower a lot. Had 60fps, stable with 5-10 bones animation before (1.8.13), now 35fps right from the start, down to 15-20 while animating (2.2.1). I believe I’ve made some mistake and it is affecting the performance, so if anyone had similar issue, please share some solution.


How much of your content is in OpenFL (such as the sprite masks), and how much is in Starling?

Did you upgrade your OpenFL version in the process of upgrading Starling?


I’ve got OpenFL upgraded before upgrading Starling so everything works perfectly fine on OpenFL 7.1.2, Lime 6.2.0, Starling 1.8.13, Dragonbones 5.0.0. I’ve just updated Starling to 2.2.1. Most of the content is OpenFL content - I’m using Starling for one dragonbones animation (around 5-10 bones) and for one simple Image with custom FragmentFilter (custom AGAL shaders). Image is around 800x600 (static textures, no heavy calculations besides those done in fragment shader).

In 1.8.13 I get around 60FPS almost constant while in 2.2.1 it gets immediately to 35FPS with animation hidden (I’ve even disabled all other things) while dropping to 15-20FPS while animating. I’m working on late 2012 Mac Mini with i5 and testing on Chrome 64 but I believe there is no issue with any of these but the library itself.

Since I have almost no spare time now, I’ll try to do some comprehensive samples during the upcoming weekend and if the results are similar I’ll post some issues on Starling github. I’ve just wanted to know whether someone has similar issue to mine after upgrading - if nobody, then I’m doing something wrong.


I’ve just tested 2.2.1 with both example Dragon animation and my own animation and it works well. I’m looking for some more clues and will share the results of my investigation with you as soon as I come to any more precise conclusions.


So Starling (without OpenFL content) works, and OpenFL works, but the combination of the two (with the later version of Starling) causes this issue? It may be a conflict in the GL context, as both Stage3D and the OpenFL renderer share the same context right now

Do you have a way I could reproduce it?


I will try to provide a comprehensive sample within few days (probably in the upcoming weekend).


I struggle to recreate this bug in a test application even though I’ve added everything as I do in my real one. I need more time to provide the sample I’ve promised delivering. I’m working on it.


I have encountered this problem.


Any more informations on that? Have you solved it or at least got any clue what caused the problem?


No, I didn’t solve it, but I found it to happen in the FragmentFilter, especially when moving the scene (this may happen in the larger display object in the FragmentFilter area),currently I try to use MeshStyle to solve it.


My MeshSytle experiment was successful and the efficiency increased to 60FPS, which means that the filter was unexpectedly occupied.

AGAL code:

    package zygame.filter;

import starling.styles.MeshStyle;
import starling.rendering.MeshEffect;
import starling.rendering.RenderState;
import openfl.display3D.Context3D;
import openfl.display3D.Context3DProgramType;
import starling.rendering.MeshEffect;
import starling.rendering.Program;
import starling.rendering.VertexDataFormat;
import openfl.Vector;

class SetColorStyle extends MeshStyle

    private var _color:UInt;

    public function new(color:UInt)
        _color = color;

    public function getColor():UInt
        return _color;

    override public function createEffect():MeshEffect
        return new SetColorEffect(_color);

    override public function updateEffect(effect:MeshEffect, state:RenderState):Void

    override public function copyFrom(meshStyle:MeshStyle):Void
            var colorStyle:SetColorStyle = cast(meshStyle,SetColorStyle);
            this._color = colorStyle.getColor();

class SetColorEffect extends MeshEffect {
	private var ver:Vector<Float>;

    public function new(color:UInt)
        ver = new Vector<Float>([0,0,0,1]);

    public function setColor(rgb:UInt):Void
		var r:Int = rgb>>16;
		var g:Int = (rgb>>8)&0xff; 
		var b:Int = rgb&0xff;
		ver[0] = r/255;
		ver[1] = g/255;
		ver[2] = b/255;

    override public function createProgram():Program
        // TODO
		var vertexShader:String =  "m44 op, va0, vc0 \n" + // 4x4 matrix transform to output clip-space
				"mov v0, va1      \n" + // pass texture coordinates to fragment program
				"mul v1, va2, vc4 \n";  // multiply alpha (vc4) with color (va2), pass to fp;

		var fragmentShader:String =
			"tex ft0, v0, fs0 <2d, repeat> \n" +
			"mul ft1, fc0, ft0.wwww \n"+
			"mov oc, ft1";
		return Program.fromSource(vertexShader, fragmentShader);

    override public function beforeDraw(context:Context3D):Void
		context.setProgramConstantsFromVector(Context3DProgramType.FRAGMENT,0, ver);


If the above code is placed on the filter, the performance will become extremely low.


That’s a great hint. I’ll try it out soon.


:smiley:If you can solve the filter, then it is really great.