libvisual-devel — libvisual mailinglist for developers

[Libvisual-devel] libvisual-display updates, and some extras

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

Vitaly has been completely rocking on libvisual-display!

The glx plugin works, both with framebuffer and GL, everyone
who is interested check out libvisual-display, lot's to come
in this department. I want to convert our current clients to
libvisual-display ASAP, we won't get it working before the 0.1.7
release so I plan it for the 0.2.0 release.


On the list for 0.2.0:
* Good error reporting.
* VisUI.
* Gtk1 and Gtk2 VisUI builder.
* Good Beep Media Player client (this is important, they don't have
  many visuals ported to their player yet, and we will instantly bring
  most of the xmms collection and extras, so we can be a big player    
  here).
* API reviews.
* Portability fixes.
* VisVideo it's scaler.
* Libvisual-display support in clients.
* All kind of things that come up.

When the error reporting stuff is in place, Gustavo
will be working on the python bindings, which will
enable the freevo (http://freevo.sf.net) project to
use libvisual.

This is our plan of universal domination, anyone comments ?

Cheers,
Dennis

Re: [Libvisual-devel] GL library linkage

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

I don't think wrapping ALL gl calls is a good idea, however, it might
be good to have some functions within lvdisplay to request glxcontext,
pbuffers and the such, or rather make it possible to access the GLX
stuff.

However, I'm not an expert in this area, so you guys keep on 
discussing :)!

Cheers,
Dennis

On Thu, 2004-10-14 at 12:05 +0200, Burkhard Plaum wrote:
> > One major benefit we'll get if we'll dlopen GL library is the ability
> > to use different hardware at the same time. Suppose there are
> > ATI, NVidia, S3Trio3D ;) hardware in the system, someone want to use it's
> > 3D acceleration abilities and 3 monitors. Just because.
> 
> But is this possible at all?
> Did you ever made such a setup working?
> How do you want to detect (at runtime), which lib should be dlopened?
> 
> I doubt, that current X11 installations allow this at all.
> 
> > To do this gl calls should be "objectised". Like this
> > lvglBegin(video, GL_LINES);
> >  ...
> > lvglEnd(video);
> 
> In this case, each lvgl*() function must internally call
> glXMakeCurrent() or something similar.
> If you use pure OpenGL, you call glXMakeCurrent() once.
> 
> > to call specific function. If it's done nicely it should introduce almost
> > no overhead.
> 
> In one case lemuria draws more than 5000 triangles in one frame, along with
> normal vectors and texture coordinates.
> It already pushes weaker hardware to the limit.
> 
> Propagating all these (15000+ / frame) function calls through another
> lib would make it unusable for many people.
> 
> > In theory ;) I can't see any problems with that.
> Pratice looks different in this case.
> 
> Wrapping library calls makes sense in many cases to keep things clean.
> But here, we are inside the innermost rendering loop, and speed really
> becomes important.
> 
> Hard- and Software developers spend a lot of time, to speed optimize
> OpenGL calls. So it's a bad idea to slow it down again
> only for supporting some esotheric hardware configurations.
> 

Re: [Libvisual-devel] GL library linkage

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

> One major benefit we'll get if we'll dlopen GL library is the ability
> to use different hardware at the same time. Suppose there are
> ATI, NVidia, S3Trio3D ;) hardware in the system, someone want to use it's
> 3D acceleration abilities and 3 monitors. Just because.

But is this possible at all?
Did you ever made such a setup working?
How do you want to detect (at runtime), which lib should be dlopened?

I doubt, that current X11 installations allow this at all.

> To do this gl calls should be "objectised". Like this
> lvglBegin(video, GL_LINES);
>  ...
> lvglEnd(video);

In this case, each lvgl*() function must internally call
glXMakeCurrent() or something similar.
If you use pure OpenGL, you call glXMakeCurrent() once.

> to call specific function. If it's done nicely it should introduce almost
> no overhead.

