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.

Sign up for GitHub

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

Jump to bottom

musescore 4.4 on windows - error in rendering #22369

Closed
sdwarwick opened this issue Apr 12, 2024 · 19 comments · Fixed by #23438
Closed

musescore 4.4 on windows - error in rendering #22369

sdwarwick opened this issue Apr 12, 2024 · 19 comments · Fixed by #23438
Assignees
@Eism @cbjeukendrup
Labels
needs info More information is required before action can be taken P1 Priority: High UI Visual issues affecting the UI (not notation)

Comments

@sdwarwick
Copy link
Contributor

sdwarwick commented Apr 12, 2024 •
edited
Loading

Issue type

UI bug (incorrect info or interface appearance)

Bug description

Please see pictures included - After compiling locally following documented procedure, it appears that the rendering of all the musescore objects are offset from the window definition provided to Windows. The mouse doesn't work correctly either. you have to point above the actual menu item to highlight an option.

muscscore

musescore_1

musescore_2

note positions of the 4's are out of the box

musescore_3

note that no gutter displayed, which includes information about what is currently selected

tried to get help on forum, nothing suggested helped.

Steps to reproduce

  1. build and install musescore from a local git repository using either cmake -P or msvc_build.bat
  2. run musescore from install/bin directory
  3. create new score
  4. see resulting display

Screenshots/Screen recordings

No response

MuseScore Version

4.4 master

Regression

I don't know

Operating system

windows 10

Additional context

git version id 49b114b
@muse-bot muse-bot added the UI Visual issues affecting the UI (not notation) label Apr 12, 2024
@sdwarwick
Copy link
Contributor Author

I re-compiled musescore master, replacing the following:

app.cpp:

    /*QCoreApplication::setAttribute(Qt::AA_UseOpenGLES);*/
    QCoreApplication::setAttribute(Qt::AA_UseSoftwareOpenGL);

This fixed the problem.

I checked my display devices, found the following:

  1. Intel HD Graphics 4000 - openGL version 4.0.0
  2. NVIDIA Quadro K1000M - opengl version 4.5.0 NVIDIA 372.95

This appears to be the same problem as:
[MU4 Issue] Transparent app border on Windows #8270

Need further information as to what might need to be changed to solve this problem correctly in MuseScore

@sdwarwick
Copy link
Contributor Author

have also determined that commenting out the line:

/*QCoreApplication::setAttribute(Qt::AA_UseOpenGLES);*/

and setting the following environment variable also works:

 $env:QT_OPENGL = 'software'

@bkunda bkunda added the P1 Priority: High label Apr 16, 2024
@cbjeukendrup
Copy link
Contributor

I think the time signature issue on the "Additional score information" is not related to this, as that happened on other OSs as well while the rest seems Windows-specific. That issue has been fixed recently by #21876.

The rest seems related to the switch to Qt 6. It's interesting that switching to software-based OpenGL fixes the issue, but I believe that that may have negative effects on performance. I don't know all about it though, and can't easily find more information about the implications of it.

@sdwarwick
Copy link
Contributor Author

see

https://doc.qt.io/qt-6/opengl-changes-qt6.html

On Windows, ANGLE, a third-party OpenGL ES to Direct 3D translator, is no longer included in Qt 6. This means Qt::AA_UseOpenGLES and the environment variable QT_OPENGL=angle no longer has any effect. In dynamic OpenGL builds there is no automatic fallback to ANGLE in case OpenGL-proper fails to initialize. For QWindow or QWidget based applications using OpenGL directly, for example via QOpenGLWidget, this means that OpenGL-proper is the only option at runtime. However, the use of a pure software OpenGL implementation, such as Mesa llvmpipe that is shipped with the pre-built Qt packages, is still available.

This means that the line

 QCoreApplication::setAttribute(Qt::AA_UseOpenGLES);

doesn't do anything now.

I believe that we will need to track down where we QWindow and QWidget might be in error?

@cbjeukendrup
Copy link
Contributor

cbjeukendrup commented Apr 18, 2024 •
edited
Loading

Thanks for that resource.

So basically the one problem here is that the content is visually offset w.r.t. the actual window; therefore, the mouse doesn't work correctly and the bottom bar falls below the border of the window.
There might be a connection to #8270, #22052 and #9968. Some of those have been fixed by apparently only partly.

The code in src/appshell/internal/platform/win/winframelesswindowcontroller.cpp might be relevant.

Edit: #8270 and the corresponding pull request seem most relevant.

@sdwarwick
Copy link
Contributor Author

am looking at app.cpp:

#ifndef MU_QT5_COMPAT
    // Necessary for QQuickWidget, but potentially suboptimal for performance.
    // Remove as soon as possible.
    QQuickWindow::setGraphicsApi(QSGRendererInterface::OpenGL);
#endif

I believe that this may be a potential source of the error, am going to look more into it.

@sdwarwick
Copy link
Contributor Author

Have found that removing both of these references to OPENGL fixes this problem:

#ifdef Q_OS_WIN
    // NOTE: There are some problems with rendering the application window on some integrated graphics processors
    //       see https://github.com/musescore/MuseScore/issues/8270

	/*QCoreApplication::setAttribute(Qt::AA_UseOpenGLES);*/

      if (!qEnvironmentVariableIsSet("QT_OPENGL_BUGLIST")) {
        qputenv("QT_OPENGL_BUGLIST", ":/resources/win_opengl_buglist.json");
    }
#endif

and

#ifndef MU_QT5_COMPAT
    // Necessary for QQuickWidget, but potentially suboptimal for performance.
    // Remove as soon as possible.
   
    // QQuickWindow::setGraphicsApi(QSGRendererInterface::OpenGL);
#endif

not sure if there are other implications if this is done, but it is a solution.

@cbjeukendrup
Copy link
Contributor

Good work!

Unfortunately, that comment about QQuickWidget is still actual as far as I know; without that line, the app crashes when opening the Format > Style dialog, which makes use of QQuickWidget.
There are two things we can do:

  • find a way to embed QML into the EditStyle dialog without using QQuickWidget
  • rebuild the whole EditStyle dialog in QML.

Ultimately, we want the second option, but that is a lot of work, so we'd rather combine it with a redesign (instead of recreating the current design in QML now and then doing it yet again later when the redesign comes). So the second option is not feasible in the short term. Hopefully the first option is possible.

@sdwarwick
Copy link
Contributor Author

sdwarwick commented Apr 19, 2024 via email

@cbjeukendrup
Copy link
Contributor

Yes, currently EditStyle is the only place where we use QQuickWidget; however it's used multiple times within that dialog.

@sdwarwick
Copy link
Contributor Author

sdwarwick commented Apr 19, 2024 •
edited
Loading

am seeing different behavior - Format -> Style actually is working for many of the settings ( this is even using the 6.2.4 version of Qt) , however there are some that DO crash the program. I'm seeing the following Debug error show up when the crash happens:

