Are both haxe-ui and the flixel backend solid enough to use?

HaxeUI is always solid 🤙 HaxeUI-Flixel? Never used it . . .

im not entirely sure about haxeui-flixel if im honest, i think @User is using it, and maybe others, but i cant personally say that ive used it. I did run into some rendering issues last time i did use it, but i think it was my openfl / flixel that was out of date and breaking things. My advice would be to take it for a spin and evaluate it - i know would be interested in the results

Thanks guys, I'll give it a try, see how it goes

Hello there, I am currently evaluating Haxe with OpenFL/HaxeUI frameworks. I am testing some basic code using VSCode on Windows. I work on laptop where my default display configuration is set with 125% scale. When testing the build on any target (tried neko/windows/html5) the text fields aren't as sharp as expected. I've added in project.xml but that didn't change anything. I also played with Toolkit.scale parameter, turned on/off Toolkit.autoscale, but that didn't affect anything in rendering. I use Haxe 4.0.5 and installed haxelib are : actuate: [1.8.9] box2d: [1.2.3] haxeui-core: [1.0.25] haxeui-openfl: [1.0.7] hscript: [2.4.0] hxcpp: [4.0.64] layout: [1.2.1] lime-samples: [7.0.0] lime: [7.7.0] openfl-samples: [8.7.0] openfl: [8.9.6]

This is what I got when windows display scale is set to 150% You can see rendered texts are blurry and not as sharp as in window's title or in VSCode UI

The Main.hx code can be found here https://pastebin.com/XQFfp1pT

And this is what trace calls output https://pastebin.com/7ZQ6WBJH

Might be an OpenFL/Lime issue because a TextField suffers the same blurry render issue

I will be happy to read any input regarding this, thank you 🙂

Hi, so this is likely openfl/lime font issue as you mentioned, haxeui doesnt do any text rendering itself and delegates that type of stuff to a its host framework (via a backend, haxeui-openfl in your case). So, in this case its an openfl TextField. Which i presume looks exactly the same as the haxeui version. Text has always looked a little off to me in openfl (blurry, strangely spaced sometimes), but its getting better and better and has already improved and incredible amount over the years, and i believe even some other improvements ready to go in a branch (though i cold be imagining/wishing that). openfl html5 output is better iirc and some fonts work better than others. Also, nme font rendering is really smooth in windows at least (would be nice if openfl incorporated that system somehow).

Thank you @User I cross posted my message on openfl discord server to figure out what happens.

This is how it renders when operating system display scale is 100%, very sharp

interesting

is the first "This is a test" a normal, non-haxeui textfield?

> its the first "This is a test" a normal, non-haxeui textfield? @User Yes, pure openfl TextField

its hard to see exactly, but that suffers from the same blurring?

there is some interesting properties to play with:

> its hard to see exactly, but that suffers from the same blurring? @User It seems so

textfield.antialiasType, textfield.gridFitType, textfield.sharpness

gridFitType sounds interesting (you'd need to set antialiasType first)

> textfield.antialiasType, textfield.gridFitType, textfield.sharpness @User Already played with this but I'm quite sure it's related to stage.contentScaleFactor always staying to 1 or Capabilities.screenDPI always staying to 72

can you set contentScaleFactor?

Seems only available as a getter :/

not sure then to be honest

maybe an openfl expert might be able to shed some better light on it though

Was also wondering how Tootlkit.scale may have an effect on rendering.

I was trying to tweak it but nothing changed

Anyway thank you for all those helpful inputs

thats just used internally by haxeui itself... you can turn it off completely, but in essence it just multiplies the UI size by that value so it shouldnt really affect anything