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. :)
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.
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.
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. :)