Because it uses the XCursor format, which is a quite old standard. Getting apps to switch to a newer standard that has vector graphics is already hard enough. Getting them to do so without burning your GPU is basically impossible.
You have to re-render vector graphics when you zoom in. Otherwise they have the same pixels stored in memory as when they were first opened.
You are always viewing a bitmap image because you have a bitmap display and it makes sense they don’t load a full size cursor into memory to get rendered.
I’d be curious as to if they’ve rendered a full size image to sit in memory, or re-render the vector image directly as it grows.
Given the way games work re-rendering would be trivial for any computer running KDE so I’d take that bet.
Previously it was using whatever cursor the theme had loaded and just scaled it up. Now it references the full set of resources for the theme and picks the appropriate one for the size.
So they went with the most correct third option: defer to the standard set by a more authoritative source. :)
Kde’s mouse growing big is actually useful though.
Ever lose your mouse? Just a wiggle- which is an action I take anyway to find it- and it gets easier to find, for a moment.
Lets me make the mouse tiny.
KDE - We added a neat accessibility feature.
Gnome - THIS GOES AGAINST EVERYTHING WE STAND FOR AND ANYONE ASKING FOR IT SHOULD FEEL BAD!
I turned it off. I never need it or want it. But I won’t hate anyone else who uses it like gnome devs do.
Yes, and the low-resolution pointer when you do this excessively is just unacceptable. I’m glad they’re finally addressing this pressing concern.
The just added a high res image or whatever rather than scaling it up. Someone probably fixed it in their spare time.
What? Why isn’t it just a vector graphic?
Because it uses the XCursor format, which is a quite old standard. Getting apps to switch to a newer standard that has vector graphics is already hard enough. Getting them to do so without burning your GPU is basically impossible.
No it doesn’t it just uses metadata compatible with XCursor themes, see e.g. this discussion.
The fix was needed because the render code just used to have a maxScale: https://invent.kde.org/plasma/kwin/-/merge_requests/9176
You have to re-render vector graphics when you zoom in. Otherwise they have the same pixels stored in memory as when they were first opened.
You are always viewing a bitmap image because you have a bitmap display and it makes sense they don’t load a full size cursor into memory to get rendered.
I’d be curious as to if they’ve rendered a full size image to sit in memory, or re-render the vector image directly as it grows.
Given the way games work re-rendering would be trivial for any computer running KDE so I’d take that bet.
They re-render it, but that used to be capped with a max size: https://invent.kde.org/plasma/kwin/-/merge_requests/9176
I would assume they replaced it with an SVG that is rasterized on demand instead of a very high resolution rasterized image.
In terms of coding effort, just replacing a PNG is the easiest, but it’s also the least correct solution, imo.
I went and read the commit descriptions.
Previously it was using whatever cursor the theme had loaded and just scaled it up. Now it references the full set of resources for the theme and picks the appropriate one for the size.
So they went with the most correct third option: defer to the standard set by a more authoritative source. :)
Perfect. Thanks for being curious enough to actually look 😜
That’s coincidentally also what I do when I can’t find my dick