Hi All,
I've been working away little by little at my icons work, and I'm beginning to make a little progress: http://www.airwebreathe.org.uk/alpha-tango-icons.png
The screenshot montage shows my work on getting HICONs and HIMAGELISTs to support the alpha channel, combined with a refreshed icon set from Tango.
Right now, a lot of the changes I've made are rather bodged, but I'm encouraged because at least here we see a proof of principle.
To get this to work, I've basically had to go through fixing places where the alpha channel is incorrectly stripped or ignored. All of them are relatively easily fixed, except the ones in the stretch blt functions.
StretchBlt, StretchDIBits et al. seem to have a fast path and a slow path. The fast path is active when no stretching or translation should occur. The slow path performs all other cases, but my tests show that only the fast path preserves the alpha channel. The reason must be that the stretch is performed in X - but this is a problem, because I don't know if it's possible for X to preserve alpha. Does anyone know?
My demo has replaced the offending StretchBlts with BitBlts, which works fine, unless the icon has to be rescaled.
Does anyone have any thoughts or comments?
Thanks Joel
Joel Holdsworth schrieb:
Does anyone have any thoughts or comments?
Thanks Joel
Looks great, hope you get your code clean and soon can send patches. Why the buttons on the right top of the open-dialog are empty?
Looks great, hope you get your code clean and soon can send patches. Why the buttons on the right top of the open-dialog are empty?
Answer: Hack n' slash. I have no reproduction of the mechanism for checking which images *should* be alpha blended, and which should not - the code assumes all icons should, and so in the case of 16-bit icons the alpha channel is fixed at constant 0, and so will these icons are drawn with 0% opacity!
This is one of many things that need to be finished in my work, but the proof-of-concept is there.
Joel