In one case lemuria draws more than 5000 triangles in one frame, along with
normal vectors and texture coordinates.
It already pushes weaker hardware to the limit.

Propagating all these (15000+ / frame) function calls through another
lib would make it unusable for many people.

> In theory ;) I can't see any problems with that.
Pratice looks different in this case.

Wrapping library calls makes sense in many cases to keep things clean.
But here, we are inside the innermost rendering loop, and speed really
becomes important.

Hard- and Software developers spend a lot of time, to speed optimize
OpenGL calls. So it's a bad idea to slow it down again
only for supporting some esotheric hardware configurations.

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

Re: [Libvisual-devel] GL library linkage

[Vitaly V. B. <vit...@us...>]

On Mon, 11 Oct 2004 15:54:52 +0200
Burkhard Plaum <pl...@ip...> wrote:

> > I think Libvisual should not be linked to libGL. It's not right
> > to link with libGL anyway - it's a kinda driver and it is different
> > for different hardware (and different driver versions, for NVIdia).
> 
> If the system is set up corrently, you can exchange the OpenGL
> libraries without breaking binaries.
Yes, most of the time, yes...

> There are MANY OpenGL programs out there, which come dynamically
> linked with OpenGL and work after you upgraded to the NVidia
> drivers.
./atlantis: /usr/lib/libGL.so.1: no version information available (required by ./atlantis)

... ugly, but it still runs.

> > It would be Much better if, say, Libvisual can dynamicaly load libGL
> > library and import its functions naming them smth like: lvglBegin()
> > etc.
> 
> So the plugin authors have to change 100s of OpenGl calls?
> I wouldn't do that.
... by hand. ;)

> If there is any "standard" in the Graphics world, it's OpenGl.
> It's available on many more platforms than libvisual will propably
> be ported to. Also the API is extremely clean and stable.
> I don't think that there are any ABI issues with OpenGL.
Agree. there should no ABI issues.

> It's a matter of taste, if you link the core lib with OpenGL or some
> driver. But plugins must assume that OpenGL is linked somehow (not
> just dlopenend).

One major benefit we'll get if we'll dlopen GL library is the ability
to use different hardware at the same time. Suppose there are
ATI, NVidia, S3Trio3D ;) hardware in the system, someone want to use it's
3D acceleration abilities and 3 monitors. Just because.

To do this gl calls should be "objectised". Like this
lvglBegin(video, GL_LINES);
 ...
lvglEnd(video);

to call specific function. If it's done nicely it should introduce almost
no overhead.

In theory ;) I can't see any problems with that.

-- 
Vitaly
GPG Key ID: F95A23B9

Re: [Libvisual-devel] Gentoo emerge fails

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

Ah, Now I recognize this, this is fixed in CVS, and thus
will be fixed in 0.1.7 :)

Cheers,
Dennis

On Wed, 2004-10-13 at 21:21 +0200, Mark van Voorden wrote:
> Hi,
> 
> While emerging xmms-libvisual-0.1.6 under Gentoo, the compiles breaks at
> the following point:
> 
> -------------------
> main.c: In function `lv_xmms_init':
> main.c:101: warning: implicit declaration of function `setlocale'
> main.c:101: error: `LC_MESSAGES' undeclared (first use in this function)
> main.c:101: error: (Each undeclared identifier is reported only once
> main.c:101: error: for each function it appears in.)
> make[1]: *** [main.lo] Error 1
> make[1]: Leaving directory
> `/var/tmp/portage/xmms-libvisual-0.1.6/work/libvisual-xmms-0.1.6/src'
> make: *** [all-recursive] Error 1
> 
> !!! ERROR: media-plugins/xmms-libvisual-0.1.6 failed.
> !!! Function src_compile, Line 502, Exitcode 2
> !!! emake failed
> !!! If you need support, post the topmost build error, NOT this status
> message.
> 
> -----------------------------
> 
> This can be fixed by adding the following line to all .c files in the src
> directory.
> #include <locale.h>
> 
> Good luck with libvisual and keep up the good work!
> 
> Regards,
> Mark van Voorden
> 

