Our tests so far only covered desktop PCs with 1920x1080 monitors, we haven’t looked into mobile phones, yet. See the first post for the comparison of browsers.
<window allow-high-dpi="true" /> fixed all blurry fonts and images in mobile browsers but that’s only for mobile. I rarely have blurry fonts on desktop (well, except on IE11 but it depends on the fonts). What font extensions do you use and what fonts?
Also worth checking if you have <window width="" height="" /> set to anything
Hi,
thanks for your response and sorry for the delay. We are already using <window width="" height="" /> and it’s not helping. Also <window allow-high-dpi="true" /> does not help for us in the browser. Maybe there is a problem with the web fonts we received from our licenser, we will work on a standalone test without OpenFL and see if we will have the same problems. The font we use is VAG Rounded Cyrillic, we received the Web Fonts directly from our licenser because we are not allowed to generate them ourself based on the license.
Anyhow, are you considering to implement the Distance Field Rendering algorithm on Fonts?
I can’t say when we’ll be able to work on doing GL-based TextField. It would be great, but the biggest concern is decided how (or in what way) we generate the font atlases. Then I think the rendering part should probably fall into place
1 Like
Could we use ATF generator to generate mipmap textures? I don’t know the distribution license though…
Well, I think the issue here is a logical one. All font glyphs? Generate only the ones needed on the fly? Generate one size, multiple sizes? So on.
Could we delegate to the developer using some parameters in config.xml? Maybe “on the fly” is too much! (could be cpu intensive right?)
Well, my biggest concern is the amount of texture memory. Every glyph won’t work for large fonts, but rendering to the texture every time we encounter a new glyph may or may not work well. We would not want to draw it fresh every single time, so we need to cache the result in some way. Not sure what Cairo is doing now, I think it uses some form of cache
Relevant to this discussion - the code and ideas there might be worth a look. The site overall has been a pretty solid reference for me during my adventures into open/webgl
a quote from it:
The other big issue which I’m not going to cover is that textures have a limited size but fonts are effectively unlimited. If you want to support all of Unicode so that you can handle Chinese and Japanese and Arabic and all the other languages, well, as of 2015 there are over 110,000 glyphs in Unicode! You can’t fit all of those in textures. There just isn’t enough room.
The way the OS and browsers handle this when they’re GPU accelerated is by using a glyph texture cache. Like above they might put textures in a texture atlas but they probably make the area for each glpyh a fixed size. They keep the most recently used glyphs in the texture. If they need to draw a glyph that’s not in the texture they replace the least recently used one with the new one they need. Of course if that glyph they are about to replace is still being referenced by a quad yet to be drawn then they need to draw with what they have before replacing the glyph.
1 Like
That’s an interesting approach, sounds helpful!
2 Likes