Re: [Libvisual-devel] SDL and openGL plugin issues.

[Vitaly V. B. <vit...@uk...>]

On Mon, 05 Jul 2004 21:54:47 +0200
Dennis Smit <sy...@yo...> wrote:

> 
> Vitaly,
> 
> If you have some time could you look into the following:
> at: http://libvisual.sourceforge.net/LIBVISUAL_TODO
> 
> * Fixes in some GL plugins that show odd behavior after another GL
>   plugin has been running (better state setting). (everyone!!!)
Yes, I've already seen this, tried to reproduce this and failed.
And I thought it was fixed...

> This is tiresome to debug but some GL plugins show up really odd
> after another had run before (in the same execution) using
> plugin switches. This is probably easier to monitor when you
> adapt the xmms plugin to only show GL plugins and show them
> randomly...
Now I see. :) Indeed, this is due to settings left by prev. plugin.

Even worse, If a plugin allocates, say, a (large ;) texture and does
not release it during cleanup, texture will still reside in video
memory. Just like with madspin plugin: there is glGenTextures()
call and no glDeleteTextures(). The same will be with other data
like lists.

Looks like the only way to reset it nicely (everything is set to
defaults in any condition on any hw/sw) is to delete GL context
and create a new one.

And here goes a problem with SDL. To make it work right now,
you can destroy and create whole window or render surface in
SDL words. This is a bad behavior... Each plugin change (well,
gl-to-gl at least) the window will be recreated.

Another way to solve this problem is to use CVS version of SDL
in 1.3 branch. Pros and cons are pretty obvious. Does
anybody know then 1.3.0 will be released???

And the last way -- get rid of SDL and write everything ourselves
or rip off some code from Scivi ;), get potrability problems and
rewrite everythin to SDL back again when it will be released..

Dennis, I really don't know what to do with it... :)

-- 
Vitaly
GPG Key ID: F95A23B9