Skip to content
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

Editor window doesn't display properly #453

Open
AntarEspadas opened this issue May 11, 2023 · 19 comments
Open

Editor window doesn't display properly #453

AntarEspadas opened this issue May 11, 2023 · 19 comments

Comments

@AntarEspadas
Copy link

After initializing a new Fyrox project with fyrox-template init --name fyrox_test --style 2d and running the editor with cargo run --package editor --release I encountered an issue where the editor window wouldn't display properly, with the window being cut off by black bars (See image below).

I'm on Arch Linux. Any help would be appreciated.

image

@IceGuye
Copy link
Contributor

IceGuye commented May 12, 2023

What is your desktop environment and display server? If it's wayland, try on the X11 and see how it goes.

@mrDIMAS
Copy link
Member

mrDIMAS commented May 12, 2023

I made a quick fix (?), could you please check again on latest? (Use this guide to update the engine).

@AntarEspadas
Copy link
Author

I use xorg with KWin.

The fix does not seem to have worked for me

image
image

@mrDIMAS
Copy link
Member

mrDIMAS commented May 12, 2023

What will happen if you try to resize the window manually, will this fix the bug?

@AntarEspadas
Copy link
Author

The problem persists regardless of window size

image
image
image

@mrDIMAS
Copy link
Member

mrDIMAS commented May 12, 2023

Do you have hi-dpi monitor or maybe you have system scaling more than 100%? I'm trying to collect as much info as possible to find the actual cause of the bug.

@AntarEspadas
Copy link
Author

That's it! I use a custom font dpi of 85, reverting to the default fixes the issue.

With that said, I would rather not have to change my configuration just to run the editor.

@IceGuye
Copy link
Contributor

IceGuye commented May 12, 2023

With that said, I would rather not have to change my configuration just to run the editor.

You can run the fyrox editor with an environmental setting:

QT_FONT_DPI=96 cargo run --package editor --release

@AntarEspadas
Copy link
Author

This does not seem to work. While specifying the dpi with QT_FONT_DPI=96 seems to work on other applications, like Dolphin and Firefox, it doesn't seem to have any effect on the editor

@mrDIMAS
Copy link
Member

mrDIMAS commented May 13, 2023

Thanks! Now I understand what I did wrong - I didn't take DPI scaling into account when creating/resizing GL surface. I'll try to fix this today.

@mrDIMAS
Copy link
Member

mrDIMAS commented May 13, 2023

@naratna could you please re-check if the bug is fixed?

@AntarEspadas
Copy link
Author

Unfortunately, this does not fix the issue

@mrDIMAS
Copy link
Member

mrDIMAS commented May 13, 2023

Could you please run the 3rd_person example and check if the issue also reproduces there? I cannot reproduce the issue (I'm on Windows), so it is kinda hard for me to find the actual cause.

@jpaugh
Copy link

jpaugh commented Jan 30, 2024

I'm getting the same issue on Ubuntu Linux, and I also have DPI scaling. (I'm using the "nightly" from github.) FWIW, It seems that I can interact with the UI in the black parts. Like, I can drag the inspector into the black area and back again. It seems like all the controls are there, but they're getting clipped somehow. (I'm too unfamiliar with Fyrox to confirm this.)

I get the same issue with the standalone editor, too.

I've confirmed that QT_FONT_DPI= 96 or 100 or whatever has no effect; and that setting the DPI scaling to 100% system wide fixes the issue

$ gsettings set org.gnome.desktop.interface text-scaling-factor 1.0

FWIW, setting the scale factor to .99 causes the black area to shrink. So, yeah, it's likely a scaling issue.
fyroxed_bug_text-dpi-scaling

@jpaugh
Copy link

jpaugh commented Jan 30, 2024