[Libvisual-devel] Gentoo emerge fails

[Mark v. V. <ma...@pc...>]

Hi,

While emerging xmms-libvisual-0.1.6 under Gentoo, the compiles breaks at
the following point:

-------------------
main.c: In function `lv_xmms_init':
main.c:101: warning: implicit declaration of function `setlocale'
main.c:101: error: `LC_MESSAGES' undeclared (first use in this function)
main.c:101: error: (Each undeclared identifier is reported only once
main.c:101: error: for each function it appears in.)
make[1]: *** [main.lo] Error 1
make[1]: Leaving directory
`/var/tmp/portage/xmms-libvisual-0.1.6/work/libvisual-xmms-0.1.6/src'
make: *** [all-recursive] Error 1

!!! ERROR: media-plugins/xmms-libvisual-0.1.6 failed.
!!! Function src_compile, Line 502, Exitcode 2
!!! emake failed
!!! If you need support, post the topmost build error, NOT this status
message.

-----------------------------

This can be fixed by adding the following line to all .c files in the src
directory.
#include <locale.h>

Good luck with libvisual and keep up the good work!

Regards,
Mark van Voorden

Re: [Libvisual-devel] VisError

[Gustavo S. B. <gu...@gs...>]

On Wednesday 13 October 2004 12:20, Dennis Smit wrote:
> On Wed, 2004-10-13 at 11:58 -0300, Gustavo Sverzut Barbieri wrote:
> > On Wednesday 13 October 2004 11:54, Gustavo Sverzut Barbieri wrote:
> > > On Monday 11 October 2004 19:30, Dennis Smit wrote:
> > > > Alright, it took me a while, but I've put some thought into this.
> > > >
> > > > 1. There won't be special reentrant functions.
> > > >
> > > > Why ?, Because when we implement an advanced error report system
> > > > we will do it reentrant by design, everywhere. If we go this road
> > > > I'd like to do it the following:
> > > >
> > > > Last function argument is of type VisError or something.
> > > > NULL can always be passed.
> > > >
> > > > It's no problem if the core breaks, Rather do it good once, than
> > > > work around half solution, or providing multiple broken interfaces.
> > > >
> > > > I personally totally go for the last argument is VisError * solution
> > > >
> > > > What do you guys think ?
> > > >
> > > > I kinda formulated my start sentence as if this is final, it's
> > > > ofcourse not, so if someone wants to discuss this, please go ahead.
> > >
> > > Dennis,
> > >
> > > Talking to a friend he mentioned TLS (Thread Local Storage). We can use
> > > that and the error will be local to the thread it happened... all for
> > > free (glibc does that).
> > >
> > > But someone need to look at it...
> >
> > Ah, the bad point is: it just work on linux and solaris... other's don't.
>
> Well I want portability. What do you think about having an extra
> VisError ** where it's needed, ofcourse far from every function really
> needs VisError. Glib does it the same way with GError.

It's ok with me.

-- 
Gustavo Sverzut Barbieri
---------------------------------------
Engenharia de Computacao 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsb...@ja...
  ICQ#: 17249123
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net

Re: [Libvisual-devel] VisError

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

