Cuperino
Background opacity flickers issue
Occasional "bleed through" of desktop when QPrompt is scrolling in full screen mode.
Steps to Reproduce
- Run app in single hdmi RPi monitor full screen mode
- Scroll text.
- 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]
...
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.
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.
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
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?
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: @.***>
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.
@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?
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.
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.
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.
I will swap sd cards and let you know... however the issue being intermittent makes detection problematic.
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
The 'Head' build still flickers occasionally. Am I able to completely disable transparency option, in case that's the culprit?
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.
Sounds good, thank you. I will install 1.1.2 on my RPi units and report.
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.
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.
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.
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:
- 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). - 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.
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.
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
Currently dealing with this annoyance... Unable to locate package qt5-x11extras-dev
Debian 11.5, x64 latest updates
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
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.
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.