[1;32m10:42:36.026 | INFO  | main_thread     | NotationProject::doSave | success save file: MuseScore/MuseScore4Development/new_project.mscz" �[0m
�[1;33m10:43:10.045 | WARN  | main_thread     | Qt              | QQmlComponent: Created graphical object was not placed in the graphics scene.�[0m
�[1;32m10:43:11.620 | INFO  | main_thread     | ActionsDispatcher::dispatch | try call action: edit-style�[0m
�[1;33m10:43:12.196 | WARN  | main_thread     | Qt              | QMetaObject::connectSlotsByName: No matching signal for on_resetTabStylesButton_clicked()�[0m
�[1;33m10:43:12.200 | WARN  | main_thread     | Qt              | QQuickWidget is only supported on OpenGL. Use QQuickWindow::setGraphicsApi() to override the default.�[0m
�[1;33m10:43:12.207 | WARN  | main_thread     | Qt              | QQuickWidget is only supported on OpenGL. Use QQuickWindow::setGraphicsApi() to override the default.�[0m
�[1;33m10:43:12.214 | WARN  | main_thread     | Qt              | QQuickWidget is only supported on OpenGL. Use QQuickWindow::setGraphicsApi() to override the default.�[0m
�[1;33m10:43:12.241 | WARN  | main_thread     | Qt              | QQuickWidget is only supported on OpenGL. Use QQuickWindow::setGraphicsApi() to override the default.�[0m
�[1;33m10:43:12.248 | WARN  | main_thread     | Qt              | QQuickWidget is only supported on OpenGL. Use QQuickWindow::setGraphicsApi() to override the default.�[0m
Exception thrown at 0x00007FFC0FD5ECBC (d3d11.dll) in MuseScoreStudio4.exe: 0xC0000005: Access violation reading location 0x00000000000000BE.

It's looking like the OpenGL rendering support is a real issue. Perhaps it can be activated only for this widget, or the problem is addressed in a later version of Qt. I'd also look at replacing QQuickWidget with a different window type.

@cbjeukendrup
Copy link
Contributor

Indeed, it crashes only on certain pages of EditStyle; namely exactly those that contain a QQuickWidget :)

Since the Qt documentation states explicitly that QQuickWidget is only functional with OpenGL, which is not the default anymore in Qt 6, it's quite certain that it just won't work, also not with a higher version of Qt.
To be sure, I tried to try it out in my Qt 6.7 branch, but couldn't, because with Qt 6.7 the app won't even run at all, because some very obscure QML error (it doesn't know anymore what QtObject and Component are!). Time to try if it works with Qt 6.6, I guess...

@cbjeukendrup
Copy link
Contributor

Update: I later found that QQuickWidget is supported again when not using OpenGL in Qt 6.5. Compare these:
https://doc.qt.io/qt-6.5/qquickwidget.html#performance-considerations
https://doc.qt.io/qt-6.2/qquickwidget.html#performance-considerations

So updating to Qt 6.5 would allow us to remove QQuickWindow::setGraphicsApi(QSGRendererInterface::OpenGL); which fixes this issue.
There are two things against updating to Qt 6.5:

  1. OS compatibility. Qt 6.5 drops support for macOS 10.14 so 10.15 becomes the minimum. This turns out to be a bit of a non-issue, because it seems that all Macs that can be updated to 10.14 can also be updated to 10.15, so there shouldn't be any Macs in the world that are stuck on 10.14. I'm not sure about the situation on other OSs though.
  2. Bugs. Some things are mysteriously broken in qt 6.5. Most notably, the toolbars are not appearing. There is not a single indication of why this might be the case.

@bkunda bkunda added the needs info More information is required before action can be taken label Jul 1, 2024
@cbjeukendrup
Copy link
Contributor

@sdwarwick Could you check if this was working correctly in MuseScore 4.3, and thus whether it would be a regression in 4.4? We'll need that info to determine how to prioritise this.

Switching to Qt 6.5 seems not a viable option right now, because it has significant inexplainable bugs and we're getting a bit too close to the 4.4 release date to do anything experimental. So for now, we'll have to try to avoid the usage of QQuickWidget, so that we can still remove that offending setGraphicsApi call.

@sdwarwick
Copy link
Contributor Author

sdwarwick commented Jul 1, 2024 via email

@cbjeukendrup
Copy link
Contributor

My question was rather: did the window offset issue (and mouse movement issue and bottom bar issue, which are consequences of that) already occur in MuseScore 4.3, or is it a new problem in 4.4?

@sdwarwick
Copy link
Contributor Author

sdwarwick commented Jul 1, 2024 via email

This was referenced Jul 2, 2024
Closed
Open
cbjeukendrup added a commit to cbjeukendrup/MuseScore that referenced this issue Jul 2, 2024
@cbjeukendrup
Eliminate QQuickWidget and QQuickWindow::setGraphicsApi(QSGRendererIn…
15fc884 
…terface::OpenGL)

Eliminating the former was a requirement for eliminating the latter (at least with Qt 6.2.x); and removing the latter should resolve musescore#22369.
cbjeukendrup added a commit to cbjeukendrup/MuseScore that referenced this issue Jul 2, 2024
@cbjeukendrup
Eliminate QQuickWidget and QQuickWindow::setGraphicsApi(QSGRendererIn…
18ec294 
…terface::OpenGL)

Eliminating the former was a requirement for eliminating the latter (at least with Qt 6.2.x); and removing the latter should resolve musescore#22369.
@cbjeukendrup cbjeukendrup mentioned this issue Jul 2, 2024
Merged
@cbjeukendrup
Copy link
Contributor

@sdwarwick Could you please try if #23438 does indeed solve the problem and that the format > style dialog still works correctly?

@cbjeukendrup cbjeukendrup self-assigned this Jul 2, 2024
cbjeukendrup added a commit to cbjeukendrup/MuseScore that referenced this issue Jul 3, 2024
@cbjeukendrup
Eliminate QQuickWidget and QQuickWindow::setGraphicsApi(QSGRendererIn…
1ae5cff 
…terface::OpenGL)

Eliminating the former was a requirement for eliminating the latter (at least with Qt 6.2.x); and removing the latter should resolve musescore#22369.
@sdwarwick
Copy link
Contributor Author

sdwarwick commented Jul 3, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Eism Eism

@cbjeukendrup cbjeukendrup

Labels
needs info More information is required before action can be taken P1 Priority: High UI Visual issues affecting the UI (not notation)
Projects
MuseScore Studio 4.4
Status: Done
Milestone
No milestone
5 participants
@sdwarwick @Eism @muse-bot @cbjeukendrup @bkunda