Re: [Libvisual-devel] Re: Libvisual

[Dennis S. <sy...@yo...>]

On Wed, 2004-09-15 at 12:05 +0200, Burkhard Plaum wrote:
> > Well, how can an app take the best depth, without knowing it ?. 
> 
> Maybe because libvisual handles the Window/Visual/depth
> stuff?

Libvisual handles the visual/depth. NOT THE WINDOWS. that is the
whole point. Because of this you can literally draw a visual
anywhere. But because we don't want the app to handle windowing
itself, we are planning to introduce libvisual-display. To solve
this issue, and have more control!

> It's nice if visualization plugins can be window system independent.
> But IMHO it would even be better if applications also don't need to
> care about it.
> I didn't dig too deep into libvisual yet, so maybe I sound stupid.

I agree with you, this is why we plan libvisual-display. But it needs
to be coded, and we aren't with many people :)

> > What about a system that tells libvisual,
> > 'I'd REALLY like THIS framerate' and then libvisual implements
> > an easy to use framerate limiter. 
> 
> Who tells it, the application or the vis plugin?

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

> > Some guys are doing VJ software
> > combined with realtime video software with it.
> 
> Ok, then we need the framerate forced by the application.

Optionally, forced, yes OPTIONALLY :) Also this LiVES stuff uses
only framebuffer plugins, because it mixes with video clips.

> > Most plugins don't obtain this framerate, it's not a problem that
> > not each sample a picture is generated.
> 
> Exactly :-)
> And this is, where it gets asynchronous!

But what is the usage, of trying to draw frames, if it's not getting
displayed anyway ? In the case that you get anough audio samples for
a high framerate, what is the use of asynchronous rendering ? And if
you can't obtain the framerate, what does asynchronous help in this ?

> > As said, we can use a FPS limiter provided by libvisual, or wouldn't
> > that be sufficient ?
> 
> If 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 ?)

> > The audio core gets redone eventually, so don't rely too much on this
> > '512' thing.
> 
> Oops, the 512 samples are hardcoded everywhere inside lemuria and many
> other plugins. It's in the xmms API (and thus also in winamp I would guess).

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

> > What is needed, in facilities, within libvisual to make it possible ?
> > (as you can guess by now, I only use threads when it's absolutely
> > needed, no way around it). Ofcourse as a plugin writer, it's your
> > choice. But I'd rather make some facilities in libvisual to work
> > it out threadlessly, than using threads.
> 
> Ok, IMHO there need to be at least 2 different layers. One,
> which handles the pcm -> picture stuff synchronously and
> threadless. The other one handles the window/displaying/framerate
> stuff.

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

> For 2D plugins like goom, these two can completely be separated.
> You can make a picture even without knowing into which window
> it will be displayed later on.

Yep, for OpenGL this is a different case ofcourse

> The problem is for OpenGL, because rendering a picture looks like
> (speaking for GLX only):
> .....
> And glXSwapBuffers can (and should) be synched to the monitor as
> I said.

Yep.

> 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.

> I can't hack a lot for libvisual due to lack of time,
> but I would really like to discuss APIs for the display stuff
> when they get written.

That is ok, Discussion APIs is contribution. Two know more than one
so to say.

> I think libvisual is a good approach, but It will cost some
> brain cycles to make it meet all requirements :-)

That is why it's good to have many people on the list, so
we can distribute those brain cycles *grin*..


Thanks for all your comments, it's sure worth stuff!

Cheers,
Dennis