On Wed, 2004-10-13 at 11:58 -0300, Gustavo Sverzut Barbieri wrote:
> On Wednesday 13 October 2004 11:54, Gustavo Sverzut Barbieri wrote:
> > On Monday 11 October 2004 19:30, Dennis Smit wrote:
> > > Alright, it took me a while, but I've put some thought into this.
> > >
> > > 1. There won't be special reentrant functions.
> > >
> > > Why ?, Because when we implement an advanced error report system
> > > we will do it reentrant by design, everywhere. If we go this road
> > > I'd like to do it the following:
> > >
> > > Last function argument is of type VisError or something.
> > > NULL can always be passed.
> > >
> > > It's no problem if the core breaks, Rather do it good once, than
> > > work around half solution, or providing multiple broken interfaces.
> > >
> > > I personally totally go for the last argument is VisError * solution
> > >
> > > What do you guys think ?
> > >
> > > I kinda formulated my start sentence as if this is final, it's ofcourse
> > > not, so if someone wants to discuss this, please go ahead.
> >
> > Dennis,
> >
> > Talking to a friend he mentioned TLS (Thread Local Storage). We can use
> > that and the error will be local to the thread it happened... all for free
> > (glibc does that).
> >
> > But someone need to look at it...
> 
> Ah, the bad point is: it just work on linux and solaris... other's don't.

Well I want portability. What do you think about having an extra 
VisError ** where it's needed, ofcourse far from every function really 
needs VisError. Glib does it the same way with GError.

Re: [Libvisual-devel] VisError

[Gustavo S. B. <gu...@gs...>]

On Wednesday 13 October 2004 11:54, Gustavo Sverzut Barbieri wrote:
> On Monday 11 October 2004 19:30, Dennis Smit wrote:
> > Alright, it took me a while, but I've put some thought into this.
> >
> > 1. There won't be special reentrant functions.
> >
> > Why ?, Because when we implement an advanced error report system
> > we will do it reentrant by design, everywhere. If we go this road
> > I'd like to do it the following:
> >
> > Last function argument is of type VisError or something.
> > NULL can always be passed.
> >
> > It's no problem if the core breaks, Rather do it good once, than
> > work around half solution, or providing multiple broken interfaces.
> >
> > I personally totally go for the last argument is VisError * solution
> >
> > What do you guys think ?
> >
> > I kinda formulated my start sentence as if this is final, it's ofcourse
> > not, so if someone wants to discuss this, please go ahead.
>
> Dennis,
>
> Talking to a friend he mentioned TLS (Thread Local Storage). We can use
> that and the error will be local to the thread it happened... all for free
> (glibc does that).
>
> But someone need to look at it...

Ah, the bad point is: it just work on linux and solaris... other's don't.

-- 
Gustavo Sverzut Barbieri
---------------------------------------
Engenharia de Computacao 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsb...@ja...
  ICQ#: 17249123
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net

Re: [Libvisual-devel] VisError

[Gustavo S. B. <gu...@gs...>]

On Monday 11 October 2004 19:30, Dennis Smit wrote:
> Alright, it took me a while, but I've put some thought into this.
>
> 1. There won't be special reentrant functions.
>
> Why ?, Because when we implement an advanced error report system
> we will do it reentrant by design, everywhere. If we go this road
> I'd like to do it the following:
>
> Last function argument is of type VisError or something.
> NULL can always be passed.
>
> It's no problem if the core breaks, Rather do it good once, than
> work around half solution, or providing multiple broken interfaces.
>
> I personally totally go for the last argument is VisError * solution
>
> What do you guys think ?
>
> I kinda formulated my start sentence as if this is final, it's ofcourse
> not, so if someone wants to discuss this, please go ahead.

Dennis,

Talking to a friend he mentioned TLS (Thread Local Storage). We can use that 
and the error will be local to the thread it happened... all for free (glibc 
does that).

But someone need to look at it... 

-- 
Gustavo Sverzut Barbieri
---------------------------------------
Engenharia de Computacao 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsb...@ja...
  ICQ#: 17249123
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net

[Libvisual-devel] XMMS plugin bugfix.

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

Duilio and list,

I've found why the xmms plugin crashed on plugin switch
when this was done throught the config dialog.

It was not synchronised with threads, I've fixed that.

Possibly there are more thread races in the
config dialog, as we really have to overview this.

Remaining big issue, GL plugins crash the xmms plugin
at startup. (aka it will only start with framebuffer
plugins).

Cheers,
Dennis

