Background opacity flickers issue

[videosmith]

Occasional "bleed through" of desktop when QPrompt is scrolling in full screen mode.

Steps to Reproduce

1. Run app in single hdmi RPi monitor full screen mode
2. Scroll text.
3. Although the app successfully overwrites the desktop, occasionally it flickers through briefly while scrolling.

Expected behavior

App should suppress the desktop background.

Screenshots (if applicable) My attempt to recreate what occurs.

Device information

• Operating System: [RPI 4 Debian Bulllseye 64, latest updates]
• QPrompt Version: [1.0.0]

...

[Cuperino]

So far I've had this problem only on Windows, while running older versions of Qt and KDE Frameworks.

Which RPi version of Qt, and which version of KDE Frameworks is QPrompt using to run on it your system? You can find this information in QPrompt's About page.

Have you tried running the Flatpak to see if it has the issue? I tried running both versions under arm64 Debian 11 and was unable to replicate the issue. I will try replicating in the raspberry Pi later today.

[Cuperino]

I'm sorry, I won't be able to try replicate the issue on my RPi yet. I forgot I left my HDMI to HDMI mini adapter in someone else's home, and I won't be seeing them until the 26th. They will try shipping the adapter over the mail.

[Cuperino]

The HDMI mini adapter arrived through the mail today. I tested on my Raspberry Pi 400, newly flashed, and was unable to replicate the bug in my end...

How are your displays configured? Which are you using and what are their resolutions?

Is your Raspberry Pi running the most up to date version of Raspberry Pi OS?

To update, first run the raspi-config tool on the terminal and choose Update. Then exit the tool and run the following update commands, as you would in most other Debian based distros:

sudo apt update
sudo apt upgrade

[Cuperino]

Hey @videosmith, are you still having the flicker issue from this thread or did it by any chance go away when you re-installed everything when solving this file saving issue?

[videosmith]

Still have it. I also installed the same software on a second RPi 4 and it flickers occasionally as well. Perhaps a bug in the RPi Bullseye os? On Sunday, April 3, 2022, 05:43:16 PM EDT, Javier O. Cordero Pérez @.***> wrote:

Hey @videosmith, are you still having the flicker issue from this thread or did it by any chance go away when you re-installed everything when solving this file saving issue?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[Cuperino]

Maybe... It could be a bug with its window manager or a bug with its GPU driver. I'll give it another try on the 400.

[Cuperino]

@videosmith I wasn't able to replicate the background opacity flicker issue in my Raspberry Pi 400. Did this issue also went away by moving to KDE Plasma, like with this other issue, or is it still present?

[videosmith]

Have not seen it recently, not certain if that is due to an OS update, or my operation of the app... will notify you if it returns.

[Cuperino]

Alright, thanks!

[videosmith]

Using your 1.1.1 release on Raspberry Pi 400, Raspian Bullseye, latest updates, 480p resolution, full screen. Flickering returned, appears only while prompting as far as I can tell.

[Cuperino]

Huh... Could you check if it happens with v1.1.0? There aren't that many differences in code between those two versions, but there's one major difference in how v1.1.1 was compiled.

[videosmith]

I will swap sd cards and let you know... however the issue being intermittent makes detection problematic.

[Cuperino]

In that case, use this alternate build of v1.1.1 so you don't loose the fixes from that version. This uses the exact same source code as v1.1.1 but was built using the parameters used for the v1.1.0 Deb build. https://github.com/Cuperino/QPrompt/releases/tag/v1.1.1-alt

[videosmith]

Will advise, thank you.

[videosmith]

Thank you. I will check it out and let you know.

[videosmith]

The 'Head' build still flickers occasionally. Am I able to completely disable transparency option, in case that's the culprit?

[Cuperino]

I've added the ability to fully disable background transparency. I still don't know where the culprit is, and I haven't been able to replicate the issue; but, if you don't need background transparency, this will completely avoid the issue and improve performance.

Go to "Main Menu > Other Settings > Disable background transparency", then click "Yes" to restart QPrompt and fully disable background transparencies. Restarting QPrompt is necessary because fully disabling transparency eliminates the alpha channel in the window's render, improving performance.

The builds for 1.1.2 are still in the making, I'm having trouble with Craft and the AppImage build again. I'll release a Deb package for x86_64 now that the icons work as intended and building the extra package consumes very little time with the new computer. It should serve as a backup for some systems, in case I can't complete the AppImage in the future.

[videosmith]

Sounds good, thank you. I will install 1.1.2 on my RPi units and report.

[Cuperino]

https://sourceforge.net/projects/qprompt/files/v1.1.2/

[videosmith]

Currently on a job. No flicker yet, however the animation occasionally freezes and when it resumes, animation jumps forward, as if a streaming video has interruptions.

[Cuperino]

