"Draw antialiased" is unchecked in some cases which leads to sharped curves rendering

• Dec 6, 2018 - 06:07
Reported version
3.0
Priority
P0 - Critical
Type
Graphical (UI)
Frequency
Once
Severity
S1 - Blocker
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

OS: Windows 7 SP 1 (6.1), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4253, revision: 082e635

1) Default score
2) Enter a few notes and add slurs, ties and hairpins

Result: poor, degraded rendering even with the default zoom (100%)
ties slurs.jpg

And worse of course in higher values (eg 400%)

ties slurs1.jpg

dynamics hairpins.jpg

  • In comparison, with the version 2.3.2:

    slurs ties version2.jpg

Comments

• Dec 6, 2018 - 07:11
Priority ⇒ P1 - High

FWIW, I can't reproduce on my system, Windows 10. The commit in question really can't explain this. I suspect whatever is going on is more likely related to pixel scaling.

Reply

• Dec 6, 2018 - 07:18

I can reproduce here on Windows 7 and 10 and on two different computers and screens (desktop vs. laptop)
And the change is so obvious between the two mentioned nightlies that issue is also obvious.

Reply

• Dec 6, 2018 - 07:54

"The commit in question really can't explain this"
I don't talk about a specific commit yet, but about nightlies. And from I see, there a few commits (6) between the two mentioned nightlies.

Reply

• Dec 6, 2018 - 08:19
Priority P1 - High ⇒ P0 - Critical
Severity S3 - Major ⇒ S1 - Blocker

I can reproduce even on Mac. Everything is ok when exporting to PDF, btw.

Reply

• Dec 6, 2018 - 14:10
Title Ties, slurs and hairpins show a damaged rendering ⇒ Ties, slurs, hairpins and beams show a damaged rendering

And beams too :(

(after checking: same origin/date of November 29)

beams.jpg

Reply

• Dec 10, 2018 - 10:23

Qt is not the reason. The most visible symbol is glissando. The "waves" are obviously resharped. I thought it related to new version of Bravura, reverted the migration, but no, no difference.

It is reprocible on Linux as well, dmitrio95 was the first who found this bug on Debian.

Reply

• Dec 10, 2018 - 12:12

After further investigation, I am not right now entirely sure of the explanation, but:
In November 29, between the two mentioned nightlies/commit in first report, there was this one: https://github.com/musescore/MuseScore/pull/4248/files
About the canvas, with custom workspace and GUI preferences, with the first one, it was set like this.
user1.jpg
With the second one, like this:
user.jpg
And so, I received this (eg for the hairpin)
mf.jpg
And even I changed in the same session, the preference (all white color), I received the same problem. It maybe (probably) the issue I seen.
hairpin.jpg

I can not say that everything is back as expected now, it should continue to test further with custom workspace, GUI preferences, colors, background, wallpapers, etc. These last days, I was intrigued by this (with colors, background) when opening other nightlies to check other things.
But from what I see after a revert to factory settings, I do not see the same issue or at least I can not reproduce for now. Rather good news!

  • On the other hand, I still see it with the Glissando. But it is not related to this date of November 29. I see it all the time (in any case, for now, I see it eg in January 2017)

Reply

• Dec 10, 2018 - 12:38

Even if you picked Advanced Workspace at the frst new start after the reset, from the wizard? Or does it get unchecked only on the create new workspace?

Reply

• Dec 10, 2018 - 12:40

@werner, I think you might be on to something with your theory that it is the upgrade from Qt 5.9 to 5.12 causing the problem.

First, a little context. I am on Windows 7 32 bit, so I can't use current nightlies. I build MuseScore myself from sources.

I can see the difference between building with MinGW530_32 and Qt 5.9.5 and building with MSVC 2017 and Qt 5.12.0. The MSVC 2017 and Qt 5.12 build exhibits the same lack of antialiasing, while the MinGW530_32 and Qt 5.9 build has nice smooth beams on-screen. The only snag in this theory is that not only the Qt version has changed between my two builds, but also the compiler. Someone else should verify that it is indeed Qt by compiling with Qt 5.9 and 5.12 with the same compiler.

Reply

• Dec 10, 2018 - 12:45

I don't see how having that "Draw antialiased" checkbock being checked or not could possible be related to what compiler or Qt version is involved. I can imagine though it being related to workspaces and switching between them

Reply

• Dec 10, 2018 - 12:58

@JLWaltener, @Jojo-Schmitz I see a difference between antialiasing quality if I build with MinGW and Qt 5.9 on the one hand and MSVC and Qt 5.12 on the other. Things are drawn antialiased, but beams look noticeably more jagged in the MSVC / Qt 5.12 build.
Antialiasing.PNG
See the smooth hairpin and the jagged beam.

Attachment Size
Antialiasing.PNG 3.03 KB

Reply

• Dec 10, 2018 - 13:19

OK, a slight difference might be explained by the Qt version difference but still not the status of that checkbox (which in turn explains a large difference though)

Reply

• Dec 10, 2018 - 13:30

I locate the change for the glissando (sharpened waves) in October 2016.
More precise soon. I return into the machine room!

Reply

• Dec 10, 2018 - 22:52

So I struggled a bit with my build environment, but I finally got a Qt 5.9 build with MinGW again and... it suddenly looks jagged too, exactly as the MSVC with Qt 5.12 build. So it is probably nothing to do with the Qt version or compiler. Sorry for leading you astray.

Reply

• Dec 12, 2018 - 07:22
Title Ties, slurs, hairpins and beams show a damaged rendering ⇒ "Draw antialiased" is unchecked in some cases which leads to sharped curves rendering
Status active ⇒ needs info

To sum up, if we check "draw antialiased" everything is drawn correctly. Could anyone point to the particular case when the checkbox is unchecked?

Reply

• Dec 12, 2018 - 08:00

@Anatoly-os I definitely see a difference in antialiasing between builds before and after 10 Dec somewhere. Lines are being antialiased in both cases, but it is as if the method differs giving different results. See my post above. AA is on, you can see it in the hairpin, but the AA on the beam doesn't look as it used to and looks IMHO worse. I don't think the beam isn't antialiased, it is just as if the antialiasing is just done with a different method, making it look different.

Reply

• Dec 12, 2018 - 09:44

About beams, and with this test score ( test.mscz ), I note a sensible change on December 9. See measure 3 top staff - under "Adagio"
And always with the default configuration (ie "Draw antialised" checked)

With this one, a9203cb, and zoom 800%, I get:

8dec.jpg

And with the next one, d5298f5, I receive (so, a side effect of this commit about cross beams and tuplet beams layout ? )

9 dec.jpg

Reply

• Dec 17, 2018 - 05:03

No, definitely not. This just started happening within the past couple of days. maybe, when I tried testing changing preferences to investigate that issue :-)

Reply