I love articles like these. Sprite-based hardware acceleration fascinates me. It’s just so different from what modern day graphics cards do. Today it’s inconceivable to hardware accelerate what boils down to copying a bunch of small byte patterns into a frame buffer.
No animation here, but more powerful CPU generally in use and therefore easy enough to apply effects to reflect user’s preference at app / desktop component startup without noticeable delay:
For a while I used desaturated icons which lit up with colour when hovered over - and some semi-transparency, if I remember correctly.
It was interesting implementing some of the effects, as it can be surprising what makes them run faster or slower on different CPUs
Also it was interesting to learn that linear operations on R, G and B channels don’t line up with human perception. Its not a huge problem for icon effects, though if you’re playing with a photo it would be much more obviously ‘wrong’.
I love articles like these. Sprite-based hardware acceleration fascinates me. It’s just so different from what modern day graphics cards do. Today it’s inconceivable to hardware accelerate what boils down to copying a bunch of small byte patterns into a frame buffer.
No animation here, but more powerful CPU generally in use and therefore easy enough to apply effects to reflect user’s preference at app / desktop component startup without noticeable delay:
https://api.kde.org/frameworks-api/frameworks-apidocs/frameworks/kiconthemes/html/classKIconEffect.html
For a while I used desaturated icons which lit up with colour when hovered over - and some semi-transparency, if I remember correctly.
It was interesting implementing some of the effects, as it can be surprising what makes them run faster or slower on different CPUs
Also it was interesting to learn that linear operations on R, G and B channels don’t line up with human perception. Its not a huge problem for icon effects, though if you’re playing with a photo it would be much more obviously ‘wrong’.