libvisual-devel

[Libvisual-devel] xmms roadmap

[Duilio J. P. <dp...@fc...>]

0.1.6
        There is no time!
0.1.7
        Let the user choose the input plugin
        Let the user choose the morph he want, if any.
        Let the user choose the actor plugins he want to play
(individually).
        Allows setting of params on a per-plugin basis.
0.1.8
        Let the user set the verboness of within libvisual.
        See if we must save setting through Serialize on VisParam.
0.1.9
        Wait for VisFont subsystem.
0.1.10
        Try to use VisFont subsystem.
        Show song info on the video area on play and things like that.
0.1.11
        Wait for libvisual libtool versioning system...
        and next releases will be made inpendently on the
        libvisual releases.
0.1.12
        Wait for VisUI
0.1.13
        ?

Bye,
Duilio.

Re: [Libvisual-devel] xmms roadmap

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

When you incorporated my comments, I will add it to the roadmap!

On Fri, 2004-09-10 at 01:05 -0300, Duilio Javier Protti wrote:
> 0.1.6
>         There is no time!
> 0.1.7
>         Let the user choose the input plugin
>         Let the user choose the morph he want, if any.
>         Let the user choose the actor plugins he want to play

Maybe an idea to support 'random morph plugin' option as well.

> (individually).
>         Allows setting of params on a per-plugin basis.
I wouldn't implement this right now, but rather wait till VisUI landed
which can give UI hints regarding the param and such. But that is
up to you!

> 0.1.8
>         Let the user set the verboness of within libvisual.
>         See if we must save setting through Serialize on VisParam.
I doubt if the xmms plugin itself needs serialization through libvisual.

> 0.1.9
>         Wait for VisFont subsystem.
> 0.1.10
>         Try to use VisFont subsystem.
>         Show song info on the video area on play and things like that.
This will be handled in libvisual itself! through an API ;)
(so every client can use it directly)

> 0.1.11
>         Wait for libvisual libtool versioning system...
>         and next releases will be made inpendently on the
>         libvisual releases.
Totally agree

> 0.1.12
>         Wait for VisUI
> 0.1.13
>         ?
> 
> Bye,
> Duilio.


Cheers,
Dennis

[Libvisual-devel] Re: xmms roadmap + VisCPU API

[Duilio J. P. <dp...@fc...>]

> When you incorporated my comments, I will add it to the roadmap!
>
> > 0.1.6
> >         There is no time!
> > 0.1.7
> >         Let the user choose the input plugin
> >         Let the user choose the morph he want, if any.
> >         Let the user choose the actor plugins he want to play
> 
> Maybe an idea to support 'random morph plugin' option as well.

Sounds good.

> > 0.1.8
> >         Let the user set the verboness of within libvisual.
> >         See if we must save setting through Serialize on VisParam.
> I doubt if the xmms plugin itself needs serialization through libvisual.

I'm agree with you.

> > 0.1.9
> >         Wait for VisFont subsystem.
> > 0.1.10
> >         Try to use VisFont subsystem.
> >         Show song info on the video area on play and things like that.
> This will be handled in libvisual itself! through an API ;)
> (so every client can use it directly)

Oh, good.

In regard of VisCPU module, there is an idea about the API?

Bye,
Duilio.

Re: [Libvisual-devel] Re: xmms roadmap + VisCPU API

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

Updated the roadmap:

http://libvisual.sourceforge.net/LIBVISUAL_ROADMAP

Re: [Libvisual-devel] Re: xmms roadmap + VisCPU API

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

On Tue, 2004-09-14 at 23:24 -0300, Duilio Javier Protti wrote:
> > Maybe an idea to support 'random morph plugin' option as well.
> Sounds good.

> > I doubt if the xmms plugin itself needs serialization through libvisual.
> I'm agree with you.

> > > 0.1.9
> > >         Wait for VisFont subsystem.
> > > 0.1.10
> > >         Try to use VisFont subsystem.
> > >         Show song info on the video area on play and things like that.
> > This will be handled in libvisual itself! through an API ;)
> > (so every client can use it directly)
> Oh, good.
> 
> In regard of VisCPU module, there is an idea about the API?

Well, there is not a real API yet no, there is a header file, but if you
can design a useful API that would be good! *heheheh*. Also, we need
to make sure that through an API call, mmx, etc can be disabled.

Cheers,
Dennis

[Libvisual-devel] Re: VisCPU API

[Duilio J. P. <dp...@fc...>]

> > In regard of VisCPU module, there is an idea about the API?
> 
> Well, there is not a real API yet no, there is a header file, but if you
> can design a useful API that would be good! *heheheh*. Also, we need
> to make sure that through an API call, mmx, etc can be disabled.
> 
> Cheers,
> Dennis

We can disable mmx within libvisual, but there is no way to
disable mmx on the whole process (even the OS can't do that).

The question is how to let the libvisual users disable/enable
mmx stuff. If we give something like:

int visual_cpu_enable_mmx (int yes_or_no);

on the VisCPU module, the problem is what to do if some plugin
enables mmx, but then other plugin (say on morphed switch) disable it.
We must denied or not? If we accept, we must tell the others
plugins that mmx activation has changed, so we must let plugins
register a callback for that:

int visual_cpu_enable_mmx (int yes_or_no, void (*) (void *));

The other possibility is to enable/disable mmx stuff only through
a visual_init() parameter. I like more this, because this is done
just once per application, and because main application have 
enough information to decide whether or not it must activate mmx
stuff.


Bye,
Duilio.

Re: [Libvisual-devel] Re: VisCPU API

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

On Wed, 2004-09-15 at 23:52 -0300, Duilio Javier Protti wrote:
> We can disable mmx within libvisual, but there is no way to
> disable mmx on the whole process (even the OS can't do that).
> 
> The question is how to let the libvisual users disable/enable
> mmx stuff. If we give something like:
> 
> int visual_cpu_enable_mmx (int yes_or_no);


I had exactly this in mind, the plugins should always check
capabilities through VisCPU subsystem, and This way we can
disable certain capabilities through the VisCPU system.

> on the VisCPU module, the problem is what to do if some plugin
> enables mmx, but then other plugin (say on morphed switch) disable it.
> We must denied or not? If we accept, we must tell the others
> plugins that mmx activation has changed, so we must let plugins
> register a callback for that:

Have to think about this, generally plugins should be touching
the capabilities, as in changing them. But still, have to
think about it.

> int visual_cpu_enable_mmx (int yes_or_no, void (*) (void *));
> 
> The other possibility is to enable/disable mmx stuff only through
> a visual_init() parameter. I like more this, because this is done
> just once per application, and because main application have 
> enough information to decide whether or not it must activate mmx
> stuff.

Well, not through visual_init, but through an initialization call.

I think that, having the app decide if it should be enabled or not
is best indeed. However now we have the next problem. What about
threaded render pipeline. (at morph, two actors in both a thread)
for heavy use in mutliCPU machines... (Why O why does mmx
share it's regs with FPU...) We should so get into SSE as well :)

Cheers,
Dennis