The jump may be related to a compromise I had to make in order to improve the performance of screen projections. All previous versions of QPrompt use separate CPU threads to process each window's graphics while the logic for the next frame is processed on a the main thread. However, this feature prevents one window from displaying the contents of another; because there's no certainty that the contents created for one window will be valid when another window's thread tries to access it.

Version 1.1.2 disables this CPU mutithreading optimization in favor of enabling screen projections to happen using only the GPU; which copies visuals across windows orders of magnitude faster. In other words, all of QPrompt got a bit slower for screen projections to become a lot faster.

Re-enabling the multithreaded renderer would have to be done at compile time and it would result in screen projections not displaying. I haven't found a way to toggle between these rendering modes, but the ideal solution here is implementing our own custom implementation of the render, which is possible to do in Qt but would require sacrificing the Kirigami framework, meaning the entire user interface would have to be re-designed.

[videosmith]

Would it be possible to have both versions installed with a simple picker at app launch? Or perhaps a config file... i know it's clumsy, just a suggestion.

[Cuperino]

I honestly want to avoid providing more than a single launcher to run the app. It creates confusion and most users would just use one variant at all times.

The rendering mode of Qt apps can be set by passing an environment variable when launching the program, but I've deliberately programed QPrompt to overwrite this environment variable in order to prevent distros from forcing the threaded renderer, which would result in some users giving QPrompt a bad rating because screen projections don't work at all.

What limits me here is that overriding the environment variable to set the renderer is basically a hack that can only be executed before Qt parts start running. That limits our options when it comes to user interaction. So far I can think of two options:

1. Parse terminal / command line options to determine whether the hack would run or not. (I don't know if Qt's parser would work here. If it won't, this would have to be programmed without relying on Qt. This approach is cleaner because the interface can be self documented and users would be able to learn about it by running qprompt -h, which does nothing at present).
2. Make use of an extra, custom, environment variable to determine whether the hack is to be run on not. (This is basically a hack to work around the hack, and it is certain to work.).

I've started a new thread to deal with the slowdown: https://github.com/Cuperino/QPrompt/issues/127

I'll leave this issue here open for now, in case someone else is facing the background opacity flicker and would like to share details about their system.

[videosmith]

I appreciate the effort sir. I will just go back to 1.1.1 for now and deal with the occasional flicker... much less impact than the animation hiccups.

[Cuperino]

I see. Try compiling v1.1.2 for yourself on the Debian systems. That build is the easiest one to create out of all platforms. Re-enabling the multi-threaded renderer is only a matter of removing line 77 from main.cpp, found here: https://github.com/Cuperino/QPrompt/blob/main/src/main.cpp#L77

[videosmith]

Thank you. I will try that.

[videosmith]

Currently dealing with this annoyance... Unable to locate package qt5-x11extras-dev

Debian 11.5, x64 latest updates

[Cuperino]

Replace that package name with: libqt5x11extras5-dev

I've updated the documentation accordingly. The command you should run is:

sudo apt install kirigami2-dev cmake-extras qml-module-org-kde-kcoreaddons qml-module-qtquick-shapes qtdeclarative5-dev-tools libqt53drender5 libqt5quickshapes5 qtdeclarative5-dev qt5-qmltooling-plugins libqt53dcore5 libkf5kirigami2-doc librhash0 libqt5svg5-dev cmake-data qml-module-qt-labs-qmlmodels qml-module-qtqml-statemachine libqt5quicktest5 libqt5x11extras5-dev qml-module-qtquick-scene2d libqt53dquickscene2d5 cmake qtquickcontrols2-5-dev gettext libkf5auth-dev-bin libkf5widgetsaddons-dev libkf5iconthemes-dev libkf5iconthemes-doc libkf5codecs-dev libkf5codecs-doc libkf5guiaddons-dev libkf5guiaddons-doc libkf5auth-dev libkf5auth-doc libkf5configwidgets-dev libkf5configwidgets-doc libkf5itemviews-dev libkf5itemviews-doc

[videosmith]

So I tried the same 1.1.2 build just now on the same RPi 4B, and no freezing. Will attempt to narrow this down. One observation: somewhere in the last couple OS updates, the drive activity light is now constantly illuminated, perhaps this suggests the fault is in system activity and not your app.

[Cuperino]

Huh! That is strange... I would've expected low end systems like the Pis to be the most affected platforms. The only difference between the two Deb packages is the architecture.

I did notice that on Fedora 36 running Wayland, the AppImage fails to make use of GPU optimizations, resulting in graphical defects and bad performance. Now, I don't know if this is a problem with the AppImage containerization or with Fedora 36. All final releases of QPrompt's AppImages fail to run properly on Fedora 36.

[videosmith]

[Cuperino]

That looks great...

[videosmith]

Attempting to discover if the constant drive led had any bearing...

Would changing the qprompt process priority in the system monitor help? Currently set to Normal.

[Cuperino]

lxpanel write seems a little high now that you mention the drive led again.

[Cuperino]

It may help as long as you don't crank it up too high. Lowering the priority of a competing app would also help. Linux uses separate "schedulers" for the CPU and for "disk IO". If disk IO is the problem, then you may want to change those priorities.

Nevertheless, it's strange that disk IO slows down QPrompt, because QPrompt loads the entire document to RAM when its opened. The disk would only be used to access any part of QPrompt itself that isn't loaded to RAM because its in Swap. But from the image we can tell that no swap is being used either.

[videosmith]

[videosmith]

agreed and probably not relevant

Will try with external ssd instead

[Cuperino]

There may be some relevancy because, although QPrompt's rarely reads or writes to disk, reading and writing to disk requires using the CPU. I've had various Linux systems slow down and even freeze because a single CPU core is busy writing to a slow flash drive.

I heard the latest version of Raspberry Pi OS added the ability to type to search for applications from the app launcher. Some desktop environments such as KDE Plasma also index all user files to provide document suggestions from the same search. RPi's Pixel/LXDE could be doing this very thing, keeping the CPU busy.

[Cuperino]

If some kind of indexing is causing this, it's likely the slowdowns will stop once all files have been indexed. Nevertheless, it could also be a bug in lxpanel that is causing excessive writing.

[Cuperino]

This thread here may help: https://github.com/raspberrypi/linux/issues/2518

[videosmith]

Ignore the led comment... my ignorance at work... old school disk activity leds illuminated with disk access... apparently these are designed to do the opposite.

[videosmith]

RPi's Pixel/LXDE could be doing this very thing, keeping the CPU busy.

And yet the system status currently indicates little load...

Perhaps a reboot/power cycle before show is all thats needed?

[Cuperino]

apparently these are designed to do the opposite.

Maybe the polarity is inverted? I don't remember the explanation, but I once had an HDD LED wired in such a way. I also inverted the Power LED with the HDD LED, if one of them didn't work, depending on which feedback was better for the owner.

And yet the system status currently indicates little load...

Maybe it finished indexing, or is something that comes and goes.

Perhaps a reboot/power cycle before show is all that's needed?

Rebooting is always a good option. There's a myth that says you don't need to reboot Linux. It's only true if you never update the Kernel (bad security) or have live Kernel patching enabled, and you manually restart system daemons as they're updated. No system does these things automatically by default because it can lead to breakage going unnoticed.

[videosmith]

I know you are very busy, however since my gear is insufficient to build a 1.1.2, have you been able to release an alternate version with the cpu multithreading option reversed?

[Cuperino]

I have not. After 1.1.2 I began refactoring the entire source code to complete the move to Qt 6 and abstract components to reduce the amount of hard dependencies on Kirigami, to avoid having to wait on KDE frameworks for future migrations and be able to work on alternative user interfaces. Since then, I've had to focus on other projects that are time sensitive and I haven't been able to touch QPrompt since the 1st of October.

Releasing a version reverting the change to a single threaded renderer would require me to remove screen projections as a feature, or re-instate its old implementation. I won't be supporting two implementations for the same feature, that's a bad coding practice that increases the time spent doing maintenance work. That plus the fact that the new (screen projections) implementation performs substantially better than the previous one, limit our options to either removing screen projections or continuing to use the single threaded renderer until a better implementation is found and developed.

Removing features is almost always a bad idea, because, even when it is a seemingly useless feature, like the old Star Wars inspired projection mode Imaginary Teleprompter used to have, someone will complain that you removed it. Which makes leaving the single threaded renderer on by default our best option until a better implementation is made.

The best I can do for you at the time is what I proposed on https://github.com/Cuperino/QPrompt/issues/72#issuecomment-1247398272 and #127, which is adding means for users to manually revert to the multi-threaded renderer, effectively breaking screen projections in your instance of QPrompt, (enabling projections would show black screens instead of projections).

I could make #127 my first priority for when I start publishing 1.2.0 pre-releases to Patreon, but that is also falling behind since I decided to focus on the refactoring first.

This particular thread has become very long. Please limit new comments to the "Background opacity flickers issue", use the forum for questions, and the proposed solutions thread for comments and suggestions.

[videosmith]

As of 1.1.3, have not seen flickers so far. Contrast and Transparency disabled.

[Cuperino]

With transparency disabled from the settings, it should be impossible for this bug to occur. It doesn't mean the bug is fixed tho, for the flicker shouldn't ever happen with transparency enabled and the opacity at 100%.

[Cuperino]

The reason why it's impossible is that the whole window switches to drawing in RGB instead of RGBA after the prompter is restarted with the feature disabled. This also means faster performance for there's less color data to process.

[videosmith]

I will try those settings.