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

Broken rendering of Vectorscope #7518

Open
1 task done
michaelgregorius opened this issue Sep 25, 2024 · 12 comments
Open
1 task done

Broken rendering of Vectorscope #7518

michaelgregorius opened this issue Sep 25, 2024 · 12 comments
Labels

Comments

@michaelgregorius
Copy link
Contributor

michaelgregorius commented Sep 25, 2024

System Information

Linux - Wayland

LMMS Version(s)

1825208

Bug Summary

The Vectorscope plugin renders in a broken way on a Linux Wayland system:

Bildschirmaufnahme_20240925_170936.webm

Steps To Reproduce

  1. Add a Vectorscope as an effect.
  2. Open the view of the Vectorscope.

Please search the issue tracker for existing bug reports before submitting your own.

  • I have searched all existing issues and confirmed that this is not a duplicate.
@michaelgregorius
Copy link
Contributor Author

It works under X11 and therefore only is a problem under Wayland. It is caused by the calls to devicePixelRatio() here:

temp.setDevicePixelRatio(devicePixelRatio());

And here:

temp.scaledToWidth(displayWidth * devicePixelRatio(),

The method devicePixelRatio() returns 2 on my system whereas I have set my scaling to 125%, i.e. 1.25. The following code fixes the rendering on my machine:

//temp.setDevicePixelRatio(devicePixelRatio());
painter.drawImage(displayLeft, displayTop, temp.scaledToWidth(displayWidth, Qt::SmoothTransformation));

It might break another case though? I am not sure why it is necessary to use the device/pixel ratio here.

@michaelgregorius
Copy link
Contributor Author

There's also a problem with the general functionality under Wayland. The screen is not cleared if HQ mode is disabled but everything works in HQ mode:

Broken.Vectorscope.in.Non-HQ.webm

@michaelgregorius
Copy link
Contributor Author

With the fix described above the broken rendering starts to appear when the value of the variable displayWidth is equal or greater than activeSize.

@bratpeki
Copy link
Contributor

I noticed, on latest master, than it occurs only with a persistence of 1. This is expected, as I would believe there is no persistance for a value of 1 (that is 100%).

@michaelgregorius
Copy link
Contributor Author

Did you test it under Linux with Wayland, @bratpeki? It seem that upscaling pixmaps does not work on that platform like it works on X11.

@bratpeki
Copy link
Contributor

No, this is on Windows, works just fine!

@he29-net
Copy link
Contributor

he29-net commented Oct 7, 2024

I am not sure why it is necessary to use the device/pixel ratio here.

Basically in all my LMMS work, I use this in context of forcing Qt to draw at native resolution. Otherwise everything tends to be drawn in the "96 DPI Qt logical pixels" and looks terrible after upscaling to match the display DPI (especially with fractional scaling).

The Waterfall display of Spectrum Analyzer uses a very similar drawing method to the Vectorscope, so it could be affected as well (I don't have any Wayland systems, so I can't check).

Not sure about the screen redraw; looking at the video again, the Persistence knob itself is getting brighter and distorted, so it clearly has nothing to do with the persistence setting or the visualization bitmap? It seems to affect the final bitmap that Qt renders for the entire widget or sub-window, so I'm leaning toward some Qt bug under Wayland. Though it's a bit odd that black would be treated as transparency if it was a bug – the effect it has seems almost... intentional... Weird.

@michaelgregorius
Copy link
Contributor Author

I am not sure why it is necessary to use the device/pixel ratio here.

Basically in all my LMMS work, I use this in context of forcing Qt to draw at native resolution. Otherwise everything tends to be drawn in the "96 DPI Qt logical pixels" and looks terrible after upscaling to match the display DPI (especially with fractional scaling).

Ok, if I understand correctly, the reasoning is the following: rendering pixmaps with fractional scaling will resample them and make them look rather bad. The Vectorscope used pixel "bins" for the traces and is therefore also pixmap based. Therefore something needs to be done to counter that. Is this correct?

Another option might be to render the trace with line segments. It might use something like a ring buffer of positions which would be rendered as line segments that get progressively fainter the older they are. This approach might allow for some nice scaling but might have an impact on the performance.

The Waterfall display of Spectrum Analyzer uses a very similar drawing method to the Vectorscope, so it could be affected as well (I don't have any Wayland systems, so I can't check).

I have just checked and was not able to get any artifacts for the Waterfall display of the Spectrum Analyzer. So there seems to be a difference in the implementation which prevents the bug.

Not sure about the screen redraw; looking at the video again, the Persistence knob itself is getting brighter and distorted, so it clearly has nothing to do with the persistence setting or the visualization bitmap? It seems to affect the final bitmap that Qt renders for the entire widget or sub-window, so I'm leaning toward some Qt bug under Wayland. Though it's a bit odd that black would be treated as transparency if it was a bug – the effect it has seems almost... intentional... Weird.

I am under the impression that it might indeed be a Qt bug that occurs under certain circumstances when a QImage/QPixmap (don't remember which) is scaled to a larger size.

@Rossmaxx
Copy link
Contributor

@michaelgregorius How much effort would it take to make LMMS working properly on Wayland?

@michaelgregorius
Copy link
Contributor Author

@michaelgregorius How much effort would it take to make LMMS working properly on Wayland?

It's hard to tell. The issues have to be found in the first place. And then some might be easier to fix than others. For example the performance related issue #7462 is not that simple to fix as it is caused by implementation differences between the underlying display servers, i.e. X11 and Wayland. The fix would be to make sure that LMMS renders in a way that is efficient enough in all places.

@regulus79
Copy link
Contributor

I am on Arch Linux, GNOME 47, Wayland, and I cannot reproduce the issue on master.

@michaelgregorius
Copy link
Contributor Author

michaelgregorius commented Dec 5, 2024

I can still reproduce the issue with the current master (d973788).

Here's some more information about my setup:
Operating System: Arch Linux
KDE Plasma Version: 6.2.3
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.0
Kernel Version: 6.11.8-arch1-2 (64-bit)
Graphics Platform: Wayland
Graphics Processor: AMD Radeon Graphics

Edit: the Qt version is what KDE uses. I am building LMMS with Qt 5.15.15.

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

No branches or pull requests

5 participants