Windowed and NoBorder render at display resolution

[oomek]

I don't know if it was intentional, or not, but in both windowed modes when you set the window to the size smaller than the current resolution the window is rendered at full monitor resolution. The fe.layout.width and height also return the display resolution. If you want to test how layout is adapting to different resolutions, for example 1280x1024, on 1920x1080 screen fonts have sampling artiffacts and the dimensions of elements set in pixels are wrong. I have a fix ready to pull in case you confirm that this wasn't intentional and should be corrected.

[oomek]

[zpaolo11x]

I think this is intentional, I always set both window size and layout size to a reduced size to see how it looks on smaller resolutions...

[oomek]

Even if you do so you still get at least text rendering with heavy aliasing and kerning errors. Do some screenshots in your native display resolution and for example 800x600 and compare.

Here is a video comparing the AM 2.5.1 and my daily build with a potential fix applied: https://youtu.be/7d8OI1X5WvY

Edit: Sorry for ultrawide format, I've reuploaded a cropped video.

[oomek]

[oomek]

There is another issue I've fixed, which was bothering me for a long time. When you set your window mode to windowed or borderless and have for example 800x600 in window.am this gets reseted to the desktop resolution if you switch mode to fullscreen or fill screen, so you have to edit the file again.

[oomek]

Here is my suggestion of changes https://github.com/mickelson/attract/pull/513

[zpaolo11x]

Thinking about a workaround for this issue. and wanted to share this thought: right now my theme adapts to screen resolution, and as you said in window mode it doesn't adapt since AM still renders everything at screen res.

Now if we fix that and the layout is rendered at the window resolution, there must be a way for me to get this value and adapt the layout to that value, for example the ScreenWidth and ScreenHeight properties should reflect the actual window resolution, not be stuck at screen resolution.

[oomek]

This is the part of my fix. In windowed modes fe.layout.width/height will return a window size, but can be overridden as before.

[zpaolo11x]

This is the part of my fix. In windowed modes fe.layout.width/height will return a window size, but can be overridden as before.

So if you override the fe.layout.width the window will change size accordingly? Otherwise it would be better to have ScreenWidth, a read-only value, to get the actual window/screen resolution

[oomek]

No, it will not. Overriding the w&h of the layout is neccessary for layouts that are constructed on the pixel basis. In this situation the positioning of elements is based on the specified w&h but fonts are rendered based on the renderwindow size, that's why they look bad without my fix. There will be no text aliasing after my fix, whether you set your custom fe.layout.width&height or not.

[oomek]

Additionally no layout size overriding will be neccessary to test in other resolutions. You just set the desired window size in window.am, set the window mode to Windowed or No Border and that's it. I hope all is clear now. Dynamic resizing is also possible, but I need to see if I can make it without triggering the layout reload signal.

[zpaolo11x]

It's clear, I do most resolution tests in fullscreen just changing the flw and flh, I think this will be possible even with the modification. It would be great to be able to redefine window size withuot having to modify window.am, from the layout, even if a redraw is necessary

[oomek]

Regarding adjusting the window size based on the specified layout width and height is something that I also need to think about. If there are no situations when it breaks certain usage scenarios I will add this as well. Of course it will not affect the Fullscreen and Fillscreen modes

[oomek]

Fixed in https://github.com/mickelson/attract/pull/528