Re: [Libvisual-devel] plans for 0.1.6

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

On Tue, 2004-06-29 at 14:21 -0300, Duilio Javier Protti wrote:
> > * Add copyright notice to all the files in every package.
> I will do that on XMMS plugin and all the actor plugins, 
> if you like.

We should make a script that does this for us in every
module. However before doing so. We first have to define
the exact copyright notice header. I also want to include
$id, some info about the authors etc in it.

> > * Use good libtool versioning.
> On these issue, I will do some experiments on my system
> and when all works well, I will submit details to the
> list and after that, if all agree, I will submit to the
> repository.

Very cool, this is really a job for you :) I suck with
build tools so it seems *hehe*.

> Dennis, we will use stable/devel branches, or just an
> unique main line?

For now we use one main line. When the library gets more mature
and requires stable ABI/API compatibility we will start stable
and devel branches.

> > * Fix alphabetic list for functions within doxygen generated docs.
> > * Param system, both local and global.
> Do you make this, Dennis, right?

I will do the param system. I have looked at the doxygen stuff
and I don't understand why it's only alphabeticly listing
structures and not functions. Gustavo maybe you can have
a look at this ?

> > * Timed morph.
> Good!!! Be careful about the system you use to timing, because
> LibVisual is a dynamic library, and the main application could
> be using timers also, and in general we can trash all the thing.
> 
> If we doesn't need high-precision timers, I suggest to make our
> own sleep, using select. I can do it if you want.

That would be good. It would be nice to have it clock screw proof.
Also what timed morphs do is calculating how much the percentage
of morph should be increased to be morphed on time. Doing this
every frame kinda like an FPS limiter but different :)

> > * Method to check if a certain morph requests VisAudio context.
> > * Fix coverart support.
> > * Byte swap helper functions to fix endianess issues (lv_bmp for 
> >   example).
> I can check for endianess on configure script, and then 
> set __LV_IS_LITTLE_ENDIAN and __LV_IS_BIG_ENDIAN macros
> on the lvconfig.h file.

Please do so! Then I will implement byte, word swap functions
like SDL does.

> > Libvisual-plugins:
> > * Include gustavo's mplayer input plugin.
> > * Fixes in some GL plugins that show odd behavior after another GL
> >   plugin has been running (better state setting).
> > * GdkPixbuf image loader (actor).
> > * Webcam plugin (actor).
> Good!!
> 
> > * Fix the 16, 24, 32 bits support for the flash morph.
> > * Infinity updates.
> Oh, work for me.

I meant updates you have been putting in the separated infinity
plugin for xmms.

> > * Loads of cleanups.
> > 
> > Libvisual-nebulus:
> > * Move the textures into a .bmp and use the libvisual bmp loader.
> > 
> > Libvisual-xmms:
> > Duilio you've been playing with the xmms plugin lately so I'm sure you
> > can add some items here :)
> 
> My only wish about XMMS plugin is that it doesn't crash :-)
> I will hunt the bug until catch it.

Very nice :) My personal interest is to (also) have a very good stand
alone version at some point so it is not xmms bound. So it's very cool
that you have more interests in the xmms plugin! :)

> About the VisBin mess that you mention, Can you make a list
> of all the troubles with the current implementation?

The basic problems are that the code is being a mess, unmaintable and
even not understandable. I've overseen some issues, and hacked them
'right'. The biggest issue is the managed bin. And we really want to
have that working.

Issues that I'm not able to solve with current codebase:
* When switching actors >REALLY< fast it'll crash because of corruption
in the video context pointer. I have no single idea what is causing
this.

* When switching from a 8 bits plugin to a 32 bits plugin then while
morphing back to the 8 bits plugin will keep the target display in 32
bits mode.


These are the most important user visible problems. But the real problem
is the code itself and I've got to sit down, write down the requirements
and design it on paper first. This will have to wait for a while but
surely will get fixed.

Gustavo, JC do you people have something to add to the list ?

If not I will generate a final 0.1.6 roadmap and add who does
what information.

Cheers and thanks,
Dennis