Luca Olivetti wrote:
Ville Skyttä wrote:
On Sat, 2005-04-02 at 18:47 +0200, Luca Olivetti wrote:
Ville Skyttä wrote:
Yep, that's expected. Before the patch, colors weren't being "freed" in OSD_Close, but were left reserved even though nothing in the OSD was using them any more. That obviously resulted in the whole whopping limit of 16 colors reaching the top sooner than supposed.
Since freeing colours should be better, then why the strange problem after using the yaepg plugin?
Beats me, I've never looked at yaepg... perhaps it's not closing the OSD properly or something.
Ok, your fix is wrong, I have (what seems to be) the correct one. I will try it a bit more, clean it up a bit and send it later.
Here's the patch, to apply with neither yours or Martin's one applied. Since things are starting to get confusing, I'm also attaching the complete files I'm using in a tgz. Basically there were 2 problems: 1) colors are added multiple times but removed only once[*] when the osd is closed, so the usage count would never get to 0 and the colors would never actually be freed. The fix is to set m_colors to one instead of incrementing it each time. [*]that's not exactly true but it doesn't matter since the osd is being closed anyway.
2) RemoveColor expected a color, but the colors in m_window are actually indexes coupled to transparency values. The fix is to change RemoveColor to accept an index instead. There's also a futile attempt to use the nearest color when the palette is full, but I doubt it's really useful.
Bye