-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[rcore][desktop_glfw] Reviewed ToggleFullScreen()
, ToggleBorderlessWindowed()
and FLAG_WINDOW_HIGHDPI
issues
#4151
base: master
Are you sure you want to change the base?
Conversation
should fix issue raysan5#4149 Linux MATE : tested Macos : tested Windows : need confirmation --- thanks to @SoloByte and to @paulmelis for their help and efforts to solve this issue
Work perfect on Linux wirth X11 Needs confirmation on Linux Wayland, MacOS, and Windows.
ToggleBorderlessWindowed()
on Linux and MacosToggleFullScreen()
, ToggleBorderlessWindowed()
and FLAG_WINDOW_HIGHDPI
issues
Here are some notes (and TODO) before I forget : Ubuntu + Wayland +
|
hardware fullscreen mode | windowed fullscreen mode |
---|---|
ToggleFullscreen() |
ToggleBorderlessWindowed() |
SetWindowState(FLAG_FULLSCREEN_MODE) |
SetWindowState(FLAG_BORDERLESS_WINDOWED_MODE) |
ClearWindowState(FLAG_FULLSCREEN_MODE) |
ClearWindowState(FLAG_BORDERLESS_WINDOWED_MODE) |
InitWindow( 0 , 0 ) |
|
SetConfigFlags(FLAG_FULLSCREEN_MODE); InitWindow( w ,h ); |
SetConfigFlags(FLAG_BORDERLESS_WINDOWED_MODE); InitWindow( w ,h ); |
"Can't reproduce. Fixed ?" list
- Paulmelis said : When the FLAG_WINDOW_HIGHDPI flag is not set the MATE menu and window bar at top and bottom respectively stay visible sometimes. And in other cases the raylib window fails to gain focus after switching to fullscreen with F.
"Can't fix ? / Known issues" list
- on Wayland : GLFW 3.4 does not yet support setting the position of the mouse cursor, so
SetMousePosition()
won't work as expected. - on Ubuntu + Wayland : as it not possible to know the position of a window,
GetCurrentMonitor()
will always return the last monitor that was associated to the window usingSetWindowMonitor()
. If the user moves the window manually from one monitor to an other, this value won't be updated automatically. - on Ubuntu : there seems to be no real "hardware fullscreen mode".
ToggleFullscreen()
seems to have the exact same effect thanToggleBorderlessWindowed()
. Duno if it specific to my graphics drivers, or if it this way for all computers running Ubuntu, or if it is related to the fact that the frame rate is left toGLFW_DONT_CARE
. - on Linux Mint + Cinnamon (X11) :
GetWindowScaleDPI()
returns{ 1.0 , 1.0
} when display is 75% and 100%, and returns { 2.0 , 2.0 } when display is 125%, 150%, 175% and 200%. Problem must comes from GLFW or Cinnamon. - on Linux Mint + Cinnamon (X11) : the display resolution is not restored from hardware fullscreen mode.
- each version of MS Windows might have a very slightly inconsistent behavior regarding
FLAG_WINDOW_HIGHDPI
andFLAG_WINDOW_RESIZEABLE
. This is because GLFW does not init the window with the same algorithm of DPI awareness : https://github.com/raysan5/raylib/blob/996f50393ec51fa33b361546986afc9762849a76/src/external/glfw/src/win32_init.c#L692C1-L697C30 - on MS Windows 11 : on multi monitor setup, if each monitor has a different DPI scale, and if the Raylib window is resizable, moving the window from one monitor to an other multiple times might shrink it a little. Same might happen if toggling from fullscreen mode many times.
ToggleFullscreen()
: on sluggish computers, when toggling from a low resolution fullscreen mode (like 640x480) back to windowed mode, the previous position of the window might not be restored correctly because GLFW might try to restore the window size and position before the OS had time to fully restore the previous monitor resolution and the desktop UI (menu-bar). The consequence is that the size of the desktop might appear too small to GLFW to restore the window.ToggleFullscreen()
: on my Linux X11, if VirtualBox is running, the Raylib's fullscreen window fails to keep the focus and is minimized.
Test source code :#include <stdio.h>
#include "raylib.h"
#include "raymath.h"
void update();
void draw();
int main( int argc , char **argv )
{
// SetWindowState( FLAG_MSAA_4X_HINT );
SetConfigFlags(FLAG_WINDOW_HIGHDPI); // <======= ???
// SetConfigFlags(FLAG_FULLSCREEN_MODE);
// SetConfigFlags(FLAG_BORDERLESS_WINDOWED_MODE);
SetConfigFlags(FLAG_RESCALE_CONTENT); //!\ HIGHLIY EXPERIMENTAL FLAG disable it for backward compatible mode
// SetConfigFlags(FLAG_RESCALE_CONTENT_LINEAR); //!\ HIGHLIY EXPERIMENTAL FLAG disable it for backward compatible mode
// SetConfigFlags(FLAG_TEXT_LINEAR_FILTER);
SetConfigFlags( FLAG_WINDOW_RESIZABLE );
InitWindow( 700 , 500 , "Test" );
// InitWindow( 500 , 0 , "Test" ); // <== full screen windowed mode
// InitWindow( 0 , 500 , "Test" ); // <== full screen windowed mode
// InitWindow( 0 , 0 , "Test" ); // <== full screen windowed mode
if ( ! IsWindowReady() )
{
// Platform initialization probably failed
return -1;
}
// ClearWindowState( FLAG_VSYNC_HINT );
// SetMouseOffset( 10, 10);
// SetMouseScale( 0.5 , 0.5 );
SetTargetFPS( 60 );
while( ! WindowShouldClose() )
{
update();
BeginDrawing();
{
ClearBackground( GRAY );
draw();
}
EndDrawing();
}
CloseWindow();
}
void update()
{
if ( IsKeyPressed( KEY_ZERO ) )
{
SetWindowMonitor(0);
}
else
if ( IsKeyPressed( KEY_ONE ) )
{
SetWindowMonitor(1);
}
else
if ( IsKeyPressed( KEY_F ) )
{
// SetWindowSize( 1280 , 720 );
ToggleFullscreen();
printf("Toggled, screen now %d x %d\n", GetScreenWidth(), GetScreenHeight());
printf("Toggled, render now %d x %d\n", GetRenderWidth(), GetRenderHeight());
}
else
if ( IsKeyPressed( KEY_G ) )
{
SetWindowState(FLAG_FULLSCREEN_MODE);
}
else
if ( IsKeyPressed( KEY_B ) )
{
ToggleBorderlessWindowed();
printf("Toggled, screen now %d x %d\n", GetScreenWidth(), GetScreenHeight());
printf("Toggled, render now %d x %d\n", GetRenderWidth(), GetRenderHeight());
}
else
if ( IsKeyPressed( KEY_N ) )
{
SetWindowState(FLAG_BORDERLESS_WINDOWED_MODE);
}
else
if ( IsKeyPressed( KEY_C ) )
{
ClearWindowState(FLAG_FULLSCREEN_MODE);
ClearWindowState(FLAG_BORDERLESS_WINDOWED_MODE);
}
else
if ( IsKeyPressed( KEY_X ) )
{
MaximizeWindow();
}
else
if ( IsKeyPressed( KEY_V ) )//|| !IsWindowFocused() )
{
MinimizeWindow();
}
else
if ( IsKeyPressed( KEY_R ) )
{
RestoreWindow();
}
else
if ( IsKeyPressed( KEY_S ) )
{
if ( IsWindowState(FLAG_RESCALE_CONTENT) )
{
ClearWindowState(FLAG_RESCALE_CONTENT);
}
else
{
SetWindowState(FLAG_RESCALE_CONTENT);
}
}
else
if ( IsKeyPressed( KEY_T ) )
{
if ( IsWindowState(FLAG_TEXT_LINEAR_FILTER) )
{
ClearWindowState(FLAG_TEXT_LINEAR_FILTER);
}
else
{
SetWindowState(FLAG_TEXT_LINEAR_FILTER);
}
}
else
if ( IsKeyPressed( KEY_KP_5 ) ) { SetMousePosition( GetScreenWidth()/2 , GetScreenHeight()/2 ); }
else
if ( IsKeyPressed( KEY_KP_7 ) ) { SetMousePosition( 0 , 0 ); }
else
if ( IsKeyPressed( KEY_KP_9 ) ) { SetMousePosition( GetScreenWidth() , 0 ); }
else
if ( IsKeyPressed( KEY_KP_3 ) ) { SetMousePosition( GetScreenWidth() , GetScreenHeight() ); }
else
if ( IsKeyPressed( KEY_KP_1 ) ) { SetMousePosition( 0 , GetScreenHeight() ); }
}
void draw()
{
Vector2 mouse = GetMousePosition();
int sw = GetScreenWidth();
int sh = GetScreenHeight();
int rw = GetRenderWidth();
int rh = GetRenderHeight();
Vector2 dpi = GetWindowScaleDPI();
int monitor = GetCurrentMonitor();
int mw = GetMonitorWidth( monitor );
int mh = GetMonitorHeight( monitor );
Rectangle screenRect = { 0.0 , 0.0 , sw , sh };
Rectangle renderRect = { 0.0 , 0.0 , rw , rh };
// Draw the border of the screen :
DrawRectangleRec( screenRect , RAYWHITE );
DrawRectangleLinesEx( screenRect , 4.0f , RED );
DrawRectangleLinesEx( renderRect , 4.0f , GREEN );
// Draw the text NOT in the center :
int font_size = 20 ;
int y = 0 ;
DrawText( TextFormat( "Mouse : %.2f x %.2f / %d x %d" , mouse.x , mouse.y , GetMouseX(), GetMouseY() ) , 10 , y+=font_size , font_size , BLACK );
DrawText( TextFormat( "Screen : %d x %d" , sw , sh ) , 10 , y+=font_size , font_size , BROWN );
DrawText( TextFormat( "Render : %d x %d pixels" , rw , rh ) , 10 , y+=font_size , font_size , DARKGREEN );
DrawText( TextFormat( "Monitor[%d] : %d x %d pixels" , monitor , mw , mh ) , 10 , y+=font_size , font_size , DARKBLUE );
DrawText( TextFormat( "DPI : %f x %f" , dpi.x , dpi.y ) , 10 , y+=font_size , font_size , BLACK );
y+=font_size;
DrawText( TextFormat( "screenRect : %f x %f" , screenRect.width , screenRect.height ) , 10 , y+=font_size , font_size , RED );
DrawText( TextFormat( "renderRect : %f x %f" , renderRect.width , renderRect.height ) , 10 , y+=font_size , font_size , GREEN );
y+=font_size;
DrawText( IsWindowFullscreen() ? "FULLSCREEN MODE" : "" , 10 , y , font_size , BLUE );
DrawText( IsWindowState( FLAG_BORDERLESS_WINDOWED_MODE ) ? "BORDERLESS WINDOWED MODE" : "" , 10 , y , font_size , PINK );
DrawText( !IsWindowFullscreen() && !IsWindowState( FLAG_BORDERLESS_WINDOWED_MODE ) ? "Windowed mode" : "" , 10 , y , font_size , YELLOW );
y+=font_size;
DrawText( IsWindowFocused() ? "HAS FOCUS" : "does not have focus" , 10 , y+=font_size , font_size , ORANGE );
DrawText( IsWindowState(FLAG_RESCALE_CONTENT) ? "RESCALE CONTENT" : "does not rescale content" , 10 , y+=font_size , font_size , DARKPURPLE );
DrawText( IsCursorOnScreen() ? "CURSOR on SCREEN" : "cursor NOT on screen" , 10 , y+=font_size , font_size , DARKGREEN );
y+=font_size;
DrawText( "[F] ToggleFullscreen()" , 10 , y+=font_size , font_size , GRAY );
DrawText( "[G] SetWindowState(FLAG_FULLSCREEN_MODE);" , 10 , y+=font_size , font_size , GRAY );
y+=font_size;
DrawText( "[B] ToggleBorderlessWindowed()" , 10 , y+=font_size , font_size , GRAY );
DrawText( "[N] SetWindowState(FLAG_BORDERLESS_WINDOWED_MODE);" , 10 , y+=font_size , font_size , GRAY );
y+=font_size;
DrawText( "[C] ClearWindowState(FLAG_xxx_MODE);" , 10 , y+=font_size , font_size , GRAY );
y+=font_size;
DrawText( "[X] MaximizeWindow();" , 10 , y+=font_size , font_size , GRAY );
DrawText( "[V] MinimizeWindow();" , 10 , y+=font_size , font_size , GRAY );
DrawText( "[R] RestoreWindow();" , 10 , y+=font_size , font_size , GRAY );
y+=font_size;
DrawText( "[T] toggle `FLAG_TEXT_LINEAR_FILTER`" , 10 , y+=font_size , font_size , GRAY );
// Draw a software mouse cursor for debug purpose :
DrawCircleSector( mouse , 30, 45, 90, 1, WHITE);
DrawCircleSectorLines( mouse , 30, 45, 90, 1, BLACK);
// Draw a target :
DrawLine( GetMouseX() , 0 , GetMouseX() , sh , BLUE );
DrawLine( 0 , GetMouseY() , sw , GetMouseY() , BLUE );
// Center of screen :
DrawLine( sw/2-10 , sh/2, sw/2+10, sh/2, RED );
DrawLine( sw/2 , sh/2-10, sw/2, sh/2+10, RED );
}
|
@SuperUserNameMan thanks for all the work to fix all of this :) When exiting fullscreen with |
#3929 maybe related as well? |
Just tested your testing code above. The When the |
Yes, because The size of the render is set to the hardware resolution that is arbitrarily picked by GLFW to fit your current window's content dimensions. For now, the only way to somehow influence the choice made by GLFW, is to resize your window to an hardware monitor resolution of your choice before calling SetWindowSize( 1280 , 720 );
ToggleFullscreen(); 1280x720 is an hardware resolution that has great chances to be supported on most monitor and graphics cards, so you'd have great chances that GLFW gives you this fullscreen resolution.
Currently trying to find a computer with a Wayland desktop. |
Note that I'm not running wayland, but plain X server |
This shows another problem I think. Right now (even with your fixes) if you toggle the fullscreen with a screen size that is not supported by the monitor, glfw will pick the closest one and activate the fullscreen with the new size. This means that CORE.Window.screen.width & CORE.Window.screen.height will not be correct until the window resize callback will be called. One solution to this could be to get all supported resolutions from the monitor and then:
There is also a fundamental question about fullscreen mode. The only thing I found the high dpi flag does on window initialization is this. If I can clear the high dpi flag and make fullscreen use the non-scaled resolution then this question is irrelevant. ExplanationIf I make a game and the user selects fullscreen mode with 4k resolution on a 4k monitor than I might want the screen size & render size to be the 4k and not scaled by the dpi. (Because my UI system might take care of scaling already) |
If i understood correctly, and if my previous tests were correct, the problem is that once we set this, we can't disable it unless we destroy and recreate the window (but we might lose the opengl context in the process if i understood correctly). That's why i was strongly claiming that the programmer should choose between
Yeah, that seems to cause some unexpected delays and lags with unexpected side-effects that i'm having some difficulties to grasp yet ... There is also some unexpected behaviors on my LinuxMint + Cinamon desktop + 4K TV that i'm unable to fix or workaround currently ... |
For unknown reasons, this does not restore the previous monitor/desktop resolution on my X11 Cinamon desktop. edit: works fine with X11 MATE desktop. |
There is also ancient code for "windowed fullscreen" that might require to be removed or fixed: edit: actually, that is only when |
edit |
The more i'm digging into the code, the more i have the feeling that i'm going to do the overhaul i did not want to do ......... I need to do a map from |
Trying to go straight forward from one fullscreen mode to another make things more complicated to control. Seems a full loop is required when trying to change fullscreen modes and window size properly for now. Maybe will restore the ability to jump from one fullscreen mode to another when more cleaning will be done deeper in the rabbit hole.
Call `WindowSizeCallback()` manually so we don't have to wait for after the next `EndDrawing()` to have access to up to date `GetScreenWidth()` etc value.
In that case, if your UI system already take care of DPI scaling (probably using |
I hoped that your fix solved all the problems but in reality I was pretty sure an overhaul is needed because otherwise those problems would have already been fixed. Right now it just feels like a rabbit hole of endless despair we went down into and the only way to get out is to start from the beginning ;)
That is a really good idea! If I find the time I might also do something like this. Maybe for glfw as well how the window system is done in the docs. Another problem here might be if high dpi flag is disabled:
If
Yes absolutely. I will have to test it and I will report back on this. (with probably more questions than answers ...) I don´t have a lot of time over the weekend, so if don´t respond it is because of that 🙃 |
Yes I know but it is the simplified version of just finding the closest resolution. (does not take aspect ratio into account) Doing this before setting Fullscreen is probably always a good idea. (in a potentially new system as well as the current system) |
fix issue mentioned by @paulmelis ?
|
Yep, that will have to be separate PR because it would involve all platforms.
There is no
I'm going to try both and see if it solve an issue on Wayland. |
No but GLFW has it and it might be better in the future if the framebuffer callback deals with framebuffer stuff and the window size callback with window size stuff? Also I probably have to use it for macOS. When the window is resized on macOS the window size callback is called with the actual window size but in your pipeline you often call the window size callback with the framebuffer size instead. |
…on on Wayland As a general rule, Raylib API functions should not be used internally by the platform code, because these functions may be tuned for cross-platform consistency so they return consistent data relevant to the user perspective, and not to the platform code perspective. --- I don't know if it is a GLFW bug, but on Wayland, the `WindowSizeCallback()` is not called when the window is restored from a fullscreen mode, and I had to workaround that. As discovered by @SoloByte, using `glfwSetFramebufferSizeCallback()` instead of `glfwSetWindowSizeCallback()` solves this issue on Wayland, and deprecate the workaround.
Sir, i think you solved the Wayland issue i had to workaround. I confirm that on Wyalnd, it is better to use the On other platforms (X11, Win10 and Win11), it seems to make no difference, so I made it default for all. I hope it will work out of the box for MacOS too. |
TODO : make further tests on all the OS i have access to and compare returned results in different scenario and see how coherent it is in relation to the active DPI scale and rescaling. (#4151 (comment)) My brain is already depleted, going for a nap. |
I think this is the main difference between x11/win10/win11 and macOS Wayland that in the former the window size and framebuffer size are always the same per default and in the latter the os sometimes scales the framebuffer for you 👍 |
I've just noticed i accidentally merged some changes involved in pending #4164. I should be more careful with my copy/paste X-S |
… part 1 When in `FLAT_RESCALE_CONTENT` mode, the default "nearest pixel" filter of the texture font is ugly sometimes. So this change adds `FLAG_RESCALE_CONTENT_LINEAR` and `FLAG_TEXT_LINEAR_FILTER` to offer more control. `FLAG_TEXT_LINEAR_FILTER` can also be used to disable the linear filtering of `FLAG_WINDOW_HIGHDPI`.
When in `FLAT_RESCALE_CONTENT` mode, the default "nearest pixel" filter of the texture font is ugly sometimes. So this change adds `FLAG_RESCALE_CONTENT_LINEAR` and `FLAG_TEXT_LINEAR_FILTER` to offer more control. `FLAG_TEXT_LINEAR_FILTER` can also be used to disable the linear filtering of `FLAG_WINDOW_HIGHDPI`.
…ng - part 3 When in `FLAT_RESCALE_CONTENT` mode, the default "nearest pixel" filter of the texture font is ugly sometimes. So this change adds `FLAG_RESCALE_CONTENT_LINEAR` and `FLAG_TEXT_LINEAR_FILTER` to offer more control. `FLAG_TEXT_LINEAR_FILTER` can also be used to disable the linear filtering of `FLAG_WINDOW_HIGHDPI`.
new
|
|
`IsCursorOnScreen()` returns true only if the cursor is over the `CORE.Window.screen` surface, so it works correctly when `FLAG_CONTENT_RESCALE` is enabled.
|
…State()` i was trying to follow the code-style involved in these two function, but it confused me so much that it caused a bug i could not identify. So I just rewrote them using helpers, and the bug disappeared.
HELP REQUIRED : MS Windows 11 + TV as monitorI'm having an issue between my Windows 11 laptop and my 4K TV, and I would like to know if it is limited to my hardware, or if it is a general issue. Issue description : on Windows 11, when the TV is set as the unique monitor, when I My TV is know to have a firmware bug with low resolution (thank you Philips and TCL cooperation), but the issue i'm describing only happens specifically with Win11 and this TV. Other OS works fine with this TV, and other monitor work fine with this Win11. Help required : Setup your TV as unique monitor in 4K or 1080p, then run the example code above, press edit note that vanilla version of Raylib also exhibit the same issue. |
I'm checking this PR and I'd like to note that it is moving in a rabbit hole redesign that I won't be able to maintain... Please note that at this state I'm hardly considering merging it. |
Thanks you for warning me. Because I think i've already spent way too much time and energy into it anyway, and this is leading me into debugging GLFW (cause of the mentioned issue above), which is way beyond what i wanted to do initially. In its current state, this PR managed to solve many issues mentioned in the original message, and any extra flag I added to Beside the Win11 issue mentioned just above, and beside the pending MacOS fixes, it works well on every platforms i tested : Win10, Linux + X11, Linux + Wayland. If you don't merge it, maybe the code could serve as a study for individuals PR to fix issues in vanilla Raylib code in a manner that you'll be able to maintain. |
After a lot of testing I think on macOS there is no proper way to disable high dpi scaling. It is possible to workaround but it is not nice nor easy to maintain. My proposition would be (to allow this PR to be merged or a similar new one)
I definitive answer about this would be nice because I am not going to try to fix anything if it is not going to be merged 🙃 In my opinion the best way to go about it is to reduce complexity and try to create consistency across platforms. (The points above would do that) As a side note: |
Are you all refering to the If yes : I don't know if the way i reimplemented the effect enabled by With these two flags enabled, even the 3D VR stereo example that i was the most afraid of worked out of the box, so i was very optimitic for the rest of the compatibility. Personally, i find this It does not even change the default behavior of Raylib if you don't enable it. The code changes involved are fully backward compatible and are, most of the time, required by the Windows's and X11's implementation of Also, this new So, if you really want to simplify this PR for the sake of code maintainability by removing If I kept trying to fix each issues independently without digging deeper into the code, I doubt i'd have managed to solve them all at once on all platforms i had access to. If you want to go tiny PR after tiny PR, it might work, but i think you'd unavoidably have to dig your hole from the inside up to the surface. But maybe i'm being too pessimistic.
Which one are you trying to disable ? OS's or Raylib's ? If you're talking about the effects enabled by |
I don't exactly know what you are refering to ? I was talking about dpi scaling and raylib already does this automatically if you enable the high dpi flag.
I can not implement how raylib behaves when the high dpi flag is disabled. So like Wayland basically and everything works pretty much fine when I use the non high dpi branch of your PR but it does not make it consistent with the rest... Example: Right now I am trying to figure out what would be merged by @raysan5. Because I don't want that our work was pretty much for nothing but I also understand that it is a lot of changes and that we have to find some common ground here. @SuperUserNameMan I also understand that you didn't do it for the fun of it and it was probably the easiest way of getting everything to work. So basically we should decide what raylib should take care of and what it should not. That the flag RESCALE_CONTENT is easier for beginners when they write a hardcoded UI I can understand but on the other hand without the flag RESCALE_CONTENT it is easier to understand why a hardcoded UI can create a lot of problems. For me personally a functioning cross-platform window system is important. (Fullscreen, Borderless Fullscreen, Maximize, Minimize, Focusing Windows, Restoring Windows, Moving Windows to different Monitors) |
Look, if the OS enforces DPI scaling, there is nothing you can do. The only thing we can do is NOT TO DO IT TWICE (once by the OS's, and once by Raylib) . So, in the You'll still have you window DPI rescaled by the MacOS, but that's the way it is. |
For the rest of your comment, regarding the future of this PR, I don't mind if @raysan5 prefers to restart the overhaul from scratch to ease code maintainability according to Raylib's standards and code-conventions. It's better to have a code that you can maintain and understand because you wrote it, than a code wrote by someone else that you can't maintain because you don't understand why the hell this and that was added or removed or changed. As far as i'm concerned, I'll still be able to use this code for the project i was working on just before. And when Raylib will be fixed, maybe i'll switch back to edit : oh ! and there is this ugly GLFW bug that i narrowed down this morning that might need to be fixed if some users complains about Raylib not going fullscreen and terminating when their Windows 11 laptop is connected to some external displays set as single main monitor. It was related to the |
I wasn't going to do that anyway ;) It is just something users of raylib need to be aware of. And the main problem right now is that if you enable the high dpi flag then the DPI scaling is consistent and works but the the image is still blurry because of the linear filter (that in the current master you can not disable or get rid of).
Yes this is the best way to do it.
I absolutely understand that. My problem is that this whole thing started because the fullscreen and borderless fullscreen are not working correctly in some way on most platforms. |
ToggleFullScreen()
, ToggleBorderlessWindowed()
and FLAG_WINDOW_HIGHDPI
issuesToggleFullScreen()
, ToggleBorderlessWindowed()
and FLAG_WINDOW_HIGHDPI
issues
dont merge it yet
You can test this PR again, code updated with new pipeline.
should fix most issues related to
ToggleFullScreen()
,ToggleBorderlessWindowed()
andFLAG_WINDOW_HIGHDPI
use a custom implementation of
SetupFramebuffer()
without affecting other platform backends and without changingrcore.c
(edit: well, i had to add some changes torcore.c
but they should not impact other platforms)adds a new experimental
FLAG_RESCALE_CONTENT
that keeps the size of what you requested inInitWindow()
and rescale and center it with borders. (so if you requested a 500x500 drawing surface, you'll allways have 500x500 drawing surface rescaled with the same aspect ratio that always fits inside the window or fullscreen window). see screen capture hereNeed confirmations and testing on :
I posted a minimal test source code in a message below. Press B for borderless fullscreen, and F for hardware fullscreen.
Here is a list of the concerned issues :
ToggleFullscreen()
not working as expected with HighDPI mode enabled #3972ToggleBorderlessWindowed()
can't restore decorations #4149thanks to @SoloByte and to @paulmelis for their help and efforts to solve this issue
(but i'd need you to test again the new update of this PR)