Resulting in something like this:
To reproduce, create any TextField with embed font.
Set text to something, set filters to [any_filter], then call setTextFormat.
Then change the text, and call setTextFormat again.
-Dopenfl-always-render doesn’t help here, and I can’t find a workaround for this.
I just tried to reproduce it here, but it worked fine, either my sample is missing something, or this is already fixed in the development versions of Lime and OpenFL.
Would you mind trying this?
package;
import openfl.display.Sprite;
import openfl.filters.GlowFilter;
import openfl.text.TextField;
import openfl.text.TextFormat;
class Main extends Sprite {
public function new () {
super ();
var format = new TextFormat ("_sans", 40, 0xFF0000);
var textField = new TextField ();
textField.text = "HELLO WORLD world world";
textField.filters = [ new GlowFilter (10, 10) ];
textField.setTextFormat (format);
addChild (textField);
stage.addEventListener ("click", function (_) {
textField.text = "abc";
textField.setTextFormat (format);
});
}
}
OK, replace with the following please:
package;
import openfl.display.Sprite;
import openfl.filters.GlowFilter;
import openfl.text.TextField;
import openfl.text.TextFormat;
import openfl.text.TextFieldAutoSize;
class Main extends Sprite {
public function new () {
super ();
var format = new TextFormat ("_sans", 40, 0xFF0000);
var textField = new TextField ();
textField.autoSize = TextFieldAutoSize.LEFT;
textField.text = "HELLO WORLD world world";
textField.filters = [new GlowFilter(0xFFFF00, 1)];
textField.setTextFormat (format);
addChild (textField);
stage.addEventListener ("click", function (_) {
textField.text = Std.string(Math.random());
textField.setTextFormat (format);
});
}
}
For me it’s also working properly (your latest sample), both hardware="true" and hardware="false", simple openfl test html5 - no parameters, latest OpenFL and Lime devs versions. Tested on Chrome and Firefox. BTW: Why are you setting text format again after update ? I guess it is not necessary.
Good to hear!
For me it is working without glitches when not using textFieldAutosize.
Otherwise I get
For Flash it was necessary, unless defaultTextFormat was set (with embed fonts, at least).
I’ve used your sample with textField.autosize. I’ll check something else now. Hmm. Could you post your project.xml file or at least <window> tag ? Even changing some settings around still makes it work properly. I’ve got project.xml <window> tag sets as follows:
<window width="1000" height="150" fps="60" hardware="true" allow-shaders="true" require-shaders="true" resizable="false"/>
<!-- metadata, make sure 'package' is at least 3 segments (ie. com.mycompany.myproject) -->
<meta title="BWF" package="BWF" version="1.0.0" company="Volk" />
<!-- output -->
<app main="Main" file="BWF" path="bin" />
<window background="#000000" fps="60" resizable="false" />
<window width="700" height="360" unless="mobile" />
<window orientation="landscape" vsync="false" antialiasing="0" if="cpp" />
<!-- classpath, haxe libs -->
<source path="src" />
<haxelib name="openfl" />
<!-- assets -->
<assets path="assets" include="*" />
<icon path="assets/openfl.svg" />
BTW, I tested without calling setTextFormat again and setting textField.autoSize to TextFieldAutoSize.RIGHT.
This “fixed” the shifting I described here.
I’ve seen that topic on shifting too. Tested with yours <window> parameters and still getting valid result. Also removed setting defaultTextFormat and tried all the autoSize types - still nothing like that. I remember it happening before and that was something I’ve fixed.
To be 100% sure - check in your OpenFL Dev branch DisplayObject::~2520 - do you have copyPixels there commented out while things after // Adding __cacheBitmapRenderer = null; makes this work uncommented at the same time ?
I’ve installed dev Lime and OpenFL.
The filter bugs have gone.
New text formatting bugs have arisen.
Text shifting is still there. I’ll try to update the example code to reproduce both of these bugs.
Bug from the screenshot:
package;
import openfl.display.Sprite;
import openfl.filters.GlowFilter;
import openfl.text.TextField;
import openfl.text.TextFormat;
class Main extends Sprite {
public function new () {
super ();
var format = new TextFormat ("_sans", 40, 0xFF0000);
var textField = new TextField ();
textField.width = 600;
textField.text = "Click here please!";
format.color = 0x4D0404;
textField.setTextFormat(format, 0, 5);
format.color = 0xCE4400;
textField.setTextFormat(format, 5, 9);
format.color = 0x4D0404;
textField.setTextFormat(format, 9, textField.length);
textField.filters = [new GlowFilter(0xFFFF00, 1)];
addChild (textField);
stage.addEventListener ("click", function (_) {
textField.text = "Thank you!";
});
}
}
Reducing text width to 400 will “fix” it.
I also removed setTextFormat for the click event to see what happens.
Regarding autoSize…
It’s just an unpredictable formatting.
In the example below, after the app is started, the text will appear either from the left or from the right of the line (should always appear from the left).
Then, after the text is changed, it will be positioned “randomly” close to the line.
import openfl.display.Sprite;
import openfl.filters.GlowFilter;
import openfl.text.TextField;
import openfl.text.TextFormat;
import openfl.text.TextFieldAutoSize;
class Main extends Sprite {
public function new () {
super ();
var format = new TextFormat ("_sans", 40, 0xFF0000);
var border:Sprite = new Sprite();
border.graphics.lineStyle(5, 0xFFFF00);
border.graphics.drawRect(400, 0, 0, 400);
addChild(border);
var textField = new TextField ();
textField.autoSize = TextFieldAutoSize.RIGHT;
textField.defaultTextFormat = format;
textField.x = 400;
textField.width = textField.height = 0;
textField.text = "Aligned text";
textField.filters = [new GlowFilter(0xFFFF00, 1)];
addChild (textField);
stage.addEventListener ("click", function (_) {
textField.text = Std.string(Math.floor(Math.random() * 100000));
});
}
}
So now the problem is partial text formatting and autoSize=right
And autoSize=center.
Partial formatting also behaves similar on windows target (and other native targets too, supposedly).
Additionally, htmlText with <font color> tags can have the same issues.
In the latest OpenFL dev the bugs still present…
Probably fixed locally 
I’m working on pushing changes, I’m just a bit strapped for time right now.
Thanks for the test case, I’ll try it out and see.
This was a new bug for me. I don’t want to push this to dev just yet, since it might have broken something else.
@Neborya However, do you need this change now, or can you wait until I test it a bit?
The last e of here is dark 
I can wait if needed.
It should be dark in the code you posted. You changed the color of the space and the next 3 letters (character 5 up to but not including character 9).
But ok, I’ll do a bit of testing on it.