This System skins are not images and do not have hot spots. It is more like "take this are and please fill it with the look of widget X in state Y". It is a lot more complicated than this. And there was probably a healthy amount of guess work and trial and error involved until look under Windows got as good as it is now.
Isn't simple and also portable to ignore hotspots at all?
I mean, if we use system paint (DrawBackgroundTheme and gtk equivalent [don't have one but it's possible to "emulate"]) during resize events (how often we resize? this doesn't introduce too much overhead) and once the size is stabilized store images in cache and paint them from there when Over, Clicked etc. events happen. I know it doesn't introduce overhead because widgets in gtk and msw use this intensely, no cache is used.
That have drawbacks anyway. If i understand well, during Paint event in U++ the Button image is scaled to the current size of the button and painted on Drawing area. It means after the resized image is drawn it's freed from memory, so it use less memory how it's implemented now but use more CPU time because of scaling. If method described by me would be used then CPU used time will be minimum but memory usage is increased. My method is more efficient if we have to deal with custom themes where we don't know where a hotspot should be placed in image in order to have a good look. AFAIK hotspots are fixed so if a theme use a different larger border or different style for a button the chameleon will fail to acquire system look.
Members
Pages
Help
Register
Login
Home
but it's possible to "emulate"]) during resize events (how often we resize? this doesn't introduce too much overhead) and once the size is stabilized store images in cache and paint them from there when Over, Clicked etc. events happen. I know it doesn't introduce overhead because widgets in gtk and msw use this intensely, no cache is used.