Re: [Libvisual-devel] how to "resize"?

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

On Mon, 2004-10-11 at 13:06 +0300, Vitaly V. Bursov wrote:
> Dennis,
> 
> suppose we have Libvisual running, actor playing etc. Everything's
> just fine.
> 
> Next moment we get a "resize" event.

visual_video_set_dimension (video, width, height);

(Make sure the new pitch,buffer pointer etc is set as well).

visual_bin_sync (bin, FALSE);


However the bin might throw some libvisual exception
messages, but catches all fatals... The VisBin will be rewritten
and fixed. However this should do it, try it, put it in CVS
and if there is a problem I'll check it...

Thanks,
Dennis


> The question is: how to notify everything to resize? what functions
> should be called? what order?
> 
> I can't get it... :( Libvisual examples can not make it clear...
> 
> I'm running into memory size allocations errors, usage
> of freed buffers or something and whole memory is just
> thrashed. System almost definitely will freeze if used
> with nvidias' gl.
> 
> 
> ps. had fixed a typo in oinksie. ;)

Saw so, thanks a lot :)

Re: [Libvisual-devel] VisError

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

Alright, it took me a while, but I've put some thought into this.

1. There won't be special reentrant functions. 

Why ?, Because when we implement an advanced error report system
we will do it reentrant by design, everywhere. If we go this road
I'd like to do it the following:

Last function argument is of type VisError or something.
NULL can always be passed.

It's no problem if the core breaks, Rather do it good once, than
work around half solution, or providing multiple broken interfaces.

I personally totally go for the last argument is VisError * solution

What do you guys think ?

I kinda formulated my start sentence as if this is final, it's ofcourse
not, so if someone wants to discuss this, please go ahead.

Cheers,
Dennis



On Wed, 2004-10-06 at 10:34 -0300, Gustavo Sverzut Barbieri wrote:
> Dennis Smit said:
> > Added the VisError subsystem to CVS. It consists out of:
> >
> > visual_error_raise
> > visual_error_set_handler
> >
> > I've put these in lv_error.c, lv_error.h because at a
> > later stage we might want to add more error handling
> > stuff, thus having it in it's own files is better.
> >
> > Thanks for the suggestion regarding the error handler
> > Duilio.
> 
> 
> I'm converting the C API to Python, but I want to keep thing OO using
> classes and errors via Exceptions... but I found out that I cannot really
> check what error occurred and looking at the code, many errors are not
> caught.
> 
> IMHO these visual_log() serves just for debug, but not for the programmers
> and methods to enable programmers to get the error messages should be
> allowed.
> 
> * Enabling programmers to get the error messages/code:
> 
>      The best way IMO is to create a table relating error codes to
> messages and functions should return the corresponding error (maybe
> -1 * errorcode).
>      Right now, every error is -1 and there is no way to know what happened!
>      We could have this function:
> 
>         const char *visual_get_error_message( int errcode )
>         {
>            if ( errcode < 0 ) errcode *= -1;
>            if ( errcode >= visual_error_messages_size ) errcode = 0;
>            return visual_error_messages[ errcode ];
>         }
> 
>      And the table as:
> 
>         int visual_error_messages_size = 3;
>         char visual_error_messages[][] = {
>            "Success.",
>            "Unknow Error.",
>            "Can not allocate memory."
>         };
> 
>      This way old functions will return "Unknow Error." until they're
> updated.
> 
>       To handle functions that return pointers we could have them changed
> to _r( ..., int *errcode ) and the version without _r uses the
> global error variable visual_errcode, the "_r" stands for
> "reentrant", just like libc ones. For example:
>          int visual_errcode = 0;
> 
>          VisVideo *visual_video_new_r( int *errcode )
>          {
>                  VisVideo *video;
> 
>                  video = visual_mem_new0 (VisVideo, 1);
>                  if ( video == NULL )
>                  {
>                          *errcode = -2;
>                          return NULL;
>                  }
> 
>                  video->screenbuffer = NULL;
> 
>               /*
>                * By default, we suppose an external buffer will be used.
>                */
>               video->flags = VISUAL_VIDEO_FLAG_EXTERNAL_BUFFER;
> 
>               return video;
>       }
> 
>       VisVideo *visual_video_new()
>       {
>               return visual_video_new( &visual_errcode );
>       }
> 
> 
> 
> 
> * Better Error Handling:
> 
> Take a look at visual_video_new:
> 
>                 video = visual_mem_new0 (VisVideo, 1);
> 
> Great, you allocated nothing, NULL is returned and where is it checked?
> Nowhere...
> 
> 
>                 video->screenbuffer = NULL;
> 
> Segfault! What the user/programmer knows? Nothing.
> 
> What about visual_video_new_with_buffer()?
> 
>         VisVideo *visual_video_new_with_buffer (int width, int height,
> VisVideoDepth depth)
>         {
>                 VisVideo *video;
>                 int ret;
> 
>                 video = visual_video_new ();
> 
> Uncaught error...
> 
>                 visual_video_set_depth (video, depth);
> 
> another...
> 
>                 visual_video_set_dimension (video, width, height);
> 
> even another...
> 
>                 video->screenbuffer = NULL;
>                 ret = visual_video_allocate_buffer (video);
> 
> another...
> 
>                 if (ret < 0) {
>                         /*
>                          * Restore the flag set by visual_video_new().
>                          */
>                         video->flags = VISUAL_VIDEO_FLAG_EXTERNAL_BUFFER;
>                         visual_video_free (video);
>                         return NULL;
>                 }
> 
>                 return video;
>         }
> 
> 
> 
> But since we believe programmers don't do mistake, it's okay... It should
> be used just to enforce our code does the right thing.
>    If we do the right checking on every entry point, things can be assumed
> to be all right, but as visual_video_new_with_buffer() is an entry
> point and we don't check we can't be sure it will work later.
> 
> 
> What do you think?
> 

