Re: [Libvisual-devel] Re: Libvisual

[Burkhard P. <pl...@ip...>]

> The application has final control, so I was thinking about the plugin.
> We can have a flag within the VisActorPlugin structure 
> like .fps_preferred .
Ok, that's good.

> But what is the usage, of trying to draw frames, if it's not getting
> displayed anyway ? 
You're right, that should be avoided.

> In the case that you get anough audio samples for
> a high framerate, what is the use of asynchronous rendering? 

On weaker CPUs, one visualization plugin might slow down the whole
process (in the worst case, also the audio playback). Imagine a player,
which does something like:

while(1)
   {
   get_next_samples();
   send_samples_to_soundcard();	
   send_samples_to_libvisual();
   }

If send_samples_to_libvisual() renders and displays everything
synchronously, the soundcard buffer might underrun, which won't sound
that good.
So at least at one point between the playback loop (which drives the
soundcard) and the visualization, things should be decoupled.

If it's in the application, inside libvisual, or inside the plugin,
doesn't matter.

Xmms says, that the render_* functions shouldn't take long (for the
reason described above). This implies, that plugins, which are more CPU
intensive, should be threaded.

>> this doesn't interfer with syncing OpenGL to the monitor refresh rate
>> it could be ok.

> It won't because that is in glx it's hands. (right ?)

It's enabled via an enviroment variable (for the NVidia drivers at least).
The application cannot control the Gl<->Monitor sync.

> We will surely make an good API that can let plugins request any format
> they want!
Ok.

> We're creating this, through improving libvisual and introducing
> libvisual-display.

The libvisual-display seems to be crucial. Keep me updated, when
there is something in CVS.

>>A workaround for this could be to copy the OpenGL framebuffer into
>>system memory and use the same display methods as for 2D plugins.
>>Maybe the PCs in 2010 can do this at 1280x1024 :-)
> 
> Heheh, well, that is a dirty solution ofcourse, might be even
> good for those video editing stuff, but not for what we want !
> but you know that as well lol.

Actually, lemuria does this for it's 256x256 texture: Copy the
framebuffer into a texture and into memory, exchange some colors
and copy it back into a second texture.
Because sometimes the foreground and background have
the same texture image, only the colors are swapped.

The funny thing is, that most people think, they are completely
different images :-)


-- 
_____________________________
Dr.-Ing. Burkhard Plaum
Institut fuer Plasmaforschung
Pfaffenwaldring 31
70569 Stuttgart
Tel.: +49 711 685-2187
Fax.:            -3102