Quick Links: Gideros Home | Download Gideros | Developer Guide
WinRT resolution/sharpness issue
  • I'm working on a WinRT update using the latest Gideros build and I'm seeing a serious degradation in the sharpness of text. I have my project window size set to 1920 x 1080, the same as the logical dimensions. In the Gideros Player I see sharp text, but in the WinRT application the text looks like it was rendered at a much lower resolution and then stretched. The attached screen shot shows the WinRT application on the top and the Gideros Player below. In the same window size, the text (implemented via TextField objects) in the player looks very crisp, while in WinRT application window it looks quite blurry. Is this a bug, or some project setting I need to tweak?

    Paul

    player_vs_winrt.jpg
    976 x 1072 - 1M
  • I thought this might be an issue with TextField objects being scaled, etc, so I tried an experiment adding text in a large font over the Bird Animation sample. I added text using several values for TT font smoothing. The following screenshot shows the WinRT application on the left and the Gideros Player on the right, both at 1920x1080. The text in the Player is crisp, while the text in the WinRT application looks like it was rendered much smaller and then enlarged, creating very blurry edges. I get crisp TextFields in WinRT applications built with Gideros 2016.8.1, but not with more recent versions. Any ideas what may be going on and what can be done about it?
    TextField_test.jpg
    3840 x 1080 - 2M
  • Maybe there is no connection at all but are you using 3rd argument "true" in your font, which is antialising as far as i know. Maybe it will help.
    local font = Font.new("myfont.txt", "myfont.png",true)
     
    local textfield = TextField.new(font, "some text")
     
    stage:addChild(textfield)
  • Yes, I've tried with true, false, and numeric values. The anti-aliasing seems functional, but with or without it, the text appears as though it came from a screen shot taken on a very low resolution screen and then enlarged.
  • In my latest experiment I tried making a TextField with a font at a larger point size, then scaling it down to the desired size. That sharpens it up some, but it still looks pretty bad. I'd really like to use the current build to get the fix for high DPI screens (that issue is effecting some of my customers) but I just can't use this build for WinRT until I find a solution to the poor rendering of TextFields.
  • hgy29hgy29 +1 -1
    Maintainer
    Seems to be due to using XAML on WinRT. On such apps WinRT applies scaling depending on the screen's DPI, but the 3D canvas may not be the same size as the screen. I am not sure if we can do something to fix it, I will google a bit on the subject
  • hgy29hgy29 +1 -1
    Maintainer
    Found this in MS docs about SwapChainPanel, the component we use to render directx content in WinRT:

    "In order to maintain crisp vector rendering, you should listen for the CompositionScaleChanged event and query the CompositionScaleX and CompositionScaleY property values to account for the current UI scale, and potentially render again from DirectX. Otherwise XAML layout might do the scaling and your visuals might be degraded."

    Seems relevant to me...
  • Interesting... This issue wasn't present in Gideros 2016.8.1 - the TextFields are consistently sharp. I suppose the change could be in Gideros itself, or in the Windows libraries it links with.
  • hgy29hgy29 +1 -1
    Maintainer
    Yes, previously gideros used plain directx window, but it has been changed to Xaml composition to support ads
  • I suspected it was something like that. I'm guessing the change to XAML is also what provided the fix for the scaling issue on high-DPI screens.

    Do see see any hope for resolving this from within Gideros? I'd try to take it on myself but I know very little of the Gideros code, I'm not at all familiar with XAML and my DirectX experience is way out of date.

    If not, I'll start implementing a workaround. Since this issue seems to only effect TextFields (probably the only vector rendering at least in the app in question) I'm considering the workaround of displaying text through bitmaps rather than through TextFields, at least for the WinRT version. Some could be pre-rendered, but dynamic text would have to built from a collection of character bitmaps, probably through a class that uses the same interface as TextField. It would be a fair amount of work, and probably a bit of a performance hit, but it would eliminate the blurry text.

    Paul
  • hgy29hgy29 +1 -1 (+1 / -0 )
    Maintainer Accepted Answer
    I looked at gideros code and now I have a rather good idea of what should be done to (hopefully) fix the problem. I'll work on this next monday (along with QT multitouch)

    Likes: keszegh

  • Thank you so much!
  • PaulH +1 -1 (+2 / -0 )
    Member
    I can't tell you how much I appreciate your help on this. On second thought, maybe I can. I'll make a new donation when this fix becomes available. Thank you!

    Likes: hgy29, antix

  • hgy29hgy29 +1 -1
    Maintainer
    @PaulH, did you have a chance to check the version I sent you in PM ?
  • I didn't notice the PM - I'll try it out now. Thanks!
  • hgy29hgy29 +1 -1
    Maintainer Accepted Answer
    Could it be that your initial window size is small ? If so your fonts will be rendered to textures at low resolution by gideros, and they'll get blurry when window is enlarged. If this is the case, you can try to set a bigger initial window size in project properties.
  • PaulH +1 -1 (+3 / -0 )
    Member
    Yes, seems to be exactly what is happening. At the time the Lua code starts running, the WinRT window is very small. The fonts get created at the low resolution, then the automatic resize happens. I never see the window change size, so it may never even be rendered on the screen at the original size, but by the time the screen is large it's showing low resolution fonts and TextFields.

    I'll follow your suggestion from the PM and listen for the application resize event. I'll also wait a few milliseconds before creating fonts and TextFields on startup. That workaround will allow me to publish the update to get my customers the fix for the high-DPI screen issue.

    Thanks for your help! I've made a donation as promised. =)

    Paul

    Likes: hgy29, keszegh, talis

  • actually i also have this problem on qt windows export, i start my app windowed but usually user sets it to fullscreen and then my ttfont becomes blurry. could there be any way to make sure that font is rendered to be crisp at some target window size? for me it's not really feasible to start with a huge window as one might not have a screen that's big enough for it.
  • btw i tried to set a big initial window size and then call setWindowSize with a smaller size right after font is defined, but then the font is also rendered for the new window size for some reason (and so it is blurry at fullscreen).
  • PaulH +1 -1 (+3 / -0 )
    Member
    What I did was put the creation of my fonts into a function, and call that function when the game state changes (from the "loading" screen to main menu, for example.) The text "Loading..." is blurry, but a second later when the main menu appears, all the fonts have been rebuilt based on the current window size, so they're all sharp. You may want to try something similar.

    Hgy29 also suggested listening for the event APPLICATION_RESIZE, and then rebuild fonts and TextFields.

    Paul

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Login with Facebook Sign In with OpenID

In this Discussion

Top Posters