Re: [Libvisual-devel] Libvisual VisUI system, proposal draft.

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

VisUI is ofcourse abstraction, so the UI will show (if done right)
in the native widget set, that implements the VisUI UI tree.

Maybe it's an idea if we start libvisual-widgets that contains
some standard widgets for doing this right ?

Cheers,
Dennis


On Fri, 2004-10-08 at 20:05 -0300, Gustavo Sverzut Barbieri wrote:
> Great!
> 
> > About xine, please tell us what not to do and what to do :)
> 
> Just to make clear, I'm talking about their GUI, not the internals.
> 
> Well, just open any xine-based player... they gui sucks, too much.
> 

Re: [Libvisual-devel] GL library linkage

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

It really should not indeed, never noticed that it was doing so.

If you can fix this for me, please do so!

The libvisual core doesn't need any GLness anyway.


On Mon, 2004-10-11 at 12:58 +0300, Vitaly V. Bursov wrote:
> Hi,
> 
> I think Libvisual should not be linked to libGL. It's not right
> to link with libGL anyway - it's a kinda driver and it is different
> for different hardware (and different driver versions, for NVIdia).
> 
> I'm not sure if somebody wants (I don't) to recompile GL programs
> on driver or hardware update. Libvisual itself has nothing to do
> with OpenGL, right?
> 
> It would be Much better if, say, Libvisual can dynamicaly load libGL
> library and import its functions naming them smth like: lvglBegin()
> etc.
> 
> Comments?
> 

Re: [Libvisual-devel] GL library linkage

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

Vitaly V. Bursov wrote:
> Hi,
> 
> I think Libvisual should not be linked to libGL. It's not right
> to link with libGL anyway - it's a kinda driver and it is different
> for different hardware (and different driver versions, for NVIdia).

If the system is set up corrently, you can exchange the OpenGL
libraries without breaking binaries.
There are MANY OpenGL programs out there, which come dynamically
linked with OpenGL and work after you upgraded to the NVidia
drivers.

