[Libvisual-devel] Re: Libvisual

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

Hi,

> We want to make an API that supports extra capabilities depending on
> the display target being used (plugable).

That sounds good.

> When an app notifies libvisual that it ONLY supports 16 bit and lower
> libvisual will transform 24 and 32 bits surfaces to 16 bit internally.

So it seems that apps still need to know a lot about the
display properties. For xine, mplayer and such, this would be
no problem, but if someone wants just to write a quick and dirty
visualisation app (like gmerlin-visualizer)?

> Like SDL did kinda ?

Probably, but as I said, I don't really like (i.e. know) SDL.
glut and gtkglarea are also exmaples, where apps can pass the
required OpenGL properties.

> I rather have the burdon on libvisual, because that way we don't force
> anything. An example is video editing. There is a program LiVES
> (lives.sf.net) If I'm not wrong that is used for VJ productions. Since
> ehm, this weekend it also supports libvisual, but it's not drawn
> in realtime because of al the video stuff. Basicly we want to take
> as much as possible out of the plugins.

Keeping plugins simple is good.
The problem is that for lemuria, time == frame_count.
Many effect mechanisms (e.g. the animated texture on most
foreground objects) rely on a constant and known framerate.

If you do completely synchronous rendering (i.e. render one picture
each 512 samples), you must render 44100/512 = 86 fps for lemuria.
I don't think, that a "standard" consumer PC is able to do this,
when full antialiasing is enabled :-)

In addition, OpenGL (i.e. GLXSwapBuffers) can be synched to
the vertical frequency of the monitor, and for the high-speed
scenes in lemuria, this is strongly recommended.
Being in sync with both the music and the monitor is impossible.

In addition, the animation speed would change, if one switches to
a track with a different samplerate. For spectrum analyzers, this
doesn't matter but for lemuria it does!

I meditated a lot about this when writing lemuria. The only possible
solution was to render in a separate thread using the
most recent audio samples and limit the framerate using a
software timer (to ca. 30 fps in my case). On weak hardware,
the animation speed becomes slower, but it's always independent
from the audio signal.

Whether the plugins or libvisual handles this is a matter of taste,
but completely synchronous rendering is not possible.

On the other hand, if I use goom for making textures, I also
use synchronous rendering (pass audio samples and get a picture).
For goom2k4, I no longer use the xmms plugin but the
goom library.

>>If libvisual handles all this, the best would be to start an own
>>thread for each plugin. In addition, each plugin should have it's
>>own Display* connection to completely avoid X11/multithread
>>related crashes.
> 
> Keep in mind, that we really don't want to just depend on X11, it should
> work everywhere, framebuffer, gstreamer, xine, whatever you'd like.

I know, I was only talking about the X11 case (the most interesting
for me).

> Well, since a libvisual pipeline is a synchronous stream I don't
> see the reason for threading.

I do (see above) :-)

>>One small thing: make DESTDIR=<some_dir> does not work.
>>It's needed when you want to make rpms.
> 
> How do I solve that, Duilio is doing most of the auto* stuff :)

The problem is the install-exec-local target. There is an
explicit reference to $(prefix)/include/libvisual, which isn't
changed by the DESTDIR mechanism. Maybe using $(includedir) would
help.

Cheers

Burkhard

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