Menu
▾
▴
libvisual-devel — libvisual mailinglist for developers
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(38) |
May
(22) |
Jun
(92) |
Jul
(101) |
Aug
(18) |
Sep
(286) |
Oct
(180) |
Nov
(73) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(18) |
Feb
(74) |
Mar
(56) |
Apr
(11) |
May
(5) |
Jun
(4) |
Jul
(20) |
Aug
(4) |
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
| 2006 |
Jan
(11) |
Feb
(2) |
Mar
(10) |
Apr
(2) |
May
(1) |
Jun
|
Jul
(24) |
Aug
(11) |
Sep
(5) |
Oct
(16) |
Nov
(25) |
Dec
(8) |
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
(4) |
Nov
(12) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
|
From: Gustavo S. B. <gu...@gs...> - 2004-10-22 01:15:20
|
On Thursday 21 October 2004 18:25, Dennis Smit wrote: > Heya, well, I like to keep you guys updated, so here we go: > > http://www.plasser.nl/synap/libvisual/visui_gtk_demo5.png > > Code: > actor = visual_actor_new ("madspin"); > visual_actor_realize (actor); > main = visual_plugin_get_userinterface (visual_actor_get_plugin > (actor)); > > vuic = lvwidget_uicontainer_new (main); > > gtk_container_add (GTK_CONTAINER (window), vuic); > > > We're getting there for sure ! Sure! I hope you're willing to implement support for help on items, with tooltips and things like that. The example you give is self explanatory, but other options are so obscure to users that might need even multimedia explanations... maybe html support for these? -- 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 |
|
From: Gustavo S. B. <gu...@gs...> - 2004-10-22 01:11:14
|
On Thursday 21 October 2004 14:25, Dennis Smit wrote: > Heya, > > What do you guys favor: > > visual_video_set_buffer or visual_video_set_pixels ... ? visual_video_set_buffer() but I like video->pixels more... so take which one you like :/ -- 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 |
|
From: Dennis S. <sy...@yo...> - 2004-10-21 21:25:08
|
Heya, well, I like to keep you guys updated, so here we go: http://www.plasser.nl/synap/libvisual/visui_gtk_demo5.png Code: actor = visual_actor_new ("madspin"); visual_actor_realize (actor); main = visual_plugin_get_userinterface (visual_actor_get_plugin (actor)); vuic = lvwidget_uicontainer_new (main); gtk_container_add (GTK_CONTAINER (window), vuic); We're getting there for sure ! Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-10-21 17:25:10
|
Heya, What do you guys favor: visual_video_set_buffer or visual_video_set_pixels ... ? |
|
From: Dennis S. <sy...@yo...> - 2004-10-21 16:17:41
|
On Thu, 2004-10-21 at 13:01 -0300, Duilio Protti wrote: > > Does anyone has experience with GTK2 and threading, is there a way, a > > function that locks all threads in a way GTK2 is happy, so I can safely > > adjust values from within different threads ? > > > > Cheers, > > Dennis > > Gtk2 doesn't handle threads by itself, it uses Glib for that. I'm not really > shure, but a way to control a chunk of threads is to use a pool of threads, > with GThreadPool. I cannot check this from where I'm right now, but I will > do at home. Well, yeah I know, but the point is, if I'm not wrong, gtk is far from thread safe, so I can't just poke around at the same thing, in different threads, I've got to look into this as well :) Dennis |
|
From: Duilio P. <dp...@fc...> - 2004-10-21 16:01:31
|
> Does anyone has experience with GTK2 and threading, is there a way, a > function that locks all threads in a way GTK2 is happy, so I can safely > adjust values from within different threads ? > > Cheers, > Dennis Gtk2 doesn't handle threads by itself, it uses Glib for that. I'm not really shure, but a way to control a chunk of threads is to use a pool of threads, with GThreadPool. I cannot check this from where I'm right now, but I will do at home. Bye, Duilio. |
|
From: Dennis S. <sy...@yo...> - 2004-10-21 14:36:32
|
On Thu, 2004-10-21 at 11:18 -0300, Duilio Protti wrote: > > Duilio, After the GTK2 widget is done, could you look into a GTK1 > > widget ? (I think it's fairly easy to port the GTK2 version over). > > Yep, there will be no mayor problems on this port. > I can do it when gtk2 widget is stable enough. Alright, good to hear, it's really getting better and better every hour! It now updates VisParams on most userinterface components, after it's completely done, I'll start cleaning it up, and work on a system that is capable of notifying the UI of changes from within the plugin as well, will be doing this in a callback setup fashion. Does anyone has experience with GTK2 and threading, is there a way, a function that locks all threads in a way GTK2 is happy, so I can safely adjust values from within different threads ? Cheers, Dennis |
|
From: Duilio P. <dp...@fc...> - 2004-10-21 14:19:27
|
> Duilio, After the GTK2 widget is done, could you look into a GTK1 > widget ? (I think it's fairly easy to port the GTK2 version over). Yep, there will be no mayor problems on this port. I can do it when gtk2 widget is stable enough. Bye, Duilio. |
|
From: Duilio P. <dp...@fc...> - 2004-10-21 14:15:16
|
> I've got a request, VisParam needs some more 'const' for the params > here and there as well, could you take a look at this ? > > Cheers, > Dennis Shure, I will take a look at it and I'll make a patch. Bye, Duilio. |
|
From: Duilio P. <dp...@fc...> - 2004-10-21 14:13:45
|
> I'd like to rename the 'screenbuffer' entry in VisVideo to 'pixels' > > Anyone objections ? Personally I like more pixels. Bye, Duilio. |
|
From: Dennis S. <sy...@yo...> - 2004-10-21 13:55:30
|
Heya guys, I'd like to rename the 'screenbuffer' entry in VisVideo to 'pixels' Anyone objections ? Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-10-21 06:09:38
|
On Tue, 2004-10-19 at 22:33 +0300, Vitaly V. Bursov wrote: > > IMHO less brain damaging than renaming and wrapping 100s of OpenGL > > functions. > Hm, it is possible to not rename them. just declare these glAsdFg() > functions. One problem here is that if plugin gets linked to > libGL. > > 1. Link statically > > 2. Link dynamically > > 3. dlopen > > > > Which of 1 and 2 are used, is beyond control of the libvisual developers. > > Because it depends on which libs (.a or .so or both) the user has installed > > when compiling. Normally, the linker will perfer .so until -static is used. > > > So the question is whether to link opengl (i.e. -lGL) or dlopen() it. > > I strongly believe, that linking is easier, it's the standard way to use > > libraries and causes little overhead (and the burdon of making this > > work is transferred to the gcc/glibc/kernel developers). > ... various X Servers, various GL drivers, various venders. > And everybody has own opinion. > > > Furthermore, if some new functions appear in a later OpenGL version, > > plugin developers can play with them without waiting, until a new libvisual > > version makes them available through dlsym(). > This can be done automatically during build process. If there's a header > file with declarations it's possible to parse it. What about binear distributions of libvisual ? > And how should be handled plugins that dlopen() libGL? (hm, are there any > around? except scivi, of course :)) > > Dennis, what do you think? We have a Holy War here! :) Well, I must admit I haven't been following it all, can you summarise what the advantage is off dlopen is, and what the problems are with dynamical linking ? I'd personally go for dynamical linking as long that is possible, when problems arise, we shouldn't go out of the way, and do it the hard way if needed, but only if needed. Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-10-20 22:03:18
|
Heya list, Alright, I've been hacking for hours, and I've got a GTK2 widget ready that is getting fairly complete, rendering wise. Need to do some small changes, and implement the 'list' and 'image' widget, and after that the current lvwidget_uicontainer widget is capable of rendering the complete VisUI set. After that I'll start working on propagating those new param settings down the stack into the plugins. When that is up, and working I need to setup a system that is capable of propagating up UI update events from within the plugin, and that is when this goodie is getting near done. After that, we can start implementing config dialogs in plugins, using VisUI, and also set up a standard VisUI config for libvisual itself. We're far from done, a GTK1 widget needs to be produced as well :) Demoshot: http://www.plasser.nl/synap/libvisual/visui_gtk_demo2.png However, it's a start! Duilio, After the GTK2 widget is done, could you look into a GTK1 widget ? (I think it's fairly easy to port the GTK2 version over). When this is all set in stone, I'll contact the amarok develers if they want to make a QT widget. Cheers, Dennis |
|
From: Gustavo S. B. <gu...@gs...> - 2004-10-20 16:10:24
|
On Wednesday 20 October 2004 02:21, Duilio Javier Protti wrote: > Here is the patch for the const pointers on API functions (lv_bin module > was not considered). Thanks Duilio, this will help a lot to avoid errors and wrappers to others languages. -- 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 |
|
From: Dennis S. <sy...@yo...> - 2004-10-20 14:51:23
|
On Wed, 2004-10-20 at 09:07 +0300, Vitaly V. Bursov wrote:
> On Tue, 19 Oct 2004 21:57:06 +0200
> Dennis Smit <sy...@yo...> wrote:
>
> > Well, I don't have a crash related to this... I can load 2 plugins and
> > unload them both, my dlopen gives a fake handle for the second library,
> > and REALLY closes the library when all handles are being dlclosed...
> Hm, it should. Sorry.
> ...weird.
>
The following test program:
#include <libvisual/libvisual.h>
int main (int argc, char **argv)
{
VisPluginRef *ref1;
VisPluginData *plug1;
VisPluginData *plug2;
visual_init (&argc, &argv);
ref1 = visual_plugin_find (visual_plugin_get_registry (),
"oinksie");
printf ("%p\n", ref1);
plug1 = visual_plugin_load (ref1);
plug2 = visual_plugin_load (ref1);
printf ("plug: %p\n", plug1);
visual_plugin_realize (plug1);
visual_plugin_realize (plug2);
visual_plugin_unload (plug1);
visual_plugin_unload (plug2);
return 0;
}
Works perfectly, what dlopen seems to do here, is when a library gets
opened twice, generate one fake handle. and close the library for real
if the last handle is being dlclosed(). Can you show me your code
that does not work, or make it possible for me to test.
If it seems that dlopen is indeed different on different systems, I can
introduce an easy hack into the plugin loader that keeps track on the
real handle. But I really think this is NOT needed...
Cheers,
Dennis
|
|
From: Dennis S. <sy...@yo...> - 2004-10-20 14:37:34
|
Alright, I think this looks good, Test and commit to CVS. Thanks a lot! On Wed, 2004-10-20 at 02:21 -0300, Duilio Javier Protti wrote: > Here is the patch for the const pointers on API functions (lv_bin module > was not considered). > > > Bye, > Duilio. > |
|
From: Vitaly V. B. <vit...@us...> - 2004-10-20 06:09:47
|
On Tue, 19 Oct 2004 21:57:06 +0200 Dennis Smit <sy...@yo...> wrote: > Well, I don't have a crash related to this... I can load 2 plugins and > unload them both, my dlopen gives a fake handle for the second library, > and REALLY closes the library when all handles are being dlclosed... Hm, it should. Sorry. ...weird. -- Vitaly GPG Key ID: F95A23B9 |
|
From: Duilio J. P. <dp...@fc...> - 2004-10-20 05:06:53
|
Here is the patch for the const pointers on API functions (lv_bin module was not considered). Bye, Duilio. |
|
From: Vitaly V. B. <vit...@us...> - 2004-10-19 20:47:29
|
On Fri, 15 Oct 2004 13:27:26 +0200
Burkhard Plaum <pl...@ip...> wrote:
> > This is worst case scenario. If you need to intermix different contexts,
> > you group gl calls anyway, don't you?
>
> I wouldn't intermix the calls, because it's nonsense.
> But as I said, less advanced programmers get strange ideas,
> when nobody watches them :-)
:) so as more advanced.
> > If there is malloc()'ed struct with dlsym()'ed function pointers,
> > call is like this
> >
> > mov <struct address>(,%index_reg,4), %eax
> > call *%eax
> >
> > or something alike.
>
> And this would be the case, if you would wrap dlsym()ed gl* functions into
> lvgl* calls?
Yes.
Here are test results.
optimization is off.
$ gcc -g a.c
=======
int main()
{
void *h = dlopen("libm.so.6", RTLD_LAZY);
a = dlsym(h, "sin");
a(0.3);
}
=======
piece of asm code.
// it's a a(0.3) call;
0x08048432 <main+58>: mov %eax,0x8049668
0x08048437 <main+63>: movl $0x3e99999a,(%esp)
0x0804843e <main+70>: mov 0x8049668,%eax
0x08048443 <main+75>: call *%eax
0x08048445 <main+77>: fstp %st(0)
(gdb) stepi
0x0804843e 10 a(0.3);
(gdb)
0x08048443 10 a(0.3);
(gdb)
0x41156760 in __sin () from /lib/libm.so.6
(gdb) print /x $eax
$3 = 0x41156760
> >>If the usage of multiple OpenGL libs cannot be avoided:
> >>Would it make sense to have them in separate processes? The LD_PRELOAD
> >>environment variable can easily force a certain libGL.so to be used,
> >>and OpenGL can be used as we learned it.
> >
> > That's too drain bamaging, sorry :)
>
> IMHO less brain damaging than renaming and wrapping 100s of OpenGL
> functions.
Hm, it is possible to not rename them. just declare these glAsdFg()
functions. One problem here is that if plugin gets linked to
libGL.
> > So, as I wrote above, there is almost no difference between staticaly
> > shared linkage and dlopen()'ed libraries regarding to speed.
> > Is it OK to load dynamically libGL?
>
> There are now 3 options:
>
> 1. Link statically
> 2. Link dynamically
> 3. dlopen
>
> Which of 1 and 2 are used, is beyond control of the libvisual developers.
> Because it depends on which libs (.a or .so or both) the user has installed
> when compiling. Normally, the linker will perfer .so until -static is used.
> So the question is whether to link opengl (i.e. -lGL) or dlopen() it.
> I strongly believe, that linking is easier, it's the standard way to use
> libraries and causes little overhead (and the burdon of making this
> work is transferred to the gcc/glibc/kernel developers).
... various X Servers, various GL drivers, various venders.
And everybody has own opinion.
> Furthermore, if some new functions appear in a later OpenGL version,
> plugin developers can play with them without waiting, until a new libvisual
> version makes them available through dlsym().
This can be done automatically during build process. If there's a header
file with declarations it's possible to parse it.
And how should be handled plugins that dlopen() libGL? (hm, are there any
around? except scivi, of course :))
Dennis, what do you think? We have a Holy War here! :)
--
Vitaly
GPG Key ID: F95A23B9
|
|
From: Dennis S. <sy...@yo...> - 2004-10-19 19:56:58
|
On Tue, 2004-10-19 at 22:02 +0300, Vitaly V. Bursov wrote:
> > I'm not sure about the bin, I really need to redo it from scratch....
> I mean
>
> int visual_bin_destroy (VisBin *bin)
> {
> visual_log_return_val_if_fail (bin != NULL, -1);
>
> if ((bin->actor != NULL) /*-->*/ && (bin->managed) /*<--*/ )
> visual_actor_destroy (bin->actor);
> ...
Aah that way, well, yeah, maybe it's better to always destroy childs...
I'm not going to fix this right now, but do that when we do the
rewrite.
> > About visual_plugin_unload, would it be better to set an error, and have
> > a way to force it ?
> No, of course not! if you unload library that is used everything will crash.
>
> Well, here's an example that will not work.
>
> plug1 = visual_plugin_load(ref);
> plug2 = visual_plugin_load(ref);
Well, I don't have a crash related to this... I can load 2 plugins and
unload them both, my dlopen gives a fake handle for the second library,
and REALLY closes the library when all handles are being dlclosed...
> visual_plugin_unload(plug1);
> visual_plugin_unload(plug2); // <-- Hard Crash here.
>
> because it dlclose()'s library. :(
>
> I do not see a quick&nice way to fix this but write a
> dlopen() manager with static struct array with
> handles and refcounters.
>
> This thing should be fixed.
>
> > What others bugs do you have? I might be able to help you
> > fixing those.
> OK, just as I find some. :)
Alright, Keep me updated, I might be able to help :)
Cheers,
Dennis
|
|
From: Vitaly V. B. <vit...@us...> - 2004-10-19 19:28:19
|
On Tue, 19 Oct 2004 11:11:23 +0200
Dennis Smit <sy...@yo...> wrote:
> On Tue, 2004-10-19 at 03:00 +0300, Vitaly V. Bursov wrote:
> > On Tue, 19 Oct 2004 00:33:14 +0200
> > Dennis Smit <sy...@yo...> wrote:
> >
> > > How are the other hackers doing ? :))
> > Hunting those weird bugs... and my hangs.
> >
> > Dennis, shouldn't visual_bin_destroy() free only managed plugins, should it?
> >
> > visual_plugin_unload() dlclose()'s library even if it is used...
> >
> > That's all for today :)
>
> I'm not sure about the bin, I really need to redo it from scratch....
I mean
int visual_bin_destroy (VisBin *bin)
{
visual_log_return_val_if_fail (bin != NULL, -1);
if ((bin->actor != NULL) /*-->*/ && (bin->managed) /*<--*/ )
visual_actor_destroy (bin->actor);
...
> About visual_plugin_unload, would it be better to set an error, and have
> a way to force it ?
No, of course not! if you unload library that is used everything will crash.
Well, here's an example that will not work.
plug1 = visual_plugin_load(ref);
plug2 = visual_plugin_load(ref);
// realize, etc.
visual_plugin_unload(plug1);
visual_plugin_unload(plug2); // <-- Hard Crash here.
because it dlclose()'s library. :(
I do not see a quick&nice way to fix this but write a
dlopen() manager with static struct array with
handles and refcounters.
This thing should be fixed.
> What others bugs do you have? I might be able to help you
> fixing those.
OK, just as I find some. :)
--
Vitaly
GPG Key ID: F95A23B9
|
|
From: Dennis S. <sy...@yo...> - 2004-10-19 09:11:12
|
On Tue, 2004-10-19 at 03:00 +0300, Vitaly V. Bursov wrote: > On Tue, 19 Oct 2004 00:33:14 +0200 > Dennis Smit <sy...@yo...> wrote: > > > How are the other hackers doing ? :)) > Hunting those weird bugs... and my hangs. > > Dennis, shouldn't visual_bin_destroy() free only managed plugins, should it? > > visual_plugin_unload() dlclose()'s library even if it is used... > > That's all for today :) I'm not sure about the bin, I really need to redo it from scratch.... About visual_plugin_unload, would it be better to set an error, and have a way to force it ? What others bugs do you have? I might be able to help you fixing those. Cheers, Dennis |
|
From: Vitaly V. B. <vi...@ph...> - 2004-10-19 00:00:37
|
On Tue, 19 Oct 2004 00:33:14 +0200 Dennis Smit <sy...@yo...> wrote: > How are the other hackers doing ? :)) Hunting those weird bugs... and my hangs. Dennis, shouldn't visual_bin_destroy() free only managed plugins, should it? visual_plugin_unload() dlclose()'s library even if it is used... That's all for today :) -- Vitaly GPG Key ID: F95A23B9 |
|
From: Dennis S. <sy...@yo...> - 2004-10-18 22:33:02
|
Alright, What is now in CVS would be anough to create the UI tree, next is a GTK2 widget, that would suite as a test. And after that I will implement UI update notification, and param change events propagation. How are the other hackers doing ? :)) Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-10-17 22:51:19
|
I applied lv_ui.h to cvs, containing the basic structures for the UI description. If anonyone has an urge to look at it, please do it now because I'll soon start implementing the code. Cheers, Dennis |
10 messages has been excluded from this view by a project administrator.