> It would be Much better if, say, Libvisual can dynamicaly load libGL
> library and import its functions naming them smth like: lvglBegin()
> etc.

So the plugin authors have to change 100s of OpenGl calls?
I wouldn't do that.

If there is any "standard" in the Graphics world, it's OpenGl.
It's available on many more platforms than libvisual will propably
be ported to. Also the API is extremely clean and stable.
I don't think that there are any ABI issues with OpenGL.

It's a matter of taste, if you link the core lib with OpenGL or some
driver. But plugins must assume that OpenGL is linked somehow (not
just dlopenend).

The only problem I encountered were wrong RPM dependencies if an RPM
is built on a machine with the NVIDIA drivers installed. But the
Redhat/Fedora people are already aware of this.

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

[Libvisual-devel] how to "resize"?

[Vitaly V. B. <vit...@us...>]

Dennis,

suppose we have Libvisual running, actor playing etc. Everything's
just fine.

Next moment we get a "resize" event.

The question is: how to notify everything to resize? what functions
should be called? what order?

I can't get it... :( Libvisual examples can not make it clear...

I'm running into memory size allocations errors, usage
of freed buffers or something and whole memory is just
thrashed. System almost definitely will freeze if used
with nvidias' gl.


ps. had fixed a typo in oinksie. ;)
-- 
Vitaly
GPG Key ID: F95A23B9

[Libvisual-devel] GL library linkage

[Vitaly V. B. <vit...@us...>]

Hi,

I think Libvisual should not be linked to libGL. It's not right
to link with libGL anyway - it's a kinda driver and it is different
for different hardware (and different driver versions, for NVIdia).

I'm not sure if somebody wants (I don't) to recompile GL programs
on driver or hardware update. Libvisual itself has nothing to do
with OpenGL, right?

It would be Much better if, say, Libvisual can dynamicaly load libGL
library and import its functions naming them smth like: lvglBegin()
etc.

Comments?

-- 
Vitaly
GPG Key ID: F95A23B9

Re: [Libvisual-devel] Libvisual VisUI system, proposal draft.

[Gustavo S. B. <gu...@gs...>]

On Friday 08 October 2004 16:42, Dennis Smit wrote:
> On Thu, 2004-10-07 at 17:51 -0300, Gustavo Sverzut Barbieri wrote:
> > On Tuesday 05 October 2004 21:46, Dennis Smit wrote:
> > > Heya Fellahs!
> > >
> > > I made a draft for VisUI. I'd like to know what you guys think about
> > > this:
> > >
> > > http://libvisual.sf.net/VISUI_DRAFT
> >
> > Just a quick read of it and it looks good, maybe problems will appear
> > during the implementation, as always :D
> >
> > Just 2 remarks:
> >  - Don't make it as bad as xine and their config dialogs! Please!
> >  - To kick ass would be cool to have a live visualization of changes, I
> > mean, whenever possible, preview the effect of the settings.
>
> When someone changes in VisUI it gets propogated to VisParamEntry which
> will directly emit an event within the visualisation plugin that
> a parameter has changed. So as long as the propogation is set
> to be direct, the visual will respond directly as well.

Great!

> About xine, please tell us what not to do and what to do :)

Just to make clear, I'm talking about their GUI, not the internals.

Well, just open any xine-based player... they gui sucks, too much.

-- 
Gustavo Sverzut Barbieri
---------------------------------------
Engenharia de Computacao 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsb...@ja...
  ICQ#: 17249123
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net

Re: [Libvisual-devel] xmms plugin - morph on double click

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

On Fri, 2004-10-08 at 02:00 -0300, Duilio Javier Protti wrote:
> Ok, I have changed the actors list to a GtkCList widget. When double
> click on an actor, you morph immediatly. I have not test it too much, so
> please take a look.

Had a look at it, it crashes here, I can't debug from where I am,
but I'll check it out again later.

