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.
Theoretically speaking, you could draw directly from vector data instead of generating a texture as an intermediate step. Or you could use a signed distance field to sample from instead of a regular bitmap.
Would it be absolutely bonkers and utterly incompatible with any legacy software? Suuure, but you would get a perfectly crisp cursor after all that wiggling.
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. :)
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.
Theoretically speaking, you could draw directly from vector data instead of generating a texture as an intermediate step. Or you could use a signed distance field to sample from instead of a regular bitmap.
Would it be absolutely bonkers and utterly incompatible with any legacy software? Suuure, but you would get a perfectly crisp cursor after all that wiggling.
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 😜