Could you please run the 3rd_person example and check if the issue also reproduces there? I cannot reproduce the issue (I'm on Windows), so it is kinda hard for me to find the actual cause.

Where would I find that example? I couldn't find anything in the fyrox source or the website referring to that.

I did find that my shiny, new project looks just fine when I execute it with the executor package, as well as the platformer example and fps example from the book. The problem seems to be limited to the editor application itself --- or maybe the UI code? (The RPG tutorial had an issue where the whole screen was blank, and changing the text scale factor had no effect.)

The images below were all taken with a text scale factor of 0.8 (80%).

  • Freshly init'd game
    fyrox_no-bug_new-templated_game

  • 2d platformer tutorial
    fyxrox_no-bug_platformer-example

  • FPS tutorial
    fyrox_no-bug_fps

@jpaugh
Copy link

jpaugh commented Jan 30, 2024

I found a workaround that should help others out. Basically, I set the scale factor to 100% until the Fyrox editor loads, then immediately set it back to 80%, even while Fyrox is running. The editor doesn't glitch, even when I resize it / maximize it.

I made a bash function to do this for me; and if you're using bash and Gnome Desktop, you can use this function directly. Others can probably adapt it to their window manager and shell.

  1. Add the script below to your .bashrc file.
  2. Open a new shell (or otherwise reload .bashrc)
  3. Use the fyrox-edit command instead of cargo run --package editor
  4. Adjust the sleep_seconds variable to the minimum value you can reliably get away with, and reload the shell after each edit. In my experiments, I am able to get it as low as 0.3. It re-scales my GUI fonts back before the editor even finishes loading the scene preview, so that's probably as close as I can cut it.
fyrox-edit () {
  local sleep_seconds=2.0
  # Cache the build to avoid a pre-mature timeout
  cargo build --package editor --release

  # Schedule the DPI settings to go back to normal after a few seconds
  __restore_text_scaling "$sleep_seconds" &
  sleep 0.1 # Pre-empt race condition, that probably never happens (TM)
  # Set scale factor 1.0 for Fyrox and proceed
  gsettings set org.gnome.desktop.interface text-scaling-factor 1.0
  cargo run --package editor --release
}


__restore_text_scaling () {
  # Reset scale factor to the default after a few seconds
  local sleep_seconds="$1";shift
  local correct_scale_factor=$(gsettings get org.gnome.desktop.interface text-scaling-factor)
  sleep "$sleep_seconds"
  gsettings set org.gnome.desktop.interface text-scaling-factor "$correct_scale_factor"
}

Edit: I updated the script to keep cargo/fyrox running in the foreground, so you can shut it down with Ctrl+C.

@mrDIMAS
Copy link
Member

mrDIMAS commented Jan 30, 2024

@jpaugh Hi, I did yet another potential fix for the editor. Could you please check if it works? I'm on Windows and it works fine here.

@jpaugh
Copy link

jpaugh commented Jan 31, 2024

Unfortunately, that didn't change the outcome. I tried by adding the nightly build to a fresh project (built with the released fyrox-template 0.10.0), and also tried running the standalone editor directly from the latest on main (811a134).

I did some more analysis with the first run. The screenshot at the bottom is with text scaling set to 80%. I also recorded the editor's stdout. Didn't see anything notable there, but it's attached (run.log). FWIW, the window_size setting seems to be mostly correct in the settings.ron, although it's a few pixels smaller from the size of my screenshot. Probably comes down to window decoration (i.e. border and the title bar).

BTW, I also had to fix a compile error in the project as generated. The editor/src/main.rs passed two arguments to Editor::new() instead of one. I just removed the loop argument, per your merged change. It might be due to using a non-nightly version of fyrox-template, but the generation step is magic to me, so IDK.

fyrox_bugfix_compile-error

fyrox_bug_screen-glitch

@jpaugh
Copy link

jpaugh commented Jan 31, 2024

Thanks so much for your support! I'm personally comfortable with the workaround I suggested, and I might be able to dig in a little more and debug things after I figure out how to build my own UI in Fyrox. 🤞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants