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);
});
}
}
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.
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:
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 ?
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));
});
}
}
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.