Bug 477223

Oh, some more testing I did was with MPV itself. I set the color profile inside mpv's config, removed the one from the display configuration, and then played a high-res video in mpv. The results are the same. I simply get the same frame drops in MPV as I do setting icc from display configuration. I tested mpv in x11 as well with the icc profile set the same way; I didn't change the mpv.config, and there were no frame drops. I also spent time testing KDE Plasma Wayland 5.27.9 with the icc profile set in mpv because it does work there from mpv; you can tell by the colors looking different, so I know for sure it works in mpv under Wayland in 5.27.9, and I also see no frame drops there, so this performance drop issue seems to be specific to setting a icc profile in Plasma 5.27.80's wayland session only.

(In reply to Myself from comment #1)
Damn, there is no way to edit a comment I made here, ok, this part where I said "under Wayland in 5.27.9, and I also see no frame drops there." This is wrong; ignore this. I tested again, and there is definitely the same performance drop, just not as bad as 5.27.80.

I tested again, and it seems like the reason I didn't see any frame drops in X11 was because when mpv goes into fullscreen, the compositor is disabled, in turn giving better performance. If compositing is allowed, I get the same frame drops in x11, but there is no way to disable compositing in Wayland like in X11 because Wayland manages windows, etc. with the compositor, and if that dies, the entire session dies anyway. I thought the compositing in Wayland was supposed to be more efficient. Why does the compositor cause dropped frames like on X11 and cause applications to get higher CPU usage when using an icc profile?

What hardware is this on? The alpha has some known performance issues on Intel due to driver bugs.

(In reply to Zamundaaa from comment #4)
> What hardware is this on? The alpha has some known performance issues on
> Intel due to driver bugs.

My laptop's CPU is an i5 7300hq. Also, one thing to note is that I did a system update lately, and the higher CPU usage i was having before dropped a little bit even with the icc profile set, and the frame drops lessened a little bit after an update on Plasma 6 Alpha lately. I don't know what caused the performance increase, but somehow it's slightly better.

Okay, then that's most likely already fixed in git master. Can you test a live boot of Neon unstable to confirm?

(In reply to Zamundaaa from comment #6)
> Okay, then that's most likely already fixed in git master. Can you test a
> live boot of Neon unstable to confirm?

There is a kind of bad mouse judder in KDE Neon that is only really noticeable in the overview effect when you have an icc profile set. I know KDE's latest neon unstable has later packages for Plasma 6 than what Arch has currently, so there might've been an update that messed up performance again anyway. Here's the list of the latest KDE-Unstable repository for Arch: https://archlinux.org/packages/?page=2&sort=last_update&repo=KDE-Unstable.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Can someone just tell me if color management just makes performance drop or is this really not meant to happen? Is this even a bug, or does color management just require more powerful hardware?

It's expected that KWin uses a bit more GPU power, but it shouldn't be noticeable

(In reply to Zamundaaa from comment #10)
> It's expected that KWin uses a bit more GPU power, but it shouldn't be
> noticeable
CPU: Intel i5-7300HQ (4) @ 3.500GHz 
GPU: Intel HD Graphics 630 GPU: NVIDIA GeForce GTX 1050 Mobile

Mpv running with vulkan and vulkan-hwdec on the nvidia gpu with mpv's high-quality profile set FSR and smooth video project running to get videos to 60 fps to get the soap opera effect. I know MPV is using allot of my CPU because of all these things, around 60% to 70% according to the quality of the video, but I get no frame drops. The computer is still capable, mostly, but then when the ICC profile is set, that's when frame drops and the stuttering starts. Everything is just a slightly worst experience performance-wise, and games suffer fps drops as well.

Just chiming in to confirm the same issue with the latest Plasma 6 RC1 release.

OS: Arch with kde-unstable, running kwin 5.92.0-1.
System: Ryzen 3 2200U with Vega 3 integrated graphics

A simple test that can illustrate the issue on my system:
* Open a Youtube video running at minimum 720p@60 in a Firefox or Chromium tab, with "stats for nerds" popup active
* Open and close the KDE Plasma Kicker.

Results:
* Without an ICC profile, the Kicker menu is smooth, but there are a few dropped frames in video playback (not a KDE/KWin specific issue, as even Mutter/GNOME has problems on this laptop with Wayland that isn't present on X11). The mouse cursor seems smooth.
* When an ICC profile is loaded, there is visible stuttering in the Kicker open/close animation, and more dropped frames present in the video playback compared to no ICC profile. Additionally, the mouse cursor exhibits stuttering at random times.

I'm dual booting a second Arch installation with Plasma 5 (i.e., kde-unstable is not active), and don't notice any performance reduction when using an ICC profile enabled via the older colord-kde menu.

I can't edit my comment; apologies for double posting. I discovered a simpler way to test this issue: enable KWin's FPS monitor in Window Management -> Desktop Effects.

Test method:
* From a blank desktop with no applications open or visible, repeatedly click on the KDE Kicker to induce the open/close animations while watching the FPS display.

Results:
* No ICC profile loaded: averages ~60fps (some dips to 57fps, chalking up to my integrated graphics not being so powerful)
* ICC profile loaded: averages 45fps (with dips as low as 30fps)

Unfortunately, this issue persists with KWin 6.0.1 in Arch. In case it helps, I've done some testing to try and isolate the issue.

Test procedure:
* Set Desktop Effects to defaults, then enable FPS counter
* Open a single 80x25 Konsole window, leaving visible in the middle of the screen
* With no other applications open or minimized, repeatedly click the kicker menu to trigger the open/close animation.

Some relevant results:
* Base settings, no ICC profile: 58-60fps
* Base settings with ICC profile: 30-45fps
* Blur plugin disabled with ICC profile: 55-60fps

Testing Night Light (5700K temperature forced):
* NL with no ICC profile: 58-60fps
* NL with no ICC profile, KWIN_DRM_FORCE_COLOR_MANAGEMENT=1: 30-45fps

My conclusion from the above behaviour is that the shader fallback is the primary cause of the performance issue, and can also be replicated when the Night Light is used with no ICC profile but the shader fallback is forced via the environment variable. If there is any other information I can provide, please let me know. Unfortunately, Kwin 6.0.1's X11 performance has also regressed badly on my system relative to the 5.27 release (unrelated to ICC profiles or Night Light; will file a separate bug when I have tested more thoroughly)/

Note that overall compositor performance is OK; e.g, displaying vsynctester.com in a browser will show a constant 60fps even if an ICC profile or NL + shader fallback is active, as long as no compositor effects are being triggered at the same time. The slowdown seems to occur mostly with certain desktop effects such as Blur or Overview, but other effects such as Squash or Magic Lamp have no problem maintaining a fluid 60fps.

*** Bug 482909 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5437

Git commit c26101a9fe6e7e2f94d04e700519eafa215e59cc by Xaver Hugl.
Committed on 08/04/2024 at 15:19.
Pushed by zamundaaa into branch 'master'.

backends/drm: use a swapchain instead of an OpenGL texture for the shadow buffer(s)

This seems to have better performance on Intel GPUs, and allows us to implement damage
tracking for the shadow "buffer" in the future

M  +38   -13   src/backends/drm/drm_egl_layer_surface.cpp
M  +2    -2    src/backends/drm/drm_egl_layer_surface.h
M  +9    -0    src/utils/drm_format_helper.cpp
M  +1    -0    src/utils/drm_format_helper.h

https://invent.kde.org/plasma/kwin/-/commit/c26101a9fe6e7e2f94d04e700519eafa215e59cc

I have the same exact problem/bug when using an ICC profile.
As soon as I use/apply an ICC profile from the "Display & Monitor" menu, I experience a serious graphic performance drop especially when I'm using firefox or playing videos.

Everything is smooth again once I put back "no color profile" on the "Display Monitor" menu.

OS: Fedora Linux 40

System: Ryzen 5 PRO 4650U with Radeon Graphics
KDE Plasma Version: 6.1.1
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
Kernel Version: 6.9.6-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland

Also, the same. Kwin wayland with amdgpu.

Only difference is that I enabled "Built in profile" some days ago. Thought it was a good idea to try it out.

Started noticing random slowdowns and choppiness. Then disabled animations. Then noticed that some apps that never had choppiness before, were being choppy.

Searching in the kwin bug reports for a recent regression, came across this report. Upon disabling color profile (set to none), the desktop became again sweet buttery smooth!

Don't know much how to replicate, but the logout effect (one that darkens the background and adds blur) is always choppy with color profile enabled. (as to absolutely smooth without it (or as smooth as my eyes can see it)).

---
Operating System: Garuda Linux 
KDE Plasma Version: 6.1.1
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Kernel Version: 6.9.7-2-cachyos (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor
Memory: 15.5 GiB of RAM
Graphics Processor: AMD Radeon RX 580 Series
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: X470 AORUS ULTRA GAMING

The same happened for me on amd apu 7840u,   780M, wayland, arch.
High CPU Usage of kwin process, and high GPU usage in Idle.
Workaround is to set Color Profile to none.

I'm having the same issue.
It seemed to work fine in 6.0.5, but after updating to 6.1.1, GPU usage increased noticeably.
Disabling ICC profiles fixed the issue.
I've looked in bugzilla, forums, reddit and tried lots of different things,
but disabling triple buffering and desktop blur effects didn't help.

Operating System: openSUSE MicroOS-Slowroll 20240702
KDE Plasma Version: 6.1.1
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Kernel Version: 6.6.37-1-longterm (64-bit)
Graphics Platform: Wayland
Processors: 4 × AMD Athlon 200GE with Radeon Vega Graphics
Memory: 15.1 GiB of RAM
Graphics Processor: AMD Radeon RX 6400
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: B450 AORUS M

Git commit 6bd07ad6b30e34f43652934630d30234ad65ac7c by Xaver Hugl.
Committed on 09/08/2024 at 13:18.
Pushed by zamundaaa into branch 'master'.

backends/drm: remove the shadow buffer when possible, and reduce it to 10bpc when not

Using the custom values for min. and max. luminance in transfer functions, we can reduce the
ranges of values in the shadow buffer to be limited to [0, 1], and with that we can switch
from a floating point buffer back to a normalized format. As gamma 2.2 encoding is much more
efficient at storing color values, this also drops the buffer from 16bpc down to 10bpc.

Furthermore, this offloads the gamma 2.2 -> PQ conversion to KMS when possible, and then uses
the scanout buffer with gamma 2.2 encoding directly. This way the shadow buffer gets completely
skipped and performance and efficiency get improved a lot.
Related: bug 491452

M  +7    -7    autotests/test_colorspaces.cpp
M  +7    -10   src/backends/drm/drm_egl_layer.cpp
M  +34   -26   src/backends/drm/drm_egl_layer_surface.cpp
M  +2    -2    src/backends/drm/drm_egl_layer_surface.h
M  +45   -28   src/backends/drm/drm_output.cpp
M  +11   -3    src/backends/drm/drm_output.h
M  +4    -10   src/backends/drm/drm_pipeline.cpp
M  +2    -2    src/backends/x11/standalone/x11_standalone_output.cpp
M  +1    -1    src/compositor_wayland.cpp
M  +3    -3    src/core/colorpipeline.cpp
M  +1    -1    src/core/colorpipeline.h
M  +16   -2    src/core/colorspace.cpp
M  +3    -1    src/core/colorspace.h
M  +2    -2    src/wayland/frog_colormanagement_v1.cpp
M  +1    -1    src/wayland/frog_colormanagement_v1.h
M  +3    -3    src/wayland/xx_colormanagement_v4.cpp

https://invent.kde.org/plasma/kwin/-/commit/6bd07ad6b30e34f43652934630d30234ad65ac7c

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6274

Git commit e7780f1ab3c198ff505c0417b41c93e262b997c3 by Xaver Hugl.
Committed on 21/08/2024 at 21:01.
Pushed by zamundaaa into branch 'master'.

backends/drm: implement damage tracking for the color management shadow buffer

This significantly reduces the amount of pixels that have to be repainted in most frames
while an ICC profile is set.

M  +16   -5    src/backends/drm/drm_egl_layer_surface.cpp
M  +1    -0    src/backends/drm/drm_egl_layer_surface.h

https://invent.kde.org/plasma/kwin/-/commit/e7780f1ab3c198ff505c0417b41c93e262b997c3

Just wanted to add that this also happens with the "Built-In" color profile on my Asus G14 GA402RJ (Ryzen CPU and Radeon iGPU, dGPU disabled) on KWin 6.1.4 with the AMDGPU Driver. 

With the built-in color profile enable, plasmashell was using up to 60% of my GPU at idle, according to amdgpu_top. After disabling it, the GPU utilization went down to 0.

I've read quite a few unresolved threads online about very similar sounding issues with KDE on high-performance laptops, usually in regards to the high idle power usage. Those might be unrelated though.

plasmashell is not affected by the color profile, it's applied in KWin and the shell doesn't know anything about it. If it uses a lot of GPU, that's something else.

Either way, since https://invent.kde.org/plasma/kwin/-/commit/6bd07ad6b30e34f43652934630d30234ad65ac7c the built in color profile should have effectively no performance impact.

(In reply to Ryn from comment #25)
> I've read quite a few unresolved threads online about very similar sounding
> issues with KDE on high-performance laptops, usually in regards to the high
> idle power usage. Those might be unrelated though.
There are a lot of issues with the NVidia driver specifically, but none related to this.

*** Bug 492514 has been marked as a duplicate of this bug. ***

I've tested a recent KDE Neon Unstable live cd (and now also the 6.1.90-1 unstable packages on Arch), but performance still isn't at parity with Xorg on my 2200G with Vega 3 iGPU.

Compared to Plasma 6.1.5  (both on Wayland, using same ICC profile):
* Overview and KDE Kicker open/close with transparency enabled is now smooth.
* Dragging a window (e.g. Konsole) on an empty desktop now has severe lag (dropping to 20fps).
* The cursor shake accessibility effect has severe lag (dropping to 10fps when the cursor is at maximum size).

I tried to disable all possible desktop effects but can't identify a way to mitigate the performance loss when the ICC profile is enabled. None of the above performance issues occur with no colour profile or the built-in option, but neither is suitable for my screen.

This is on Plasma 6.2 beta on Arch Linux. I'll list some of the things I've noticed with an icc profile set.

1. on an empty desktop if I move a window around, the movement is super laggy.

2. Overview is smooth.

3. Video playback is actually super smooth, unlike before no constant framedrops.

4. Kickoff animations or any animations in the panel widgets are kind of laggy—not super laggy—but noticeable.

5. Now for gaming If I turn off vsync, I get 120 fps easily. If I enable vsync, it drops as low as 50.

It's very odd how performance is random; some things perform better while some other things get worse; hopefully these all get ironed out.

I realized that the reason why the game fps seem to drops to 50 or lower is that it's trying to match the compositor framerate when it's on.

The composer itself runs on the laptop's intel integrated gpu, and the game is running from the nvidia gpu with prime offload on the latest nvidia 560 driver, so this shows that the nvidia gpu has no problems getting high fps, but because the compositor's performance drops, which is running on the integrated gpu, it in turn negatively affects the nvidia gpu even though the nvidia gpu is more than capable of getting high fps with the the icc profile set.

*** Bug 490744 has been marked as a duplicate of this bug. ***

(In reply to Rean from comment #31)
> I realized that the reason why the game fps seem to drops to 50 or lower is
> that it's trying to match the compositor framerate when it's on.
> 
> The composer itself runs on the laptop's intel integrated gpu, and the game
> is running from the nvidia gpu with prime offload on the latest nvidia 560
> driver, so this shows that the nvidia gpu has no problems getting high fps,
> but because the compositor's performance drops, which is running on the
> integrated gpu, it in turn negatively affects the nvidia gpu even though the
> nvidia gpu is more than capable of getting high fps with the the icc profile
> set.

Performance with NVidia and multi-gpu copies is still quite bad on the driver side, I'm not sure that's something we can do anything about. The ICC profile might move the needle a bit, but it's unlikely to be the cause.

I track power consumption on my Intel laptop through a sensor widget that measures at the battery, and I found that power consumption with an ICC profile with 6.1.5 (which should have the shadow buffer changes) is better than it was on the previous version, but still significantly higher than what it is with no profile applied. GPU usage seen through intel_gpu_top also backs this up, with high GPU usage on kwin_wayland. I don't believe that the shadow buffer fix alone was enough to resolve the issue. Without an ICC profile, I expect to see about 1A of current at the battery when watching a video, while with a profile on 6.1.5 I see around 1.5A and it was over 2A on previous versions.

> 6.1.5 (which should have the shadow buffer changes)
No, that's 6.2 only.

I've just updated to 6.2.0 on Fedora and I'm still experiencing serious lag/perfomance drop (moving windows around, video playback for example) when using an ICC profile.

OS: Fedora Linux 40

System: Ryzen 5 PRO 4650U with Radeon Graphics
KDE Plasma Version: 6.2.0
KDE Frameworks Version: 6.6.0
Qt Version: 6.7.2
Kernel Version: 6.10.12-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland

Git commit 80a91b1a4f7f0cb43c2666a758288533652e72ff by Vlad Zahorodnii, on behalf of Xaver Hugl.
Committed on 15/10/2024 at 11:25.
Pushed by vladz into branch 'master'.

backends/drm: upload custom geometry instead of using glScissor for optimized rendering

Empirical data suggests this yields a decent reduction in GPU usage

M  +65   -4    src/backends/drm/drm_egl_layer_surface.cpp

https://invent.kde.org/plasma/kwin/-/commit/80a91b1a4f7f0cb43c2666a758288533652e72ff

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6625

Git commit 72f1dd2af31659ea076c13bd6a5aaa686edde0b7 by Vlad Zahorodnii.
Committed on 15/10/2024 at 12:06.
Pushed by vladz into branch 'Plasma/6.2'.

backends/drm: upload custom geometry instead of using glScissor for optimized rendering

Empirical data suggests this yields a decent reduction in GPU usage


(cherry picked from commit 80a91b1a4f7f0cb43c2666a758288533652e72ff)

Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>

M  +65   -4    src/backends/drm/drm_egl_layer_surface.cpp

https://invent.kde.org/plasma/kwin/-/commit/72f1dd2af31659ea076c13bd6a5aaa686edde0b7

*** This bug has been marked as a duplicate of bug 494382 ***

This can't be a duplicate of Bug 494382 because that was opened later about Plasma 6.2. It could be the reverse though, or it could be that Plasma 6.2 has an additional regression compared to the status quo of this issue.

Can folks try again with 6.2.1.1, which will be released shortly? Hopefully that should fix it. Thanks a lot!

(In reply to Nate Graham from comment #42)
> Can folks try again with 6.2.1.1, which will be released shortly? Hopefully
> that should fix it. Thanks a lot!

Windows are not stuttering anymore when you move them around with an ICC profile set; it's smooth now.

Created attachment 174928 [details]
Process GPU usage with and without an ICC profile loaded

I upgraded to 6.2.1, and the stutter from 6.2 has disappeared for me as well. However, there is still unexpectedly high GPU usage and power consumption when an ICC profile is loaded and content on the screen is moving. There may be an overall improvement compared to 6.1.5, but the issue is still present.

I just realized when an ICC profile is set, Direct Scanout does not work at all. This can't be intentional, right, or is it?

It might have been like that for awhile, and I'm just noticing it, but Direct Scanout ceases to function in fullscreen applications when you set either the built-in icc profile or the custom icc profile.

Sounds like this is fixed now, closing again.

The direct scanout thing you noticed is probably unrelated, and also possibly expected, according to two KWin contributors I asked.

Even if it is way better (using 6.2.1.1), the system is still sluggy when an ICC profile is used. I can see it for instance in windows opening/closing animation, or when scrolling long emails with a lot of pictures as attachment.

There is no such issue under X.org.

*** Bug 494382 has been marked as a duplicate of this bug. ***

*** Bug 493438 has been marked as a duplicate of this bug. ***

*** Bug 494496 has been marked as a duplicate of this bug. ***

FWIW, in contrary to other reports saying the issue arise with Night Light, I do not seem to have any issue with that one, only with an ICC profile, whether Night Light is active or not.

I'm not getting the FPS dropping from 60 to 46 anymore in games when icc is enabled since NVidia driver version 565; the game is maintaining 60 fps. If I unlock the framerate, it goes higher than 60. Intel-gpu-top still shows around 60% to 70% render, but usage before used to be getting to 99%, so this is actually way better now.

Ok, so icc profiles are not unusable at least on my system anymore, and I'm not noticing the delays with normal desktop usage that other people are talking about. Windows actually moves around super smoothly for me. Maybe there's some performance improvements that could be done to get the render usage down more, but for me, my laptop can now handle the icc profiles on plasma.

(In reply to Bruno Pagani from comment #48)
> Even if it is way better (using 6.2.1.1), the system is still sluggy when an
> ICC profile is used. I can see it for instance in windows opening/closing
> animation, or when scrolling long emails with a lot of pictures as
> attachment.
> 
> There is no such issue under X.org.

Presumably because Xorg doesn't have ICC profile support in KWin. For the issues you mention, do they go away on Wayland when not using an ICC profile? Or are they always there on Wayland?

(In reply to Nate Graham from comment #55)
> (In reply to Bruno Pagani from comment #48)
> > Even if it is way better (using 6.2.1.1), the system is still sluggy when an
> > ICC profile is used. I can see it for instance in windows opening/closing
> > animation, or when scrolling long emails with a lot of pictures as
> > attachment.
> > 
> > There is no such issue under X.org.
> 
> Presumably because Xorg doesn't have ICC profile support in KWin.

I’m not sure what that’s supposed to mean, but I can definitively see the screen color changing when applying the ICC profile under X.org. And that has been the case for at least 7 years.

> For the
> issues you mention, do they go away on Wayland when not using an ICC
> profile? Or are they always there on Wayland?

They go away when not using an ICC profile. If they are instructions somewhere to provide some sort of profiling in both cases, I would happily follow them.

For the record, I switched to Wayland when Plasma 6.1 went out, but found it unusable due to very laggy performance and switched back to X.org. Then I read news on your blog about improvements in perfs when using an ICC profile, thought it could be related and discovered that bug. I then disabled the ICC profile and everything went smooth. After 6.2.1.1 was out, I tried to re-enable the ICC profile, and as I said it is definitively better than before (i.e. it is usable), but there is still a visible performance penalty when enabling an ICC profile, mostly visible when scrolling long contents (like this very bug page) or opening/closing windows (while before even moving the cursor was a terrible experience).

OK, thanks. So for you, even with 6.2.1.1, there is still some performance penalty. Thanks for the offer of profiling; hopefully a KWin developer can provide instructions for that.

What I meant with Xorg is that over there, applying an ICC profile is not a *KWin* feature.

What the actual hell? I thought it was the NVIDIA update, but it was just a coincidence. The new software brightness setting in Plasma, for some reason, lowers the performance impact of the icc profile When you lower it, what is going on?

I have the same experience as Bruno on a pure-Intel system, where the performance penalty is visible (GPU usage + occasional frame drops) but not debilitating, and I'd be willing to run the profiler as well if that helps.

I only found this issue due to doing a search for a different bug and finding this report, but I decided to check since I recently starting using an ICC profile after calibrating my laptop's screen. There is no noticeable lag or frame drop to my eye, so I probably wouldn't have noticed otherwise. I haven't tested if having ICC enabled or disabled impacts performance in 3D applications or battery life. With intel-gpu-top open, if I scroll up and down on this page from bottom to top over and over the "Render/3D" usage averages between 10-20% with ICC disabled, and between 25-40% with ICC enabled.

 I'm on an intel only laptop, Asus Vivobook with an intel 5 120u, no AMD or Nvidia hardware. I am running Arch linux with KDE Plasma 6.2.3, KDE frameworks 6.7.0, Qt 6.8.0, Kernel 6.11.6 under Wayland session.

(In reply to Alex B from comment #60)
> I only found this issue due to doing a search for a different bug and
> finding this report, but I decided to check since I recently starting using
> an ICC profile after calibrating my laptop's screen. There is no noticeable
> lag or frame drop to my eye, so I probably wouldn't have noticed otherwise.
> I haven't tested if having ICC enabled or disabled impacts performance in 3D
> applications or battery life. With intel-gpu-top open, if I scroll up and
> down on this page from bottom to top over and over the "Render/3D" usage
> averages between 10-20% with ICC disabled, and between 25-40% with ICC
> enabled.
> 
>  I'm on an intel only laptop, Asus Vivobook with an intel 5 120u, no AMD or
> Nvidia hardware. I am running Arch linux with KDE Plasma 6.2.3, KDE
> frameworks 6.7.0, Qt 6.8.0, Kernel 6.11.6 under Wayland session.

I have a Dell Inspiron 14 5440 with the same CPU, also without Nvidia, and I'm also on Arch Linux (EndeavourOS). Right now, without ICC, night light, or internal color profile (which actually creates an ICC profile managed by Kwin itself), I'm seeing higher GPU usage, with peaks of around 50% when moving windows, and with a slight delay, I see the cursor moving first and then the window. I reported this issue when I was on Fedora 40, and when version 6.2.0 came out (bug number 494382), the auto-consumption was fixed in version 6.2.1, but now it has returned in 6.2.3.