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-07-05 19:55:40
|
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!!!) 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... My knowledge about GL is (still) very limited (I'm planning to read the openGL red book when I'm on vacation!) :) And I'm kinda unable to really solve this easily. Thanks, Dennis |
|
From: Duilio J. P. <dp...@fc...> - 2004-07-05 17:10:55
|
> Heya Duilio, > > Could you verify the following: > > When pressing F11 in libvisual to go fullscreen it hangs, crashes. > > After killing xmms while running in gdb: > #0 0x4192ab57 in lv_xmms_config_toggle_fullscreen () at config.c:168 > > > Not sure what is going on... Ok, problem fixed, thanks Dennis. Duilio. |
|
From: Dennis S. <sy...@yo...> - 2004-07-05 15:38:12
|
Vitaly this is super cool! Thanks a lot I tried writing an ALSA plugin before but gave up after failing twice *shame* :) Thanks a lot for this. I've put the ALSA plugin into CVS, it has some small issues and I'll look into that! But overall this is just superB! How is your scivi openGL plugin going nowadays and what have you been up to ? Cheers, Dennis On Mon, 2004-07-05 at 11:35 +0300, Vitaly V. Bursov wrote: > Hello! > > Here is a small hacky ALSA capture plugin for libvisual. Have no idea > if it will work but it works for me with alsa-lib 1.0.5, recording > source set to "Mix" i.e. everything that goes through codec. > Tested applications: madplay and mplayer. > > You may test it and if it works, you're lucky :) Please note I am > not ALSA programmer and can not provide much support if something > goes wrong... > |
|
From: Dennis S. <sy...@yo...> - 2004-07-05 15:29:05
|
On Mon, 2004-07-05 at 12:09 -0300, Duilio Javier Protti wrote: > El lun, 05 de 07 de 2004 a las 01:18, Dennis Smit escribi=F3: > > Sounds good, in which C file do you wish to add this ? >=20 > I'm not shure, choice is between lv_common.c and a new lv_mem.c. I'd be more happy with lv_mem, we might add more memory related features to it in the future. Thanks, Dennis |
|
From: Duilio J. P. <dp...@fc...> - 2004-07-05 15:07:55
|
El lun, 05 de 07 de 2004 a las 01:18, Dennis Smit escribi=C3=B3: > Sounds good, in which C file do you wish to add this ? I'm not shure, choice is between lv_common.c and a new lv_mem.c. > Btw, did you have a look at the copyright banner I posted > to the list ? Yes, and is right for me. Bye, Duilio. |
|
From: Dennis S. <sy...@yo...> - 2004-07-05 09:39:20
|
Sounds good, in which C file do you wish to add this ? Btw, did you have a look at the copyright banner I posted to the list ? Cheers, Dennis On Sun, 2004-07-04 at 20:00 -0300, Duilio Javier Protti wrote: > I was thinking about to include in the library a > Glib like macro to make request of memory initialized > to 0. It will fail if malloc returns NULL, showing an > useful message. Looks something like: > > void *visual_malloc0 (size_t nbytes); > > #define visual_new0(struct_type, n_structs) \ > ((struct_type *) visual_malloc0 (((size_t) sizeof (struct_type)) * > ((size_t) (n_structs)))) > > > This will let us require memory without checking > the return value and showing a message accordingly. > > People, what do you think? > > > Duilio. |
|
From: Vitaly V. B. <vit...@uk...> - 2004-07-05 08:36:07
|
Hello! Here is a small hacky ALSA capture plugin for libvisual. Have no idea if it will work but it works for me with alsa-lib 1.0.5, recording source set to "Mix" i.e. everything that goes through codec. Tested applications: madplay and mplayer. You may test it and if it works, you're lucky :) Please note I am not ALSA programmer and can not provide much support if something goes wrong... -- Vitaly GPG Key ID: F95A23B9 |
|
From: Dennis S. <sy...@yo...> - 2004-07-05 08:12:45
|
Heya Duilio, Could you verify the following: When pressing F11 in libvisual to go fullscreen it hangs, crashes. After killing xmms while running in gdb: #0 0x4192ab57 in lv_xmms_config_toggle_fullscreen () at config.c:168 Not sure what is going on... Cheers, Dennis |
|
From: Duilio J. P. <dp...@fc...> - 2004-07-04 23:00:41
|
I was thinking about to include in the library a
Glib like macro to make request of memory initialized
to 0. It will fail if malloc returns NULL, showing an
useful message. Looks something like:
void *visual_malloc0 (size_t nbytes);
#define visual_new0(struct_type, n_structs) \
((struct_type *) visual_malloc0 (((size_t) sizeof (struct_type)) *
((size_t) (n_structs))))
This will let us require memory without checking
the return value and showing a message accordingly.
People, what do you think?
Duilio.
|
|
From: Dennis S. <sy...@yo...> - 2004-07-04 22:01:18
|
We need to have a Copyright banner in all our C and header files. I was thinking about the following for the LGPL files: /* Libvisual - The audio visualisation framework. * Copyright (C) 2004 Dennis Smit <sy...@ne...>, * Anyone that <wo...@in...le> * * $Id: * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU Lesser General Public License as published by * the Free Software Foundation; either version 2.1 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA * */ What do you people think ? The GPL banner would be very likewise ofcourse. Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-07-02 21:14:38
|
On Fri, 2004-07-02 at 11:56 -0300, Duilio Javier Protti wrote: > El jue, 01 de 07 de 2004 a las 13:38, Dennis Smit escribi=F3: > > Sounds good, would you like to do it before 0.1.6 or after 0.1.6 = ? > > It's quite a bit of work, I suspect... :( >=20 > I will work on XMMS plugin now, if there is some time later I will > try it before 0.1.6, but there is no hurry, I guess (read below).= =20 >=20 > > Also we need to have good visual_palette helper functions to allo= cate > > colors and the such! >=20 > Ok, we must begin doing a small wishlist about this. Do you need > this functions as soon as possible, for the new things in lv_bmp > in example? If this is the case we can focus work on this. Nah, totally take your time... I think it's more important to get libvisual usable for users for now. Let's first work over the current TODO list and then see if there is anything left ;) Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-07-02 21:14:33
|
On Fri, 2004-07-02 at 11:56 -0300, Duilio Javier Protti wrote: > > Not entirely the same, also adding support for all the depths very well. > > > > I think it would be good to do this at the same time as the VisColor > > change, don't you agree ? > > IMHO, the void* is better. Typing as suggested above is good on the user > side, but a library like libvisual must be as reusable as possible, and > for the pixels I think the only way is to give the void*. You're probably right, we should avoid crack code :). We'll see in the future :) Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-07-02 21:13:41
|
On Fri, 2004-07-02 at 11:56 -0300, Duilio Javier Protti wrote:
> Why not just freed the video->screenbuffer if it is an allocated
> buffer, and set the new one? Because if I do this, what value must
> contain the video->flags?
The reason we don't do this is because a user can swap buffers and the
such. We shouldn't do un expected behavior regarding the screenbuffer
allocation management. Be very careful with automating the screenbuffer
memory management. (Or rather limit this as much as possible) Although
I do agree with the ALLOCATED flags changes.
> The problem is that the void* not give us information about where
> it points, if it is an allocated or an external buffer.
>
> I was thinking about adding a flag argument to visual_video_set_buffer()
> to give this info, but I'm not shure, we must trust so much on the
> client and the interface will be more 'hard' to learn. What do you think
> about it?
If a user allocates his own screenbuffer the memory management is also
in his hands. He can use the free_with_buffer calls to free his buffer
or do it manually with his own frees. In most cases a user that
allocates a buffer himself would be using visual_video_allocate stuff.
The visual_video_set_buffer must be seen as a real low level call and
not too much highlevelness should be done here.
>
> Of course there are other possibilities such as changing the semantic
> of the constructors. I like more this option, but need discussion.
>
> > Also, please have a space between everything and '('.
>
> I don't understand this. Do you mean change 'if (x)' for 'if ( x )'?
> I like that, but is not the style you use on the sources.
I meant HAVE_ALLOCATED_BUFFER(video). I don't make an exception
for macros. I always have spaces between 'blah' and '(' :)
Thanks a lot,
Dennis
|
|
From: Duilio J. P. <dp...@fc...> - 2004-07-02 14:54:49
|
El jue, 01 de 07 de 2004 a las 13:38, Dennis Smit escribi=C3=B3: > Sounds good, would you like to do it before 0.1.6 or after 0.1.6 ? > It's quite a bit of work, I suspect... :( I will work on XMMS plugin now, if there is some time later I will try it before 0.1.6, but there is no hurry, I guess (read below).=20 > Also we need to have good visual_palette helper functions to allocate > colors and the such! Ok, we must begin doing a small wishlist about this. Do you need this functions as soon as possible, for the new things in lv_bmp in example? If this is the case we can focus work on this. Bye, Duilio. |
|
From: Duilio J. P. <dp...@fc...> - 2004-07-02 14:54:42
|
El jue, 01 de 07 de 2004 a las 14:26, Dennis Smit escribi=C3=B3:
> I was thinking some more about this..
>=20
> I think it's wise to change the void *screenbuffer in VisVideo
> to some union that is goom it's Pixel thingy:
>=20
> typedef union _PIXEL {
> struct {
> unsigned char b;
> unsigned char g;
> unsigned char r;
> unsigned char a;
> } channels;
> unsigned int val;
> unsigned char cop[4];
> } Pixel;
>=20
>=20
> Not entirely the same, also adding support for all the depths very well.
>=20
> I think it would be good to do this at the same time as the VisColor
> change, don't you agree ?
IMHO, the void* is better. Typing as suggested above is good on the user
side, but a library like libvisual must be as reusable as possible, and
for the pixels I think the only way is to give the void*.
Is ugly, but this way can be used on any context. May be I'm wrong :-)
Duilio.
|
|
From: Duilio J. P. <dp...@fc...> - 2004-07-02 14:54:41
|
El vie, 02 de 07 de 2004 a las 08:43, Dennis Smit escribi=C3=B3:
> Duilio, thanks for your HAVE_ALLOCATED_BUFFER work!
>=20
> Following:
>=20
> int visual_video_set_buffer (VisVideo *video, void *buffer)
> {
> visual_log_return_val_if_fail (video !=3D NULL, -1);
>=20
> if (HAVE_ALLOCATED_BUFFER (video)) {
> visual_log (VISUAL_LOG_CRITICAL, "Trying to set a scree=
n
> buffer on "
> "a VisVideo structure which points to a=
n
> external screen buffer");
> return -1;
> }
>=20
> video->screenbuffer =3D buffer;
>=20
> return 0;
> }
>=20
>=20
>=20
>=20
> Why is it illegal to set a screen buffer on a Visvideo which points to
> an external screen buffer ?
Sorry, the message is wrong, must say:
"Trying to set a buffer on a VisVideo structure"
"which points to an allocated screen buffer"
Why not just freed the video->screenbuffer if it is an allocated
buffer, and set the new one? Because if I do this, what value must
contain the video->flags?
The problem is that the void* not give us information about where
it points, if it is an allocated or an external buffer.=20
I was thinking about adding a flag argument to visual_video_set_buffer()
to give this info, but I'm not shure, we must trust so much on the
client and the interface will be more 'hard' to learn. What do you think
about it?
Of course there are other possibilities such as changing the semantic
of the constructors. I like more this option, but need discussion.
> Also, please have a space between everything and '('.
I don't understand this. Do you mean change 'if (x)' for 'if ( x )'?
I like that, but is not the style you use on the sources.
Bye,
Duilio.
|
|
From: Dennis S. <sy...@yo...> - 2004-07-02 11:43:35
|
Duilio, thanks for your HAVE_ALLOCATED_BUFFER work!
Following:
int visual_video_set_buffer (VisVideo *video, void *buffer)
{
visual_log_return_val_if_fail (video != NULL, -1);
if (HAVE_ALLOCATED_BUFFER (video)) {
visual_log (VISUAL_LOG_CRITICAL, "Trying to set a screen
buffer on "
"a VisVideo structure which points to an
external screen buffer");
return -1;
}
video->screenbuffer = buffer;
return 0;
}
Why is it illegal to set a screen buffer on a Visvideo which points to
an external screen buffer ?
Also, please have a space between everything and '('.
Cheers and thanks a lot!,
Dennis
|
|
From: Dennis S. <sy...@yo...> - 2004-07-01 17:29:24
|
I was thinking some more about this..
I think it's wise to change the void *screenbuffer in VisVideo
to some union that is goom it's Pixel thingy:
typedef union _PIXEL {
struct {
unsigned char b;
unsigned char g;
unsigned char r;
unsigned char a;
} channels;
unsigned int val;
unsigned char cop[4];
} Pixel;
Not entirely the same, also adding support for all the depths very well.
I think it would be good to do this at the same time as the VisColor
change, don't you agree ?
On Thu, 2004-07-01 at 13:18 -0300, Duilio Javier Protti wrote:
> I suggest to change the _VisPalette structure from:
> ......
|
|
From: Dennis S. <sy...@yo...> - 2004-07-01 16:39:03
|
Sounds good, would you like to do it before 0.1.6 or after 0.1.6 ?
It's quite a bit of work, I suspect... :(
Also we need to have good visual_palette helper functions to allocate
colors and the such!
Thanks,
Dennis
On Thu, 2004-07-01 at 13:18 -0300, Duilio Javier Protti wrote:
> I suggest to change the _VisPalette structure from:
>
> struct _VisPalette {
> unsigned char r[256];
> unsigned char g[256];
> unsigned char b[256];
> };
>
> to
>
> struct _VisPalette {
> int ncolors;
> VisColor *colors;
> };
>
> where _VisColor is:
>
> struct _VisColor {
> unsigned char r;
> unsigned char g;
> unsigned char b;
> unsigned char unused;
> };
>
> This way the palette size is not fixed,
> the colors fit well in memory, and we have
> the same structure than SDL have, so we
> can copy palettes with just a memcpy().
>
>
> Regards,
> Duilio.
|
|
From: Dennis S. <sy...@yo...> - 2004-07-01 16:35:57
|
On Thu, 2004-07-01 at 13:17 -0300, Duilio Javier Protti wrote:
> > You shouldn't check if pal != NULL with debugging messages. pal is legal
> > to be NULL when not being in a 8bits mode.
>
> Ok, but we still deferencing the pointer, which can cause
> a segmentation fault. I have changed to this:
>
> static void sdl_set_pal ()
> {
> int i;
>
> visual_log_return_if_fail (screen != NULL);
>
> if (pal != NULL) {
> for (i = 0; i < 256; i ++) {
> sdlpal[i].r = pal->r[i];
> sdlpal[i].g = pal->g[i];
> sdlpal[i].b = pal->b[i];
> }
> SDL_SetColors (screen, sdlpal, 0, 256);
> }
> }
>
> Do you think is fine?
I think it's good like this, yes :)
|
|
From: Duilio J. P. <dp...@fc...> - 2004-07-01 16:17:49
|
I suggest to change the _VisPalette structure from:
struct _VisPalette {
unsigned char r[256];
unsigned char g[256];
unsigned char b[256];
};
to
struct _VisPalette {
int ncolors;
VisColor *colors;
};
where _VisColor is:
struct _VisColor {
unsigned char r;
unsigned char g;
unsigned char b;
unsigned char unused;
};
This way the palette size is not fixed,
the colors fit well in memory, and we have
the same structure than SDL have, so we
can copy palettes with just a memcpy().
Regards,
Duilio.
|
|
From: Duilio J. P. <dp...@fc...> - 2004-07-01 16:17:05
|
> You shouldn't check if pal != NULL with debugging messages. pal is legal
> to be NULL when not being in a 8bits mode.
Ok, but we still deferencing the pointer, which can cause
a segmentation fault. I have changed to this:
static void sdl_set_pal ()
{
int i;
visual_log_return_if_fail (screen != NULL);
if (pal != NULL) {
for (i = 0; i < 256; i ++) {
sdlpal[i].r = pal->r[i];
sdlpal[i].g = pal->g[i];
sdlpal[i].b = pal->b[i];
}
SDL_SetColors (screen, sdlpal, 0, 256);
}
}
Do you think is fine?
Bye,
Duilio.
|
|
From: Dennis S. <sy...@yo...> - 2004-07-01 12:12:27
|
Alpha overlay is almost completely working now!
By doing (in the render thread in the xmms plugin):
VisVideo *bitmapje = visual_bitmap_load_new_video
("/alphachantest.bmp");
VisVideo *bitmapje32 = visual_video_new ();
visual_video_set_depth (bitmapje32, VISUAL_VIDEO_DEPTH_32BIT);
visual_video_set_dimension (bitmapje32, bitmapje->width,
bitmapje->height);
visual_video_allocate_buffer (bitmapje32);
visual_video_depth_transform (bitmapje32, bitmapje);
/* This is the color to alpha chan function (the first 3 numbers
* are the r g b values for the color that is going to be
* the alpha channel and the last number is
* the density of the other colors */
visual_video_alpha_color (bitmapje32, 255, 0, 234, 128);
Now after visual_bin_run:
visual_video_blit_overlay (video, bitmapje32, 10, 10, TRUE);
10, 10 is placement, the TRUE flag tells the overlay function
to look for an alpha channel.
Result:
http://libvisual.sourceforge.net/libvisual-overlay.png
First image is with density at 128 second image at 255.
The picture has some rough edges, but that is in the pic
not libvisual :)
Cheers,
Dennis
|
|
From: Dennis S. <sy...@yo...> - 2004-07-01 10:32:15
|
Heya Duilio, You shouldn't check if pal != NULL with debugging messages. pal is legal to be NULL when not being in a 8bits mode. Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-07-01 10:18:54
|
I don't thrust garbage collectors in a unmanaged environment, sorry let's stick to the 'good' old memory model. I don't think it's good for speed either. And we really need that, however I must admit I have not investigated it. Cheers, Dennis On Thu, 2004-07-01 at 00:43 -0300, Gustavo Sverzut Barbieri wrote: > Em Thursday 01 July 2004 00:14, Duilio Javier Protti escreveu: > > I have removed temporarily the free() call from > > visual_video_free_buffer(), because we don't > > known if this is memory malloc'ed from us (in XMMS > > plugin this point to the pixels field of the > > SDL_ScreenSurface created by SDL on another thread, > > which can be even a hardware surface). > > -- Thanks to valgrind -- > > > > We need some flags inside the VisVideo that > > tells if the screenbuffer was created by us or > > not. > > What about using a garbage collector? There is a good one for gcc (-lgd). > It runs on any code... it replaces malloc() for a special one and make free() > have no effect > |
10 messages has been excluded from this view by a project administrator.
