Bug 436803 - Weird flickering when list of apps is refreshed
Summary: Weird flickering when list of apps is refreshed
Status: RESOLVED FIXED
Alias: None
Product: plasma-systemmonitor
Classification: Applications
Component: general (show other bugs)
Version: 5.21.4
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KSysGuard Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-09 00:08 UTC by medin
Modified: 2021-06-01 13:11 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.22
Sentry Crash Report:


Attachments
Weird flickering when list of apps is refreshed (512.91 KB, video/mp4)
2021-05-09 00:08 UTC, medin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description medin 2021-05-09 00:08:56 UTC
Created attachment 138262 [details]
Weird flickering when list of apps is refreshed

This happens only when I select an element in the list of apps, See attached video for more info.
 
NB : this problem is not present with KSysguard.

Operating System: Manjaro Linux
KDE Plasma Version: 5.21.4
KDE Frameworks Version: 5.81.0
Qt Version: 5.15.2
Kernel Version: 5.4.112-1-MANJARO
OS Type: 64-bit
Graphics Platform: X11
Comment 1 Nate Graham 2021-05-10 22:52:49 UTC
Cannot reproduce. Looks graphics-related. What kind of graphical hardware does your system have?
Comment 2 medin 2021-05-10 23:05:49 UTC
(In reply to Nate Graham from comment #1)
> Cannot reproduce. Looks graphics-related. What kind of graphical hardware
> does your system have?

I have an intel cpu with integrated graphics and use modesetting driver. I don't think it's related to hardware because from what I know the new monitor app is build with same Qt framework as KSysguard which doesn't suffer from this problem at all.
Comment 3 Nate Graham 2021-05-10 23:12:07 UTC
Not exactly. :)

KSysGuard was written with QtWidgets, which is an older set of Qt-provided UI components and exclusively renders using the CPU, not your graphics hardware (if present). System Monitor is written with QtQuick, which is a newer Qt UI component set which can render using the GPU for reduced CPU usage and lower power usage as well as better visual effects. However this means that these apps are exposed to rendering glitches from buggy GPU drivers.
Comment 4 medin 2021-05-10 23:47:21 UTC
(In reply to Nate Graham from comment #3)
> Not exactly. :)
> 
> KSysGuard was written with QtWidgets, which is an older set of Qt-provided
> UI components and exclusively renders using the CPU, not your graphics
> hardware (if present). System Monitor is written with QtQuick, which is a
> newer Qt UI component set which can render using the GPU for reduced CPU
> usage and lower power usage as well as better visual effects. However this
> means that these apps are exposed to rendering glitches from buggy GPU
> drivers.

Thanks, that explains why the new monitor app seems little slower to open and load data.
Comment 5 Bug Janitor Service 2021-05-13 20:46:42 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-systemmonitor/-/merge_requests/129
Comment 6 David Edmundson 2021-05-17 10:03:54 UTC
Git commit 05ca503aa63e579d1b5d774e90d945d8e0433993 by David Edmundson.
Committed on 17/05/2021 at 10:02.
Pushed by davidedmundson into branch 'master'.

Fix flickering in table view

We have a list of delegates:

Whenever we get a layoutChange signal (from a re-order), table view
recycles all of them. Every binding, text and value changes.

Our backgrounds have two rectangles:

    One does a white or grey line:
```
color: (row % 2 == 0) ? Kirigami.Theme.backgroundColor :
Kirigami.Theme.alternateBackgroundColor
```

    One draws the highlight:
```
	color: Kirigami.Theme.backgroundColor
        Kirigami.Theme.inherit: false
        Kirigami.Theme.colorSet: Kirigami.Theme.Selection
        opacity: selected ? 1: 0
```

That's all well and good, but we don't want the text to be black on
blue, so there's some code here that handles this in the parent item of
the cell background.

```
	Kirigami.Theme.colorSet: background.selected ?
Kirigami.Theme.Selection : Kirigami.Theme.View
	Kirigami.Theme.inherit: false
```

A noticable quirk there is that our background to draw the white and
grey alternating rows actually draws a blue background because it
inherits the selected colourSet from our parent Kirigami.Theme. That is
marked as being "Selection" not "View"

Why does that cause a problem?

After a reshuffle what happens is:

 - All bindings update, Qt does everything perfectly

 - The colours in the real highlight update on time

- The colours in the background are delayed because they come from the
parent ColorSet

- Kirigami theme propagation has some "event compression" before
propagating to children. IMHO this is a Kirigami bug.

- The old selected item which is now some random item renders a blue
highlight where it should be rendering the white or grey background.

This patch moves logic for the selection colour into rectangle for
drawing the main background, whic also means we explicitly set a
Kirigami.ColorSet there.

This also helps differentiate highlighted + vs highlighted + mouse over
which brings it more in line with the desktop.

M  +5    -2    src/table/CellBackground.qml

https://invent.kde.org/plasma/plasma-systemmonitor/commit/05ca503aa63e579d1b5d774e90d945d8e0433993
Comment 7 David Edmundson 2021-06-01 12:02:53 UTC
Git commit 3da9fda948ebe1e41e31e4d302ef907fe182ab6f by David Edmundson.
Committed on 01/06/2021 at 12:01.
Pushed by davidedmundson into branch 'Plasma/5.22'.

Fix flickering in table view

We have a list of delegates:

Whenever we get a layoutChange signal (from a re-order), table view
recycles all of them. Every binding, text and value changes.

Our backgrounds have two rectangles:

    One does a white or grey line:
```
color: (row % 2 == 0) ? Kirigami.Theme.backgroundColor :
Kirigami.Theme.alternateBackgroundColor
```

    One draws the highlight:
```
	color: Kirigami.Theme.backgroundColor
        Kirigami.Theme.inherit: false
        Kirigami.Theme.colorSet: Kirigami.Theme.Selection
        opacity: selected ? 1: 0
```

That's all well and good, but we don't want the text to be black on
blue, so there's some code here that handles this in the parent item of
the cell background.

```
	Kirigami.Theme.colorSet: background.selected ?
Kirigami.Theme.Selection : Kirigami.Theme.View
	Kirigami.Theme.inherit: false
```

A noticable quirk there is that our background to draw the white and
grey alternating rows actually draws a blue background because it
inherits the selected colourSet from our parent Kirigami.Theme. That is
marked as being "Selection" not "View"

Why does that cause a problem?

After a reshuffle what happens is:

 - All bindings update, Qt does everything perfectly

 - The colours in the real highlight update on time

- The colours in the background are delayed because they come from the
parent ColorSet

- Kirigami theme propagation has some "event compression" before
propagating to children. IMHO this is a Kirigami bug.

- The old selected item which is now some random item renders a blue
highlight where it should be rendering the white or grey background.

This patch moves logic for the selection colour into rectangle for
drawing the main background, whic also means we explicitly set a
Kirigami.ColorSet there.

This also helps differentiate highlighted + vs highlighted + mouse over
which brings it more in line with the desktop.
(cherry picked from commit 05ca503aa63e579d1b5d774e90d945d8e0433993)

M  +5    -2    src/table/CellBackground.qml

https://invent.kde.org/plasma/plasma-systemmonitor/commit/3da9fda948ebe1e41e31e4d302ef907fe182ab6f