Re: [Libvisual-devel] Libvisual VisUI system, proposal draft.

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

On Thu, 2004-10-07 at 17:51 -0300, Gustavo Sverzut Barbieri wrote:
> On Tuesday 05 October 2004 21:46, Dennis Smit wrote:
> > Heya Fellahs!
> >
> > I made a draft for VisUI. I'd like to know what you guys think about
> > this:
> >
> > http://libvisual.sf.net/VISUI_DRAFT
> 
> Just a quick read of it and it looks good, maybe problems will appear during 
> the implementation, as always :D
> 
> Just 2 remarks:
>  - Don't make it as bad as xine and their config dialogs! Please!
>  - To kick ass would be cool to have a live visualization of changes, I mean, 
> whenever possible, preview the effect of the settings.


When someone changes in VisUI it gets propogated to VisParamEntry which
will directly emit an event within the visualisation plugin that
a parameter has changed. So as long as the propogation is set
to be direct, the visual will respond directly as well.

About xine, please tell us what not to do and what to do :)

Thanks,
Dennis

[Libvisual-devel] xmms plugin - morph on double click

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

Ok, I have changed the actors list to a GtkCList widget. When double
click on an actor, you morph immediatly. I have not test it too much, so
please take a look.

Bye,
Duilio.

Re: [Libvisual-devel] Libvisual VisUI system, proposal draft.

[Gustavo S. B. <gu...@gs...>]

On Tuesday 05 October 2004 21:46, Dennis Smit wrote:
> Heya Fellahs!
>
> I made a draft for VisUI. I'd like to know what you guys think about
> this:
>
> http://libvisual.sf.net/VISUI_DRAFT

Just a quick read of it and it looks good, maybe problems will appear during 
the implementation, as always :D

Just 2 remarks:
 - Don't make it as bad as xine and their config dialogs! Please!
 - To kick ass would be cool to have a live visualization of changes, I mean, 
whenever possible, preview the effect of the settings.

-- 
Gustavo Sverzut Barbieri
---------------------------------------
Engenharia de Computacao 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsb...@ja...
  ICQ#: 17249123
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net

Re: [Libvisual-devel] Preview of Python/C++ wrappers

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

On Thu, 2004-10-07 at 01:01 -0300, Gustavo Sverzut Barbieri wrote:
> Hello,
> 
> Tomorrow I'll have an exam so what I started to play with? Yes, you guess:
> Python and C++ wrappers! :D

Always keep your piorities straight, right :))

> I do not plan to code the C++, just started to play with it while I was
> looking for help with the Python version, they're quite similar, but the
> python version is more complete... If someone have interest in C++
> version, you can follow this code.

I've had a look at both, both look very nice, I also really like the C++
bindings so I might start maintaining that when the API is more stable.

Also since our idea is powerful but simple at the same time, I really
think that these bindings can be of great meaning. So keep up
the good work :)

> The Python version is incomplete also, Color, Palette and Video are
> complete, other are pending. So until now I can't have a simplesdl
> working, but I hope to have one by next week.
>    It uses classes to represent VisColor, VisPalette and VisVideo and the
> operations related to them, methods follow C API and I have some
> aliases set up, like is_depth_supported() -> depth_is_supported().
> Errors are translated into exceptions. Every Class/method have its own
> docstring (python documentation).

Sounds very good!


Cheers,
Dennis

Re: [Libvisual-devel] Re: xmms plugin

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

On Thu, 2004-10-07 at 01:20 -0300, Duilio Javier Protti wrote:
> will be on travel this weekend, I hope can do this before, but not shure
> :-(

Alright, take your time :)

> I think are all good ideas! I suggest add one more: review all the API
> functions looking for pointer arguments that will not be changed, and
> change them to 'const'.

That as well, ofcourse we should keep reviewing anyway, When you spot
something that is really out of place, or should be done different,
just post on the list :)

Cheers,
Dennis