TextField looks terrible on HTML5

nudpiedo · October 18, 2015, 7:44pm

Hello,

I continued translating some Elm examples and today I went through this element sorting/layout of an array of strings and I decided to represent them as TextFields because, they seem customizable and fit in a Sprite; however I am unable to render properly the text in Html5 or Neko; it always looks blurry and transform it to a bitmap makes it worse also in flash. AntiAlias makes some effects on Neko but also not really nice (I would not implement a text processor App in OpenFL).

See screenshot (left browser, down neko, right flash). For sure -dDom makes it better but I think it is not always a choice.

I tried to follow the trick exposed on this thread but then it also looks bad on flash and improves nowhere

Here the code I used, which is short and I hope easy to follow:

github.com

vrescobar/elm2openfl/blob/master/Visuals/layout/layout_simple/Source/Main.hx#L26


}


// Those side effects ara just plainly wrong in terms of Functional programming / Elm language
//   in additiof side effects on the original Sprite and so on
class Element {
    public static function show(a:Dynamic):TextField {
        var txt = new TextField();
        txt.text = Std.string(a);
        txt.autoSize = TextFieldAutoSize.LEFT;
        txt.setTextFormat(new TextFormat("Courier New"));
        txt.antiAliasType = AntiAliasType.ADVANCED;


        return txt;
    }


    public static function flow(dir:Direction, es:Array<TextField>):Sprite {
        var container:Sprite = new Sprite();
        // How to sort based on given direction
        var sorter = switch dir {
            case up: function(i, j) { return 1 ;};
            case down: function(i, j) { return 0 ;};

Does any one has any idea trick or solution for that? Am I forced to use -Ddom to get a better text rendering on the browser? I still didn’t try native targets, I hope tomorrow I can try Android/iOS.

singmajesty · October 19, 2015, 9:41pm

I just did a test with Courier New, embedded. Here is what I get:

textField = new TextField ();
textField.defaultTextFormat = new TextFormat ("Courier New", 40);
textField.width = 200;
textField.text = "QWERTY";
addChild (textField);

I also copied “cour.ttf” from my system into my assets directory. I’m not sure why it looks so different on your system. Perhaps the font is not embedded, perhaps it is being scaled?

nudpiedo · October 20, 2015, 10:28pm

Hello,

Did you compile your Html5 with -Ddom?

Embedding the font makes it look a bit better but still far away from any other program I run on my computer which is kind of vanilla macos 10.11 el capitan.

The whole code:

    var txt = new TextField();
    txt.defaultTextFormat = new TextFormat(Assets.getFont("fonts/cour.ttf").fontName, 12);
    txt.embedFonts = true;
    txt.autoSize = TextFieldAutoSize.LEFT;
    txt.text = Std.string(a);
    return txt;

(flash, html5 no dom, neko, cpp)

With size 40 it looks much better but that’s not the size I want, so if I scale to something smaller in neko and CPP looks almost as good as flash; in the other hand html5 becomes just unusable…

txt.scaleX = txt.scaleY = 0.25;

I use a retina display, and together with those scaling imrpovements I though it could it be that the density of pixels or DPI is detected wrong, the only I found on the topic is this API which in the comment speaks only about the Flash target:

    trace(openfl.system.Capabilities.screenDPI);

It prints:

Neko: 0
Flash: 72
Html5: 96
Cpp: 0

Any idea? how can I verify my setup?

singmajesty · October 20, 2015, 10:50pm

Yeah, I have a feeling this is related to retina resolution. I showed you what it looked like on my system – pretty consistent

There is an OS X retina fix in OpenFL on GIT right now, going out soon in a new release, it may be related?