Menu
▾
▴
libvisual-devel
|
From: Vitaly V. B. <vit...@us...> - 2004-09-23 13:06:57
Attachments:
libvisual-events.diff
libvisual-display.tar.bz2
|
Hello, This patch for Libvisual's event system adds folowing events: Quit, Visibiity and Generic. The first two of them are already used by lvdisplay, so you need this patch to try out lvdisplay ;) Also it changes VisEvent struct to an union. It is binary incompatible with previous version. I haven't checked it carefully it just passes events for lvdisplay and everything looks fine. Please take a look over lvdisplay. You need to fix a path to plugins in example/main.c. Any suggestions, critics, code, etc. are very welcome. -- Vitaly GPG Key ID: F95A23B9 |
|
From: Dennis S. <sy...@yo...> - 2004-09-27 15:49:44
|
Heya Vitaly, Sorry for keeping you waiting for so long! I just hadn't the time to get to it! I submitted the VisEvent changes to CVS, all looks good. You've got CVS write access, so you can put libvisual-display into CVS. Please make the dir layout 'kinda right' the first time, because you know how CVS and dir removal goes :) Thanks a lot and I hope to see more from you regarding libvisual-display! Owyeah, please have a look at my event code changes, if it's right like this. Cheers, Dennis On Thu, 2004-09-23 at 16:06 +0300, Vitaly V. Bursov wrote: > Hello, > > This patch for Libvisual's event system adds folowing events: > Quit, Visibiity and Generic. The first two of them are already > used by lvdisplay, so you need this patch to try out > lvdisplay ;) > > Also it changes VisEvent struct to an union. It is binary > incompatible with previous version. I haven't checked it > carefully it just passes events for lvdisplay and everything > looks fine. > > Please take a look over lvdisplay. You need to fix a path > to plugins in example/main.c. > > Any suggestions, critics, code, etc. are very welcome. > |
|
From: Vitaly V. B. <vit...@us...> - 2004-09-27 20:06:32
|
On Mon, 27 Sep 2004 17:49:50 +0200 Dennis Smit <sy...@yo...> 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! Nice! Also you've changed API version and old lvdisplay binary refused to load its drivers. Cool! Simple recompilation and it runs again. :) > You've got CVS write access, so you can put libvisual-display > into CVS. Please make the dir layout 'kinda right' the > first time, because you know how CVS and dir removal goes :) OK. > Owyeah, please have a look at my event code changes, if it's right like > this. Yes. And thanks for commenting my code! ;) Dennis, I have one question regarding resize event... One of arguments passed to visual_event_queue_add_resize() is called "video". I am not sure if I can pass a correct value here from driver backend... Is it OK to pass NULL? I guess not. Do you think I shoul bind VisVideo object to every BE+FE pair or something? Does it make sense? -- Thanks, Vitaly GPG Key ID: F95A23B9 |
|
From: Dennis S. <sy...@yo...> - 2004-09-27 20:23:01
|
On Mon, 2004-09-27 at 23:06 +0300, Vitaly V. Bursov wrote: > Dennis, I have one question regarding resize event... > One of arguments passed to visual_event_queue_add_resize() is called > "video". I am not sure if I can pass a correct value here from > driver backend... Is it OK to pass NULL? I guess not. > > Do you think I shoul bind VisVideo object to every BE+FE pair or > something? Does it make sense? It's mandatory at the moment, but I think it's technically possible to do without a VisVideo, however it needs some changes in both the core AND >EVERY< plugin. If I've got the time, I'll investigate this tomorrow. However, I think it makes sense that every BE+FE pair needs a VisVideo. VisVideo contains the dimension/pitch/bpp and screenbuffer stuff, which is needed to draw a frame. Ofcourse I'm totally open for suggestions / comments. If you know a reason why not every BE+FE pair needs a VisVideo please go ahead :) Cheers, Dennis |
|
From: Vitaly V. B. <vit...@us...> - 2004-09-27 20:35:38
|
On Mon, 27 Sep 2004 23:06:54 +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! Hmm... I have two identical versions of lvdisplay here built in different directories... One of them hangs, another not. Confused. -- Vitaly GPG Key ID: F95A23B9 |
|
From: Vitaly V. B. <vit...@us...> - 2004-09-27 20:45:30
|
On Mon, 27 Sep 2004 23:06:54 +0300 "Vitaly V. Bursov" <vit...@us...> wrote: > On Mon, 27 Sep 2004 17:49:50 +0200 > Dennis Smit <sy...@yo...> 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? -- Vitaly GPG Key ID: F95A23B9 |
|
From: Dennis S. <sy...@yo...> - 2004-09-27 20:59:12
|
On Mon, 2004-09-27 at 23:45 +0300, Vitaly V. Bursov wrote: > On Mon, 27 Sep 2004 23:06:54 +0300 > "Vitaly V. Bursov" <vit...@us...> wrote: > > > On Mon, 27 Sep 2004 17:49:50 +0200 > > Dennis Smit <sy...@yo...> 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? That is odd, no idea tho what it can be, can you test on different machines ? |
|
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 |
|
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: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 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: 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: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: 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-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: 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 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: 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 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: Duilio J. P. <dp...@fc...> - 2004-09-28 22:54:01
|
> 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 Cool!, I want for this from a time ago, but I don't have worked on because it was for 0.1.8 on the ROADMAP. But I think will be good to get it right now. I was thinking on a simple system like: void visual_log_set_verbose (int yes_or_no); to enable/disable i.e. debug messages (but maybe other internal things too). Also would be good to let the user set this through visual_init() passing -v flag or something like that. I believe having different debug levels (i.e. from 0 to 9) is a bad idea on a dynamic library like libvisual, and is in general very confusing. Bye, Duilio. |
|
From: Dennis S. <sy...@yo...> - 2004-09-28 23:12:35
|
On Tue, 2004-09-28 at 20:05 -0300, Duilio Javier Protti wrote: > Cool!, I want for this from a time ago, but I don't have worked > on because it was for 0.1.8 on the ROADMAP. But I think will be > good to get it right now. Well, Don't take the roadmap too litteraly, it's a direction, not a final road, remember, where we go, we make the roads ;) > I was thinking on a simple system like: > > void visual_log_set_verbose (int yes_or_no); > > to enable/disable i.e. debug messages (but maybe other internal > things too). Also would be good to let the user set this through > visual_init() passing -v flag or something like that. Well, I wouldn't do that, and especially not something as common as '-v' An application that just passes on his argv/argc could errornously change the verboseness level. I personally don't think that just 'visual_log, on and off' is anough. I was thinking about something like this: VISUAL_LOG_VERBOSENESS_HIGH (for everything) VISUAL_LOG_VERBOSENESS_MEDIUM (for warnings/criticals/errors) VISUAL_LOG_VERBOSENESS_LOW (for critical/errors) and: VISUAL_LOG_VERBOSENESS_NONE (for disabling ALL the messages) There is kinda one special case, that is VISUAL_LOG_INFO.. Not sure how we should handle this one in this case... > I believe having different debug levels (i.e. from 0 to 9) is > a bad idea on a dynamic library like libvisual, and is in general > very confusing. I agree that over doing it is confusing, but there is a clear distinction between VISUAL_LOG_DEBUG and VISUAL_LOG_ERROR, I don't think you can treat them equaly as they are whole different message classes. Please give me your comments... Greets, Dennis |
|
From: Duilio J. P. <dp...@fc...> - 2004-09-29 06:01:42
|
> I was thinking about something like this: > VISUAL_LOG_VERBOSENESS_HIGH (for everything) > VISUAL_LOG_VERBOSENESS_MEDIUM (for warnings/criticals/errors) > VISUAL_LOG_VERBOSENESS_LOW (for critical/errors) > and: > VISUAL_LOG_VERBOSENESS_NONE (for disabling ALL the messages) I think is perfect > There is kinda one special case, that is VISUAL_LOG_INFO.. Not sure > how we should handle this one in this case... Well, we must let the user some way to show a message >always< so a good place to put that is on VISUAL_LOG_INFO messages I guess. Bye, Duilio. |
|
From: Dennis S. <sy...@yo...> - 2004-09-29 08:28:29
|
On Wed, 2004-09-29 at 03:13 -0300, Duilio Javier Protti wrote: > > I was thinking about something like this: > > VISUAL_LOG_VERBOSENESS_HIGH (for everything) > > VISUAL_LOG_VERBOSENESS_MEDIUM (for warnings/criticals/errors) > > VISUAL_LOG_VERBOSENESS_LOW (for critical/errors) > > and: > > VISUAL_LOG_VERBOSENESS_NONE (for disabling ALL the messages) > > I think is perfect Ok, care to implement it ? :) > > There is kinda one special case, that is VISUAL_LOG_INFO.. Not sure > > how we should handle this one in this case... > > Well, we must let the user some way to show a message >always< so > a good place to put that is on VISUAL_LOG_INFO messages I guess. Agree on that! 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 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. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X