Oni broken after Fedora 32 update

jisensee commented 4 years ago

I upgraded to Fedora 32 and now nothing is rendering properly. It was all good on Fedora 30. All UI elements are still functional, so I can still open and edit files. Atached screenshot and a debug log, let me know if you need more info to troubleshoot this.

Capture oni.log

CrossR commented 4 years ago

I'm able to repro in my Fedora 32 VM: https://drive.google.com/file/d/1BLKzevJc_PeUX_uUG0IQ55wB3q_LxLvq/view?usp=sharing

This was with a fully clean install and Oni2 direct from the early access portal. I only tried the AppImage, but I expect it will be the same for both.

At least for me, rendering does recover if I mess with the window size, so its almost like the initial render isn't happy somehow.

bryphe commented 4 years ago

Thanks for logging the issue @jisensee and for taking a first look @CrossR !

Interesting - it looks like a font loading or shaping issue. Perhaps related to the harfbuzz version we're using - or the recent font work in Revery.

I'll see if I can get a repro as well. Working on setting up a Fedora 32 VM-

bryphe commented 4 years ago

I just set up a Fedora 32 VM as well on a Windows host (the latest build - f81e09ed) - and it's not reproducing for me:

Some ideas:

If the appimage is extracted first with ./Onivim2-x86_64.AppImage --appimage-extract, does running it directly via the AppRun work? If so - it might be a problem with how we are packaging / loading the font files in the app image case.
Does the .tar.gz work, or does it have the same issue? If it works - that would again point to a problem with out AppImage package.
Running with the debug logs might help us diagnose as well - because they give more details on font loading: ./Onivim2-x86_64.AppImage -f --debug --log-file=oni2-debug.log

bryphe commented 4 years ago

It's possible this could've been impacted by #2204

jisensee commented 4 years ago

@bryphe Hi, thats weird. I just pulled the latest release and tried both of your suggestions. It was still broken on both of them. I attached a debug log in my original report. Here is another one from just now with the tar.gz. Let me know if that helps or if I can do anything else to narrow this down. oni2.log

bryphe commented 4 years ago

Thanks @jisensee for trying the latest! Rules out it being fixed by #2204

@CrossR mentioned on Discord that he had installed via this ISO: https://download.fedoraproject.org/pub/alt/releases/32/Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-32-1.6.iso and VMWare.

I had used this one, so perhaps that's a difference: https://download.fedoraproject.org/pub/fedora/linux/releases/32/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-32-1.6.iso

In addition - I was using Hyper-V on Windows.

I'll work on setting Astronomy-KDE release on a VM and see if I can reproduce it there. And @jisensee - looks like from the log you're running it via VMWare? What host OS are you using?

jisensee commented 4 years ago

@bryphe Yea, I am using VMWare on Windows 10. It has been a while since I set the VM up but I am pretty sure I just used the normal Fedora Workstation iso.

bryphe commented 4 years ago

Thanks @jisensee . I set up with VMWare Player + Windows 10 but didn't have any luck (didn't reproduce for me). I'll try setting up once more, and then I'll dive in to see if we can maybe get some better logging or more details. I suspect it's like @CrossR mentioned an issue with the GPU integration. It's curious that it started working after resizing.

jisensee commented 4 years ago

Resizing actually worked for me as well iirc. But when going back to full screen it broke again :(

bryphe commented 4 years ago

Sorry for the delay on this, I've been investigating. Unfortunately, I haven't been able to reproduce on any config I tried - with any of the matrix: (Hyper-V, VMWare Workstation Player) x (Fedora Worksation vs Fedora Astronomy) x (Mesa 20.0.4 vs Mesa 20.1.4). Really wish I could reproduce this!

It must be one of three possibilities, though, judging from the screenshot:

Possibility 1: GPU Driver / Rendering issue

This seems like a likely potential culprit - given that resizing seems to transiently fix it. I noticed that on my machine, prior to updating, I had Mesa 20.0.4 installed, and that the log given showed Mesa 20.1.4 - so I upgraded, hoping I could reproduce it, but no luck.

One way we could troubleshoot this, though, is to force Onivim to run in software mode:

LIBGL_DEBUG=1 LIBGL_ALWAYS_SOFTWARE=1 ./Onivim2-x86_64.AppImage -f --silent

If Onivim runs in software mode, that would strongly suggest there is something wrong the video drivers or the way Mesa -> VMWare -> host is set up.

It would also help just to get debug logs in hardware / SVGA mode, see if anything interesting is happening:

LIBGL_DEBUG=1 ./Onivim2-x86_64.AppImage -f --silent

Possibility 2: Harfbuzz shaping issue

There's a possibility that some of the recent font-fallback work could've impacted this - it could be that we're running into a bug where we're aggressively falling back to a font, or not resolving the proper glyphs. The fact that the UI font doesn't render at all, but the editor font shows up, is interesting...

The output of:

./Onivim2-x86_64.AppImage -f --checkhealth

Would be interesting - that shows the harfbuzz version that's being linked, as well as some basic font metrics that might be useful for debugging.

Possibility 3: Font Loading issue

It could also be that, beyond harfbuzz - we're having an issue loading the font. It's strange the editor font in the screenshot is clipped - that suggests we might not be getting the measurements correct (and this could impact the UI by wrapping early / aggressively to hide the text).

We get extra logs for font-rendering and wrapping with the --trace flag - so checking the log with --trace enabled, like:

./Onivim2-x86_64.AppImage -f --trace --log-file=trace.log

might give clues if the font metrics are off, or wrapping is the culprit...

Other than that - @CrossR - is your VM that you can reproduce on set up to build? I'm wondering if you build and run revery - if the same issues show up, or if it's specific to Onivim.

jisensee commented 4 years ago

@bryphe Hey, thanks for your input and investigating. It works now, although I unfortunately can't say what exactly the issue was. Here is what I did:

Updated AMD GPU drivers on the Windows host to the latest version (actually Horizon: Zero Dawn made me do this :P)
Updated VMWare
I also pulled the latest oni-release but it also worked for the older one from my last test, so that couldn't be it. I will keep this in mind if I encounter similiar issues in the future, it didn't cross my mind at all that those things might be the culprit.

bryphe commented 4 years ago

Thanks for the update @jisensee , really glad it's working now! 🎉

Interesting - it could very well be the VMWare update or the GPU driver update. Based on the description of the problem - a GPU / driver seems likely.

One thought I had, as well, is that the skia-sdl example is clearing out the stencil buffer prior to launching:

SDL_GL_GetDrawableSize(window, &dw, &dh);
--
  |  
  | glViewport(0, 0, dw, dh);
  | glClearColor(1, 1, 1, 1);
  | glClearStencil(0);
  | glClear(GL_COLOR_BUFFER_BIT \| GL_STENCIL_BUFFER_BIT);

...which we aren't currently doing. I doubt that is the issue, but it's possible... Keep us posted if it comes up again!

Updated AMD GPU drivers on the Windows host to the latest version (actually Horizon: Zero Dawn made me do this :P)

Nice 😄 That game looks great - can see why it would need updated drivers!

@CrossR - I'm curious if updating your VMWare version makes a difference, or video drivers? Sounds like you had hit this as well

onivim / oni2

Oni broken after Fedora 32 update #2207