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: Dennis S. <sy...@yo...> - 2004-09-28 19:43:14
|
On Tue, 2004-09-28 at 20:24 +0100, Andrew Godwin wrote: > It's not functional; it's simply a template which will get moulded around a > CMS or have one built into it. The links are just ideas, too. > > I'd like to know if you like it, hate it, or have unprintable views about it. > Should I go ahead and try integrating it? Should I change the look? > > Anyway, I suppose you will want to see it after all this, so head over to: > > http://bytehoard.ath.cx/libvisualtest I'm simply VERY VERY VERY happy with this design, it's exactly what I want. If you could throw an CMS around this, that would be just super. Thanks a lot! Dennis |
|
From: Andrew G. <and...@bl...> - 2004-09-28 19:24:27
|
Hello everybody. Over the last day or so I've had a go at putting together an alternative look for the libvisual website. I know Gustavo has a design, and have had a look at it; the same dark theme, some similar color changes, and of course the same logo all feature in the design. I tried getting some screencaps to see if I could make a new logo at first, but the current one surpasses anything I got out of gforce. The entire thing is valid XHTML 1.0 Strict, and is entirely CSS based for the look. There are some alternative stylesheets, too, if you feel so inclined. I've tested it rendering in Gecko and KHTML. I'm not sure if IE will accept it (I'll have to see if it still works under wine at some point), and it does use alpha-blended pngs, but they can be changes. It's not functional; it's simply a template which will get moulded around a CMS or have one built into it. The links are just ideas, too. I'd like to know if you like it, hate it, or have unprintable views about it. Should I go ahead and try integrating it? Should I change the look? Anyway, I suppose you will want to see it after all this, so head over to: http://bytehoard.ath.cx/libvisualtest Andrew Godwin |
|
From: Dennis S. <sy...@yo...> - 2004-09-28 19:20:10
|
On Tue, 2004-09-28 at 14:55 -0300, Duilio Javier Protti wrote: > I have installed libvisual outside the standard places > (/home/duilio/share) and I see that then I cannot compile > against it. This is because `pkg-config libvisual --cflags` > returns > > -I/home/duilio/share/include/libvisual > > but all plugins makes > > #include <libvisual/libvisual.h> > > so the correct flags returned by pkg-config should be > > -I/home/duilio/share/include > > Fixing this on the libvisual.pc.in I have rebuilded all the > plugins without problems. Dennis, I must commit this to the > repository? Yep please commit. |
|
From: Vitaly V. B. <vit...@us...> - 2004-09-28 19:19:18
|
On Tue, 28 Sep 2004 19:34:19 +0200 Dennis Smit <sy...@yo...> wrote: > I'd (finally) like to implement the plugin flag stuff. > > On the list I now have: > > VISUAL_PLUGIN_FLAG_NOT_REENTRANT (some plugins, like alsa could > use the singleton design pattern > to solve this, not sure about > this tho) > > VISUAL_PLUGIN_FLAG_SPECIAL (flag for plugins like > gdkpixbuf, plugins that > have a special function > which shouldn't be used > in for example, amarok > or the xmms plugin) Looks good :) > More suggestions ? May be implement something like VISUAL_PLUGIN_FLAG_SPECIAL but in an opposite way. I.e. plugin must be used only with this application. This application simply provide some kind of special data/interfaces that can not be used with Libvisual. One nice way to implement this is to use const char* identifier to specify, say, application id. Numeric id's -- enums and #defines not very useful here, I think. We could place this id to VisPluginInfo. If so, we should add some void *dummys[5]; so we can extend functionality further without breaking plugin ABI. -- Vitaly GPG Key ID: F95A23B9 |
|
From: Duilio J. P. <dp...@fc...> - 2004-09-28 17:43:24
|
I have installed libvisual outside the standard places (/home/duilio/share) and I see that then I cannot compile against it. This is because `pkg-config libvisual --cflags` returns -I/home/duilio/share/include/libvisual but all plugins makes #include <libvisual/libvisual.h> so the correct flags returned by pkg-config should be -I/home/duilio/share/include Fixing this on the libvisual.pc.in I have rebuilded all the plugins without problems. Dennis, I must commit this to the repository? Bye, Duilio. |
|
From: Dennis S. <sy...@yo...> - 2004-09-28 17:36:03
|
On Tue, 2004-09-28 at 13:47 -0300, Duilio Javier Protti wrote: > > JESS is still not building btw ;) > > > > Please take a look at this as well. > > Ok, I have fixed right now. Thanks for fixing it, I've got a question, Since you did most of the visual_log system, what do you think about having a method that sets the verboseness of the log system, so you can make it shutup all together, both through an API call and a environment variable... It would be very nice if you could have a look at this. Thanks, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-09-28 17:34:28
|
Heya, I'd (finally) like to implement the plugin flag stuff. On the list I now have: VISUAL_PLUGIN_FLAG_NOT_REENTRANT (some plugins, like alsa could use the singleton design pattern to solve this, not sure about this tho) VISUAL_PLUGIN_FLAG_SPECIAL (flag for plugins like gdkpixbuf, plugins that have a special function which shouldn't be used in for example, amarok or the xmms plugin) More suggestions ? Cheers, Dennis |
|
From: Duilio J. P. <dp...@fc...> - 2004-09-28 16:35:58
|
> JESS is still not building btw ;) > > Please take a look at this as well. Ok, I have fixed right now. > One other thing, maybe it's an idea to be able to set the number > of seconds a morph takes in the libvisual-xmms plugin, through > the configure window. I'm agree with that! Bye, Duilio. |
|
From: Dennis S. <sy...@yo...> - 2004-09-28 16:24:56
|
Heya, Vitaly, regarding the resize event. I recalled why I'm passing it as well. Plugins may want to know things like the screen it's pitch value and such which is encapsulated in the VisVideo. If you've got any suggestions, please comment Cheers, Dennis Smit |
|
From: Dennis S. <sy...@yo...> - 2004-09-28 15:23:46
|
> libvisual-plugins was broken until now, because of my error :-( > I have fixed, and I have removed all that unncessary AC_DEFINE's. JESS is still not building btw ;) Please take a look at this as well. One other thing, maybe it's an idea to be able to set the number of seconds a morph takes in the libvisual-xmms plugin, through the configure window. Thanks, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-09-28 15:15:26
|
> Leak memory !? I hope you will fix this too. I can't have external > plugins to LiVES which leak memory. > > Salsaman. No panic Salsaman, this is just CVS, and it's been fixed completely by now. Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-09-28 15:11:58
|
> int visual_event_queue_free (VisEventQueue *eventqueue)
> {
> visual_log_return_val_if_fail (eventqueue != NULL, -1);
>
> visual_list_destroy (&eventqueue->events, free);
>
> visual_mem_free (eventqueue);
>
> return 0;
> }
I made an visual_list_destroy_elements, and reverted param to use
this as well.
Aka everything from CVS needs to be >recompiled<
Cheers,
Dennis
|
|
From: salsaman <sal...@xs...> - 2004-09-28 12:20:15
|
Vitaly V. Bursov wrote: >On Tue, 28 Sep 2004 10:51:06 +0100 >salsaman <sal...@xs...> wrote: > > > >>>Or, better IMO, visual_list_free() from visual_list_destroy() in lv_list.c. >>>This WILL LEAK Memory, but won'r thrash malloc state... there is one more >>>here, Dennis. >>> >>> >>> >>Leak memory !? I hope you will fix this too. I can't have external >> >> >Of course we'll fix this! You asked some patch... Here's my suggestion. >Just for a few days. I'm quiet busy right now... sorry! > >At least it will fix all known (for this moment) memory issues. >Oh, and will add another one :) which is kinda better because it will >not break memory manager consistency. > > > >>plugins to LiVES which leak memory. >> >> >Anyway, it will not leak memory during "normal operation", only when >plugins switched or Libvisual deinitialized, etc. > OK, well deinit/reinit could happen several thousand times during a long (I am talking about days or weeks) run of LiVES. Don't forget this is not just a VJ app, people use this application to edit professional video. If LiVES crashes, people could lose hours or days of work. Even more so when I add the multitrack editor and people can make generators into tracks. Anyway, I am confident that you will have all these memory issues fixed soon. Salsaman. > I don't think that >somebody will create/free lists in a loop. > >And don't worry, that is not that much memory to kill application >in a short time, I think. ;) > > > |
|
From: Vitaly V. B. <vit...@us...> - 2004-09-28 11:47:09
|
On Tue, 28 Sep 2004 10:51:06 +0100 salsaman <sal...@xs...> wrote: > >Or, better IMO, visual_list_free() from visual_list_destroy() in lv_list.c. > >This WILL LEAK Memory, but won'r thrash malloc state... there is one more > >here, Dennis. > > > Leak memory !? I hope you will fix this too. I can't have external Of course we'll fix this! You asked some patch... Here's my suggestion. Just for a few days. I'm quiet busy right now... sorry! At least it will fix all known (for this moment) memory issues. Oh, and will add another one :) which is kinda better because it will not break memory manager consistency. > plugins to LiVES which leak memory. Anyway, it will not leak memory during "normal operation", only when plugins switched or Libvisual deinitialized, etc. I don't think that somebody will create/free lists in a loop. And don't worry, that is not that much memory to kill application in a short time, I think. ;) -- Vitaly GPG Key ID: F95A23B9 |
|
From: salsaman <sal...@xs...> - 2004-09-28 08:35:13
|
Vitaly V. Bursov wrote: >On Tue, 28 Sep 2004 00:52:47 +0200 >Dennis Smit <sy...@yo...> wrote: > > > >>On Tue, 2004-09-28 at 00:43 +0100, salsaman wrote: >> >> >>>Any chance of a diff just for this issue so I can patch LiVES before >>>tomorrow's performance ? >>> >>> > > > >>Remove the visual_list_destroy from visual_param_container_destroy in >>libvisual/lv_param.c >> >> > >Or, better IMO, visual_list_free() from visual_list_destroy() in lv_list.c. >This WILL LEAK Memory, but won'r thrash malloc state... there is one more >here, Dennis. > > > Leak memory !? I hope you will fix this too. I can't have external plugins to LiVES which leak memory. Salsaman. |
|
From: Duilio J. P. <dp...@fc...> - 2004-09-28 06:16:27
|
> PS. Dennis, are you sure your new plugin selection algo in lv-plugins > works the right way? It just visits all dirs and builts nothing. > > First, configure.ac: > AC_DEFINE([ALSALA], [input_alsa.la], [alsa input plugin dynamic library name > ALSALA=input_alsa.la # Missed (?) > AC_SUBST(ALSALA) > Is AC_DEFINE necessary? it created definition in config.h.in... > > After fixing this, only static "plugin" built. with ".a" extension... libvisual-plugins was broken until now, because of my error :-( I have fixed, and I have removed all that unncessary AC_DEFINE's. Thanks a lot, Duilio. |
|
From: Dennis S. <sy...@yo...> - 2004-09-28 05:50:33
|
On Tue, 2004-09-28 at 08:34 +0300, Vitaly V. Bursov wrote:
> int visual_event_queue_free (VisEventQueue *eventqueue)
> {
> visual_log_return_val_if_fail (eventqueue != NULL, -1);
>
> visual_list_destroy (&eventqueue->events, free);
>
> visual_mem_free (eventqueue);
>
> return 0;
> }
Ai this is painful, I was confused and thought list_destroy only called
the destroyer for the elements in the list...
> PS. Dennis, are you sure your new plugin selection algo in lv-plugins
> works the right way? It just visits all dirs and builts nothing.
>
> First, configure.ac:
> AC_DEFINE([ALSALA], [input_alsa.la], [alsa input plugin dynamic library name
> ALSALA=input_alsa.la # Missed (?)
> AC_SUBST(ALSALA)
> Is AC_DEFINE necessary? it created definition in config.h.in...
>
> After fixing this, only static "plugin" built. with ".a" extension...
Actually I'm sure it did not work, I had the same problem, but I think
Duilio has fixed it in CVS this night.
Cheers,
Dennis
|
|
From: Vitaly V. B. <vit...@us...> - 2004-09-28 05:34:35
|
On Tue, 28 Sep 2004 00:52:47 +0200
Dennis Smit <sy...@yo...> wrote:
> On Tue, 2004-09-28 at 00:43 +0100, salsaman wrote:
> > Any chance of a diff just for this issue so I can patch LiVES before
> > tomorrow's performance ?
> Remove the visual_list_destroy from visual_param_container_destroy in
> libvisual/lv_param.c
Or, better IMO, visual_list_free() from visual_list_destroy() in lv_list.c.
This WILL LEAK Memory, but won'r thrash malloc state... there is one more
here, Dennis.
in lv_event.c:
int visual_event_queue_free (VisEventQueue *eventqueue)
{
visual_log_return_val_if_fail (eventqueue != NULL, -1);
visual_list_destroy (&eventqueue->events, free);
visual_mem_free (eventqueue);
return 0;
}
int visual_list_destroy (VisList *list, visual_list_destroy_func_t destroyer)
{
...
visual_list_free (list);
}
> Btw I had a hang on gforce once in the Arena preset, so it's not
> something on your machine, so it seems. I'm going to try to debug
> this but it's pretty hard because I don't have a pattern to
> recreate the hang, it happens almost never here.
PS. Dennis, are you sure your new plugin selection algo in lv-plugins
works the right way? It just visits all dirs and builts nothing.
First, configure.ac:
AC_DEFINE([ALSALA], [input_alsa.la], [alsa input plugin dynamic library name
ALSALA=input_alsa.la # Missed (?)
AC_SUBST(ALSALA)
Is AC_DEFINE necessary? it created definition in config.h.in...
After fixing this, only static "plugin" built. with ".a" extension...
[vitalyb@vb vitalyb]$ automake --version
automake (GNU automake) 1.7.9
[vitalyb@vb vitalyb]$ autoconf --version
autoconf (GNU Autoconf) 2.59
--
Vitaly
GPG Key ID: F95A23B9
|
|
From: Dennis S. <sy...@yo...> - 2004-09-27 22:52:50
|
On Tue, 2004-09-28 at 00:43 +0100, salsaman wrote: > Any chance of a diff just for this issue so I can patch LiVES before > tomorrow's performance ? > > Cheers, > Salsaman. Remove the visual_list_destroy from visual_param_container_destroy in libvisual/lv_param.c Btw I had a hang on gforce once in the Arena preset, so it's not something on your machine, so it seems. I'm going to try to debug this but it's pretty hard because I don't have a pattern to recreate the hang, it happens almost never here. Good luck tomorrow, I won't be there btw, I really have no time. Better luck next time.. Cheers, Dennis |
|
From: salsaman <sal...@xs...> - 2004-09-27 22:27:34
|
Dennis Smit wrote:
>On Tue, 2004-09-28 at 00:59 +0300, Vitaly V. Bursov wrote:
>
>
>>The problem is that you're trying to free() member of a struct.
>>##I.e. There is
>>
>>struct _VisParamContainer {
>> VisList entries;
>> VisEventQueue *eventqueue;
>>};
>>
>>##And
>> visual_list_destroy (¶mcontainer->entries, param_list_destroy);
>>##And
>>
>>int visual_list_destroy (VisList *list, visual_list_destroy_func_t destroyer)
>>{
>> ....
>> visual_list_free (list);
>>
>> return 0;
>>}
>>
>>
>>That is it.
>>
>>I think stuff like
>> VisList entries;
>>should be changed to
>> VisList *entries;
>>
>>
>>
>
>Wow, thank you for tracking it down, believe it or not but I was
>looking at that while doing the xmms plugin as well, but didn't
>fixed it yet. I'm comitting a fix to CVS in a minute.
>
>Thanks,
>Dennis
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>who ports your project to Linux PPC the best. Sponsored by IBM.
>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>_______________________________________________
>Libvisual-devel mailing list
>Lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libvisual-devel
>
>
>
>
Any chance of a diff just for this issue so I can patch LiVES before
tomorrow's performance ?
Cheers,
Salsaman.
|
|
From: Dennis S. <sy...@yo...> - 2004-09-27 22:18:42
|
Vitaly I just tried out lvdisplay, and seriously DAMN COOL!!! We need to figure out a bit how we're going to design the rest of the API and especially the naming, but seeing it work and seeing the code really makes me happy... Now I won't be able to sleep! Cheers, Dennis :) |
|
From: Dennis S. <sy...@yo...> - 2004-09-27 22:07:48
|
On Tue, 2004-09-28 at 00:59 +0300, Vitaly V. Bursov wrote:
> The problem is that you're trying to free() member of a struct.
> ##I.e. There is
>
> struct _VisParamContainer {
> VisList entries;
> VisEventQueue *eventqueue;
> };
>
> ##And
> visual_list_destroy (¶mcontainer->entries, param_list_destroy);
> ##And
>
> int visual_list_destroy (VisList *list, visual_list_destroy_func_t destroyer)
> {
> ....
> visual_list_free (list);
>
> return 0;
> }
>
>
> That is it.
>
> I think stuff like
> VisList entries;
> should be changed to
> VisList *entries;
>
Wow, thank you for tracking it down, believe it or not but I was
looking at that while doing the xmms plugin as well, but didn't
fixed it yet. I'm comitting a fix to CVS in a minute.
Thanks,
Dennis
|
|
From: Vitaly V. B. <vit...@us...> - 2004-09-27 21:59:30
|
On Mon, 27 Sep 2004 23:18:20 +0200
Dennis Smit <sy...@yo...> wrote:
> On Tue, 2004-09-28 at 00:03 +0300, Vitaly V. Bursov wrote:
> > On Mon, 27 Sep 2004 23:45:39 +0300
> > "Vitaly V. Bursov" <vit...@us...> wrote:
> >
> > > > > I submitted the VisEvent changes to CVS, all looks good.
> > > > Indeed, moreover, it works good :) A bug was fixed this time
> > > > in Libvisual and visual_quit() on lvdisplay quit works fine now!
> > > ... heh, relative path "hangs", absolute - not. weird, ld bug?
> > ... nvidia bug!? ok, i'm gonna download 6111 driver :) and
> > we'll see...
> >
> Alright, I'm glad tho that libvisual-display is finally getting off the
> ground. To really rock we really need more display control than SDL
> gives us, and we really need to support more targets out of the box.
Not so fast, Dennis! ;) 6111 works the same way!
OK, There are some good news also! :) I've tracked it down! He-he ;)
This could also fix Salsaman's problem.
The problem is that you're trying to free() member of a struct.
##I.e. There is
struct _VisParamContainer {
VisList entries;
VisEventQueue *eventqueue;
};
##And
visual_list_destroy (¶mcontainer->entries, param_list_destroy);
##And
int visual_list_destroy (VisList *list, visual_list_destroy_func_t destroyer)
{
....
visual_list_free (list);
return 0;
}
That is it.
I think stuff like
VisList entries;
should be changed to
VisList *entries;
this will break abi & plugins. Not a problem we're going to
a next version anyway!
And please make sure there no such references to scructs anywhere.
It's a potential risk, IMO.
> Also having our GL sink in our own control will greatly help us
> making better openGL support. When the stuff is in CVS, and working
> I'll surely hack on it as well!.... That is if time permits ;)
Since this bug is not in lvdisplay, I'll import it in few minutes ;)
--
Vitaly
GPG Key ID: F95A23B9
|
|
From: Dennis S. <sy...@yo...> - 2004-09-27 21:18:30
|
On Tue, 2004-09-28 at 00:03 +0300, Vitaly V. Bursov wrote: > On Mon, 27 Sep 2004 23:45:39 +0300 > "Vitaly V. Bursov" <vit...@us...> wrote: > > > > > I submitted the VisEvent changes to CVS, all looks good. > > > Indeed, moreover, it works good :) A bug was fixed this time > > > in Libvisual and visual_quit() on lvdisplay quit works fine now! > > ... heh, relative path "hangs", absolute - not. weird, ld bug? > ... nvidia bug!? ok, i'm gonna download 6111 driver :) and > we'll see... > Alright, I'm glad tho that libvisual-display is finally getting off the ground. To really rock we really need more display control than SDL gives us, and we really need to support more targets out of the box. Also having our GL sink in our own control will greatly help us making better openGL support. When the stuff is in CVS, and working I'll surely hack on it as well!.... That is if time permits ;) Duilio is fixing the xmms plugin it's usability, I'll be doing some libvisual core/plugin stuff and hopefully we can do another release in a week or two. It won't have all the todo points we had in mind but it has bug fixes and newness! :) I think it's best to keep releasing quite regulary (atleast once a month). Thanks, Dennis |
|
From: Vitaly V. B. <vit...@us...> - 2004-09-27 21:02:59
|
On Mon, 27 Sep 2004 23:45:39 +0300 "Vitaly V. Bursov" <vit...@us...> wrote: > > > I submitted the VisEvent changes to CVS, all looks good. > > Indeed, moreover, it works good :) A bug was fixed this time > > in Libvisual and visual_quit() on lvdisplay quit works fine now! > ... heh, relative path "hangs", absolute - not. weird, ld bug? ... nvidia bug!? ok, i'm gonna download 6111 driver :) and we'll see... -- Vitaly GPG Key ID: F95A23B9 |
10 messages has been excluded from this view by a project administrator.
