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