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: Mark K. <ma...@we...> - 2004-07-09 08:06:57
|
Hi, the other day Gustavo Sverzut Barbieri pointed us amaroK developers to the libvisual project, as it might be interesting for our project. amaroK is KDE's new audio player. You can learn about the project on http://amarok.kde.org Currently amaroK supports XMMS visualization plugins by means of a small wrapper program (a hack really, but works reasonably well). For the future we planned to provide our own visualization framework. Now libvisual comes into game, and this looks like a very promising path we could go. So we're looking forward to trying your lib. How far is libvisual progressed? Is it worth starting to support it already now? --Mark |
|
From: Dennis S. <sy...@yo...> - 2004-07-08 15:05:02
|
On Thu, 2004-07-08 at 00:02 -0300, Duilio Javier Protti wrote:
> > I've done the following commit:
> >
> > 2004-07-07 Dennis Smit <ds...@ne...>
> >
> > * libvisual/lv_actor.c:
> > (visual_actor_get_next_by_name_gl,
> > visual_actor_get_prev_by_name_gl,
> > visual_actor_get_next_by_name_nogl,
> > visual_actor_get_prev_by_name_nogl):
> > New methods.
> >
> >
> >
> > These methods can be used to filter out certain types of plugins.
> >
> > Duilio I suggest the following:
> >
> > Instead of a checkbox to 'disable gl plugins'
> > have three radio buttons grouped that do either:
> >
> > 'Only GL plugins'
> > 'Only non GL plugins'
> > 'All types of plugins'
> >
> > Or something likewise.
> >
> > I've updated the xmms plugin to use the API and remove the non GL hack.
> >
> > What do you think ?
> >
> > Cheers,
> > Dennis
>
> Good, is much clear this way.
>
> I have submitted the version with the three radiobuttons (along
> with the Glade file), but now I need a
> visual_actor_get_next_by_name_gl() function :-)
Good work, btw I had already checked in the _name_gl methods!!!
* libvisual/lv_actor.c:
(visual_actor_get_next_by_name_gl,
visual_actor_get_prev_by_name_gl,
I want this application API very abstract and this is being the reason
why I rather have many methods than exposing the app writer to
internals.
> This way we
> can use get_next/get_prev functions for others things that just have
> the name of an actor, an we don't need to add functions for every
> new criteria for which we want to filter the list, but instead we
> just walk through the list and take what we want.
The user can always request a VisList full of VisPluginRefs by doing:
visual_actor_get_list. From there on he can check the
LVPlugin->plugin.actorplugin->.... stuff. Tho this is not cached and
needs to be retrieved by the init function from the plugin (which is
basicly loading the plugin) but not realizing it. I will move the
_lv_plugin functions to visual_plugin functions to get the API public.
Cheers,
Dennis
|
|
From: Dennis S. <sy...@yo...> - 2004-07-08 14:58:53
|
This sounds scary, Can you send me the source of the app ? Thanks, Dennis On Thu, 2004-07-08 at 01:00 +0300, Vitaly V. Bursov wrote: > I was trying to get app workin nicely with Libvisual. I mean > "nicely" >> "just to compile" and spent a lot of time trying to > understand where is the problem.... > > Some plugins (esd, alsa) are built linked with libpthread or > are using libraries which are linked. My problem was that main > app was *not* linked with pthread and when e.g alsa plugin was loaded, > libpthread was loaded by linker also and app crashed shortly after > visual_init(). Just segfault deep inside NVidia's GL library... > > Weird... > |
|
From: Duilio J. P. <dp...@fc...> - 2004-07-08 03:00:59
|
> I've done the following commit: > > 2004-07-07 Dennis Smit <ds...@ne...> > > * libvisual/lv_actor.c: > (visual_actor_get_next_by_name_gl, > visual_actor_get_prev_by_name_gl, > visual_actor_get_next_by_name_nogl, > visual_actor_get_prev_by_name_nogl): > New methods. > > > > These methods can be used to filter out certain types of plugins. > > Duilio I suggest the following: > > Instead of a checkbox to 'disable gl plugins' > have three radio buttons grouped that do either: > > 'Only GL plugins' > 'Only non GL plugins' > 'All types of plugins' > > Or something likewise. > > I've updated the xmms plugin to use the API and remove the non GL hack. > > What do you think ? > > Cheers, > Dennis Good, is much clear this way. I have submitted the version with the three radiobuttons (along with the Glade file), but now I need a visual_actor_get_next_by_name_gl() function :-) I think about the visual_actor_get_next_by_name(), that it must return a pointer to a VisActor struct, and from this we can obtain info related to the actor (i.e. if it is a GL one). This way we can use get_next/get_prev functions for others things that just have the name of an actor, an we don't need to add functions for every new criteria for which we want to filter the list, but instead we just walk through the list and take what we want. Bye, Duilio. |
|
From: Vitaly V. B. <vit...@us...> - 2004-07-07 21:59:50
|
I was trying to get app workin nicely with Libvisual. I mean "nicely" >> "just to compile" and spent a lot of time trying to understand where is the problem.... Some plugins (esd, alsa) are built linked with libpthread or are using libraries which are linked. My problem was that main app was *not* linked with pthread and when e.g alsa plugin was loaded, libpthread was loaded by linker also and app crashed shortly after visual_init(). Just segfault deep inside NVidia's GL library... Weird... -- Vitaly GPG Key ID: F95A23B9 |
|
From: Vitaly V. B. <vit...@us...> - 2004-07-07 20:52:58
|
Sorry... broken ISP's relay. Will use another one. -- Vitaly GPG Key ID: F95A23B9 |
|
From: Dennis S. <sy...@yo...> - 2004-07-07 20:50:50
|
Haven't you send this one to the list earlier today ? btw please commit this patch :) thanks a lot. On Wed, 2004-07-07 at 23:22 +0300, Vitaly V. Bursov wrote: > a patch. > |
|
From: Vitaly V. B. <vit...@us...> - 2004-07-07 20:46:08
|
a patch. -- Vitaly GPG Key ID: F95A23B9 |
|
From: Dennis S. <sy...@yo...> - 2004-07-07 20:41:28
|
Please commit, thanks for taking the time to hunt this down! On Wed, 2004-07-07 at 20:46 +0300, Vitaly V. Bursov wrote: > ..... I HATE segfaults! :) > |
|
From: Dennis S. <sy...@yo...> - 2004-07-07 20:37:47
|
I've done the following commit:
2004-07-07 Dennis Smit <ds...@ne...>
* libvisual/lv_actor.c:
(visual_actor_get_next_by_name_gl,
visual_actor_get_prev_by_name_gl,
visual_actor_get_next_by_name_nogl,
visual_actor_get_prev_by_name_nogl):
New methods.
These methods can be used to filter out certain types of plugins.
Duilio I suggest the following:
Instead of a checkbox to 'disable gl plugins'
have three radio buttons grouped that do either:
'Only GL plugins'
'Only non GL plugins'
'All types of plugins'
Or something likewise.
I've updated the xmms plugin to use the API and remove the non GL hack.
What do you think ?
Cheers,
Dennis
|
|
From: Vitaly V. B. <vit...@uk...> - 2004-07-07 20:23:03
|
..... I HATE segfaults! :) -- Vitaly GPG Key ID: F95A23B9 |
|
From: Dennis S. <sy...@yo...> - 2004-07-07 18:50:10
|
No that I know off. Btw, I write Libvisual as Libvisual, just pointing out :) Cheers and thanks for the lv_mem stuff :) On Wed, 2004-07-07 at 12:44 -0300, Duilio Javier Protti wrote: > Dennis, LibVisual has been reported to work (or at > least compile), on MacOSX? > > > Duilio. |
|
From: Duilio J. P. <dp...@fc...> - 2004-07-07 15:42:47
|
Dennis, LibVisual has been reported to work (or at least compile), on MacOSX? Duilio. |
|
From: Duilio J. P. <dp...@fc...> - 2004-07-07 15:42:31
|
I have done some portability related job on this module. Now, size_t type is deduced by configure script and is defined as visual_size_t on lvconfig.h file, and also the macro VISUAL_SIZE_T_FORMAT is defined to the correct string to use on the format string of visual_log for a visual_size_t type. This way we don't need to include sys/types.h and stdlib.h to get the correct type. Before to run make on the new sources, delete the file lvconfig.h, this way a new one with the correct definitions will be created. Bye, Duilio. |
|
From: Duilio J. P. <dp...@fc...> - 2004-07-06 19:37:22
|
The visual_mem module is working. Take a look an send opinions. I will keep working on small portability issues of this module. Bye, Duilio. |
|
From: Dennis S. <sy...@yo...> - 2004-07-06 16:54:56
|
On Tue, 2004-07-06 at 13:41 -0300, Duilio Javier Protti wrote: > > How do we proceed here to fix this the right way ?, shall I add the API > > so you can fix the code ? > > Yes, please! I have not done this because I don't want to change > the API without previously asked on the list. Ok I might do this tonight, I first want to take a good post-work nap :) |
|
From: Duilio J. P. <dp...@fc...> - 2004-07-06 16:40:27
|
> How do we proceed here to fix this the right way ?, shall I add the API > so you can fix the code ? Yes, please! I have not done this because I don't want to change the API without previously asked on the list. Regards, Duilio. |
|
From: Dennis S. <sy...@yo...> - 2004-07-06 15:10:39
|
Heya Duilio,
This really is not the way to do this. I think it's better to have a
extra get_next_by_name method in VisActor that skips openGL plugins.
___
if
(options->disable_opengl_plugins) {
while ( (strcmp
(next_plugin, "infinite") != 0) &&
(strcmp
(next_plugin, "jess") != 0) &&
(strcmp
(next_plugin, "oinksie") != 0) &&
(strcmp
(next_plugin, "lv_scope") != 0) ) {
___
Basicly the old code was working, we just need an extra skip openGL
method next_by_name, that was already on the TODO list.
How do we proceed here to fix this the right way ?, shall I add the API
so you can fix the code ?
Cheers,
Dennis
On Mon, 2004-07-05 at 23:41 -0300, Duilio Javier Protti wrote:
> Now OpenGl plugins can be disabled through configure
> window or config file.
>
> Enjoy it!
>
> Bye,
> Duilio.
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Libvisual-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libvisual-devel
|
|
From: Duilio J. P. <dp...@fc...> - 2004-07-06 02:39:39
|
Now OpenGl plugins can be disabled through configure window or config file. Enjoy it! Bye, Duilio. |
|
From: Vitaly V. B. <vit...@uk...> - 2004-07-06 00:18:55
|
On Mon, 05 Jul 2004 23:36:33 +0200 Dennis Smit <sy...@yo...> wrote: > On Tue, 2004-07-06 at 00:02 +0300, Vitaly V. Bursov wrote: > > On Mon, 05 Jul 2004 21:54:47 +0200 > > Dennis Smit <sy...@yo...> wrote: > > > > > > > > Vitaly, > > > > > > If you have some time could you look into the following: > > > at: http://libvisual.sourceforge.net/LIBVISUAL_TODO > > > > > > * Fixes in some GL plugins that show odd behavior after another GL > > > plugin has been running (better state setting). (everyone!!!) > > Yes, I've already seen this, tried to reproduce this and failed. > > And I thought it was fixed... > > > > > This is tiresome to debug but some GL plugins show up really odd > > > after another had run before (in the same execution) using > > > plugin switches. This is probably easier to monitor when you > > > adapt the xmms plugin to only show GL plugins and show them > > > randomly... > > Now I see. :) Indeed, this is due to settings left by prev. plugin. > > > > Even worse, If a plugin allocates, say, a (large ;) texture and does > > not release it during cleanup, texture will still reside in video > > memory. Just like with madspin plugin: there is glGenTextures() > > call and no glDeleteTextures(). The same will be with other data > > like lists. > > Would you mind to clean this kind of things up anyway if I gave > you CVS access to libvisual CVS ? Sure. SF's anon cvs isn't working again.... My SF login: vitalyvb > > Looks like the only way to reset it nicely (everything is set to > > defaults in any condition on any hw/sw) is to delete GL context > > and create a new one. > > > > And here goes a problem with SDL. To make it work right now, > > you can destroy and create whole window or render surface in > > SDL words. This is a bad behavior... Each plugin change (well, > > gl-to-gl at least) the window will be recreated. > > Yeah that is totally bummer, but if that is the only way for now... glPush* / glPop functions can also be used but it will have slight side effect like making stacks 1-entry shorter. And I am not sure if everything can be saved/restored.. > > Another way to solve this problem is to use CVS version of SDL > > in 1.3 branch. Pros and cons are pretty obvious. Does > > anybody know then 1.3.0 will be released??? > > For libvisual-xmms we can't use SDL 1.3. SDL 1.3 is a must tho if it's > not just only because off the offscreen buffers... Hmm.... I was wrong. Current CVS version won't help here. They do not create more contexts... /* * Create a render target with the given size and attributes. ... * Currently this function does not create a new OpenGL context. ... */ extern DECLSPEC SDL_RenderTarget * SDLCALL SDL_GL_CreateRenderTarget ... > Alright, thanks a lot tho for the comment, it really cleared > things up! My pleasure :) -- Vitaly GPG Key ID: F95A23B9 |
|
From: Duilio J. P. <dp...@fc...> - 2004-07-05 23:57:48
|
> On quit running valgrind ./simplesdl: > > > ==26715== > ==26715== Invalid free() / delete / delete[] > ==26715== at 0x3C01F918: free (vg_replace_malloc.c:127) > ==26715== by 0x3C10B502: visual_list_free > (in /usr/lib/libvisual.so.0.0.0) > ==26715== by 0x3C107D2C: visual_plugin_ref_list_destroy > (in /usr/lib/libvisual.so.0.0.0) > ==26715== by 0x3C10C3A2: visual_quit (in /usr/lib/libvisual.so.0.0.0) > ==26715== Address 0x3CB57A34 is 0 bytes inside a block of size 12 > free'd > ==26715== at 0x3C01F918: free (vg_replace_malloc.c:127) > ==26715== by 0x3C10B502: visual_list_free > (in /usr/lib/libvisual.so.0.0.0) > ==26715== by 0x3C10B5A7: visual_list_destroy > (in /usr/lib/libvisual.so.0.0.0) > ==26715== by 0x3C107D22: visual_plugin_ref_list_destroy > (in /usr/lib/libvisual.so.0.0.0) > ==26715== > ==26715== Jump to the invalid address stated on the next line > ==26715== at 0x0: ??? > ==26715== by 0x3C10C3C0: visual_quit (in /usr/lib/libvisual.so.0.0.0) > ==26715== by 0x8049E87: main > (in /usr/src/libvis-newcvs/libvisual/examples/simplesdl) > ==26715== Address 0x0 is not stack'd, malloc'd or free'd > ==26715== > ==26715== Process terminating with default action of signal 11 > (SIGSEGV): dumping core > ==26715== Access not within mapped region at address 0x0 > ==26715== at 0x0: ??? > ==26715== by 0x3C10C3C0: visual_quit (in /usr/lib/libvisual.so.0.0.0) > ==26715== by 0x8049E87: main > (in /usr/src/libvis-newcvs/libvisual/examples/simplesdl) > ==26715== > > > > Maybe this also causes some xmms plugin borkage that we've been seeing, > not sure tho... That problem with visual_list_destroy() is exactly the same we have in XMMS plugin, and that's the reason I will wait to catch the errors on plugin's quit until libvisual code revision has be done (after 0.1.6). Duilio. |
|
From: Dennis S. <sy...@yo...> - 2004-07-05 21:58:45
|
On the copyright banner stuff. I want to do something like this: Being able to add a file 'copyright-banner.c' to a source dir which contains the banner + appropiate copyright assignment and such. Have a small script, program that adds this to the head of all header and program files AND is capable of replacing the old headers with a newer version. Is this a good idea ? Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-07-05 21:36:51
|
On Tue, 2004-07-06 at 00:02 +0300, Vitaly V. Bursov wrote: > On Mon, 05 Jul 2004 21:54:47 +0200 > Dennis Smit <sy...@yo...> wrote: > > > > > Vitaly, > > > > If you have some time could you look into the following: > > at: http://libvisual.sourceforge.net/LIBVISUAL_TODO > > > > * Fixes in some GL plugins that show odd behavior after another GL > > plugin has been running (better state setting). (everyone!!!) > Yes, I've already seen this, tried to reproduce this and failed. > And I thought it was fixed... > > > This is tiresome to debug but some GL plugins show up really odd > > after another had run before (in the same execution) using > > plugin switches. This is probably easier to monitor when you > > adapt the xmms plugin to only show GL plugins and show them > > randomly... > Now I see. :) Indeed, this is due to settings left by prev. plugin. > > Even worse, If a plugin allocates, say, a (large ;) texture and does > not release it during cleanup, texture will still reside in video > memory. Just like with madspin plugin: there is glGenTextures() > call and no glDeleteTextures(). The same will be with other data > like lists. Would you mind to clean this kind of things up anyway if I gave you CVS access to libvisual CVS ? > Looks like the only way to reset it nicely (everything is set to > defaults in any condition on any hw/sw) is to delete GL context > and create a new one. > > And here goes a problem with SDL. To make it work right now, > you can destroy and create whole window or render surface in > SDL words. This is a bad behavior... Each plugin change (well, > gl-to-gl at least) the window will be recreated. Yeah that is totally bummer, but if that is the only way for now... > Another way to solve this problem is to use CVS version of SDL > in 1.3 branch. Pros and cons are pretty obvious. Does > anybody know then 1.3.0 will be released??? For libvisual-xmms we can't use SDL 1.3. SDL 1.3 is a must tho if it's not just only because off the offscreen buffers... > And the last way -- get rid of SDL and write everything ourselves > or rip off some code from Scivi ;), get potrability problems and > rewrite everythin to SDL back again when it will be released.. HEhe... > Dennis, I really don't know what to do with it... :) Alright, thanks a lot tho for the comment, it really cleared things up! Cheers, Dennis |
|
From: Vitaly V. B. <vit...@uk...> - 2004-07-05 21:20:04
|
On Mon, 05 Jul 2004 21:54:47 +0200 Dennis Smit <sy...@yo...> wrote: > > Vitaly, > > If you have some time could you look into the following: > at: http://libvisual.sourceforge.net/LIBVISUAL_TODO > > * Fixes in some GL plugins that show odd behavior after another GL > plugin has been running (better state setting). (everyone!!!) Yes, I've already seen this, tried to reproduce this and failed. And I thought it was fixed... > This is tiresome to debug but some GL plugins show up really odd > after another had run before (in the same execution) using > plugin switches. This is probably easier to monitor when you > adapt the xmms plugin to only show GL plugins and show them > randomly... Now I see. :) Indeed, this is due to settings left by prev. plugin. Even worse, If a plugin allocates, say, a (large ;) texture and does not release it during cleanup, texture will still reside in video memory. Just like with madspin plugin: there is glGenTextures() call and no glDeleteTextures(). The same will be with other data like lists. Looks like the only way to reset it nicely (everything is set to defaults in any condition on any hw/sw) is to delete GL context and create a new one. And here goes a problem with SDL. To make it work right now, you can destroy and create whole window or render surface in SDL words. This is a bad behavior... Each plugin change (well, gl-to-gl at least) the window will be recreated. Another way to solve this problem is to use CVS version of SDL in 1.3 branch. Pros and cons are pretty obvious. Does anybody know then 1.3.0 will be released??? And the last way -- get rid of SDL and write everything ourselves or rip off some code from Scivi ;), get potrability problems and rewrite everythin to SDL back again when it will be released.. Dennis, I really don't know what to do with it... :) -- Vitaly GPG Key ID: F95A23B9 |
|
From: Dennis S. <sy...@yo...> - 2004-07-05 20:10:25
|
On quit running valgrind ./simplesdl: ==26715== ==26715== Invalid free() / delete / delete[] ==26715== at 0x3C01F918: free (vg_replace_malloc.c:127) ==26715== by 0x3C10B502: visual_list_free (in /usr/lib/libvisual.so.0.0.0) ==26715== by 0x3C107D2C: visual_plugin_ref_list_destroy (in /usr/lib/libvisual.so.0.0.0) ==26715== by 0x3C10C3A2: visual_quit (in /usr/lib/libvisual.so.0.0.0) ==26715== Address 0x3CB57A34 is 0 bytes inside a block of size 12 free'd ==26715== at 0x3C01F918: free (vg_replace_malloc.c:127) ==26715== by 0x3C10B502: visual_list_free (in /usr/lib/libvisual.so.0.0.0) ==26715== by 0x3C10B5A7: visual_list_destroy (in /usr/lib/libvisual.so.0.0.0) ==26715== by 0x3C107D22: visual_plugin_ref_list_destroy (in /usr/lib/libvisual.so.0.0.0) ==26715== ==26715== Jump to the invalid address stated on the next line ==26715== at 0x0: ??? ==26715== by 0x3C10C3C0: visual_quit (in /usr/lib/libvisual.so.0.0.0) ==26715== by 0x8049E87: main (in /usr/src/libvis-newcvs/libvisual/examples/simplesdl) ==26715== Address 0x0 is not stack'd, malloc'd or free'd ==26715== ==26715== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==26715== Access not within mapped region at address 0x0 ==26715== at 0x0: ??? ==26715== by 0x3C10C3C0: visual_quit (in /usr/lib/libvisual.so.0.0.0) ==26715== by 0x8049E87: main (in /usr/src/libvis-newcvs/libvisual/examples/simplesdl) ==26715== Maybe this also causes some xmms plugin borkage that we've been seeing, not sure tho... |
10 messages has been excluded from this view by a project administrator.
