29 Dec
2009
29 Dec
'09
10:19 a.m.
Hi,
I have some code in gtk2 that is leaking and I can't fix it. Over the
past two nights I have managed to get the leak down from 200MB/minute to
200MB/10 minutes but I can't get rid of it completely. It's annoying
because it increments in 200MB blocks so I have to wait for up to 10
mins to see if it is fixed or not. I have tried valgrind but it doesn't
really like jack and did not give me any useful output. I have traced
the leak through normal debugging and have verified that it does not
happen if I disable this offending code.
This code is run in the widgets realize event and the event is triggered
every 500ms.
PangoContext *pc = gtk_widget_get_pango_context(widget);
PangoLayout *pl;
PangoFontDescription *pfd;
PangoRectangle rect;
pfd = pango_font_description_new();
pango_font_description_set_family(pfd, "sans");
pango_font_description_set_size(pfd, 8 * PANGO_SCALE);
pango_context_set_font_description(pc, pfd);
pl = pango_layout_new(pc);
pango_layout_set_text(pl, "99", -1);
pango_layout_get_pixel_extents(pl, &rect, NULL);
pango_font_description_free(pfd);
g_object_unref(pc);
If I add another
g_object_unref(pl) ;
The app code will compile but when I run it I get this segfault:
*** glibc detected *** ./src/jackeq: free(): invalid pointer:
0x0000000001b87a60 ***
I can have one g_object_unref for either pl or pc without segfaulting
but not both.
I'm pretty sure this is the last leak I have to catch for the merged
gtkmeter.c/gtkmeterscale.c and I can't release jackeq until it is fixed.
Any assistance with this one is appreciated.
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd
29 Dec
29 Dec
1:03 p.m.
Hi
gtk_widget_get_pango_context(widget) didn't need to unref, it's owned by
the widget you get it from. Unlike the context returned by
gtk_widget_create_pango_context()
I'm use mostly style->font_desc instead.
PangoLayout *pl;
PangoRectangle rect;
GtkStyle *style = gtk_widget_get_style(widget);
pango_font_description_set_family(style->font_desc, "sans");
pango_font_description_set_size(style->font_desc, 8 *
PANGO_SCALE);
gtk_widget_modify_font(widget, style->font_desc);
pl = pango_layout_new(style->font_desc);
pango_layout_set_text(pl, "99", -1);
pango_layout_get_pixel_extents(pl, &rect, NULL);
g_object_unref(pl);
regards hermann
Am Mittwoch, den 30.12.2009, 01:18 +1100 schrieb Patrick Shirkey:
Hi,
I have some code in gtk2 that is leaking and I can't fix it. Over the
past two nights I have managed to get the leak down from 200MB/minute to
200MB/10 minutes but I can't get rid of it completely. It's annoying
because it increments in 200MB blocks so I have to wait for up to 10
mins to see if it is fixed or not. I have tried valgrind but it doesn't
really like jack and did not give me any useful output. I have traced
the leak through normal debugging and have verified that it does not
happen if I disable this offending code.
This code is run in the widgets realize event and the event is triggered
every 500ms.
PangoContext *pc = gtk_widget_get_pango_context(widget);
PangoLayout *pl;
PangoFontDescription *pfd;
PangoRectangle rect;
pfd = pango_font_description_new();
pango_font_description_set_family(pfd, "sans");
pango_font_description_set_size(pfd, 8 * PANGO_SCALE);
pango_context_set_font_description(pc, pfd);
pl = pango_layout_new(pc);
pango_layout_set_text(pl, "99", -1);
pango_layout_get_pixel_extents(pl, &rect, NULL);
pango_font_description_free(pfd);
g_object_unref(pc);
If I add another
g_object_unref(pl) ;
The app code will compile but when I run it I get this segfault:
*** glibc detected *** ./src/jackeq: free(): invalid pointer:
0x0000000001b87a60 ***
I can have one g_object_unref for either pl or pc without segfaulting
but not both.
I'm pretty sure this is the last leak I have to catch for the merged
gtkmeter.c/gtkmeterscale.c and I can't release jackeq until it is fixed.
Any assistance with this one is appreciated.
Cheers.
1:55 p.m.
On 12/30/2009 04:03 AM, hermann wrote:
Hi
gtk_widget_get_pango_context(widget) didn't need to unref, it's owned by
the widget you get it from. Unlike the context returned by
gtk_widget_create_pango_context()
I'm use mostly style->font_desc instead.
PangoLayout *pl;
PangoRectangle rect;
GtkStyle *style = gtk_widget_get_style(widget);
pango_font_description_set_family(style->font_desc, "sans");
pango_font_description_set_size(style->font_desc, 8 *
PANGO_SCALE);
gtk_widget_modify_font(widget, style->font_desc);
pl = pango_layout_new(style->font_desc);
pango_layout_set_text(pl, "99", -1);
pango_layout_get_pixel_extents(pl,&rect, NULL);
g_object_unref(pl);
regards hermann
Thanks. That's a nicer way of doing things but this call segfaults
pango_layout_new(style->font_desc)
gcc tells me this:
note: expected ‘struct PangoContext *’ but argument is of type ‘struct
PangoFontDescription *’
I have replaced it with this:
pl = pango_layout_new(gtk_widget_get_pango_context(widget));
But still get a memory leak. This makes it happen faster than the
previous method I was using. Back down to a couple of minutes before I
see the leak from 10 previously.
Patrick Shirkey
Boost Hardware Ltd
Am Mittwoch, den 30.12.2009, 01:18 +1100 schrieb Patrick Shirkey:
Hi,
I have some code in gtk2 that is leaking and I can't fix it. Over the
past two nights I have managed to get the leak down from 200MB/minute to
200MB/10 minutes but I can't get rid of it completely. It's annoying
because it increments in 200MB blocks so I have to wait for up to 10
mins to see if it is fixed or not. I have tried valgrind but it doesn't
really like jack and did not give me any useful output. I have traced
the leak through normal debugging and have verified that it does not
happen if I disable this offending code.
This code is run in the widgets realize event and the event is triggered
every 500ms.
PangoContext *pc = gtk_widget_get_pango_context(widget);
PangoLayout *pl;
PangoFontDescription *pfd;
PangoRectangle rect;
pfd = pango_font_description_new();
pango_font_description_set_family(pfd, "sans");
pango_font_description_set_size(pfd, 8 * PANGO_SCALE);
pango_context_set_font_description(pc, pfd);
pl = pango_layout_new(pc);
pango_layout_set_text(pl, "99", -1);
pango_layout_get_pixel_extents(pl,&rect, NULL);
pango_font_description_free(pfd);
g_object_unref(pc);
If I add another
g_object_unref(pl) ;
The app code will compile but when I run it I get this segfault:
*** glibc detected *** ./src/jackeq: free(): invalid pointer:
0x0000000001b87a60 ***
I can have one g_object_unref for either pl or pc without segfaulting
but not both.
I'm pretty sure this is the last leak I have to catch for the merged
gtkmeter.c/gtkmeterscale.c and I can't release jackeq until it is fixed.
Any assistance with this one is appreciated.
Cheers.
3:22 p.m.
Am Mittwoch, den 30.12.2009, 04:54 +1100 schrieb Patrick Shirkey:
Thanks. That's a nicer way of doing things but this call segfaults
pango_layout_new(style->font_desc)
gcc tells me this:
note: expected ‘struct PangoContext *’ but argument is of type ‘struct
PangoFontDescription *’
I have replaced it with this:
pl = pango_layout_new(gtk_widget_get_pango_context(widget));
Ah, okay, I didn't really use pango_layout_new, were for do you use it ?
You have already set the Font style, why don't simply label it ?
Do you use the rect afterwards ?
But still get a memory leak. This makes it happen faster than the
previous method I was using. Back down to a couple of minutes before I
see the leak from 10 previously.
Patrick Shirkey
Boost Hardware Ltd
Am Mittwoch, den 30.12.2009, 01:18 +1100 schrieb Patrick Shirkey:
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev Hi,
I have some code in gtk2 that is leaking and I can't fix it. Over the
past two nights I have managed to get the leak down from 200MB/minute to
200MB/10 minutes but I can't get rid of it completely. It's annoying
because it increments in 200MB blocks so I have to wait for up to 10
mins to see if it is fixed or not. I have tried valgrind but it doesn't
really like jack and did not give me any useful output. I have traced
the leak through normal debugging and have verified that it does not
happen if I disable this offending code.
This code is run in the widgets realize event and the event is triggered
every 500ms.
PangoContext *pc = gtk_widget_get_pango_context(widget);
PangoLayout *pl;
PangoFontDescription *pfd;
PangoRectangle rect;
pfd = pango_font_description_new();
pango_font_description_set_family(pfd, "sans");
pango_font_description_set_size(pfd, 8 * PANGO_SCALE);
pango_context_set_font_description(pc, pfd);
pl = pango_layout_new(pc);
pango_layout_set_text(pl, "99", -1);
pango_layout_get_pixel_extents(pl,&rect, NULL);
pango_font_description_free(pfd);
g_object_unref(pc);
If I add another
g_object_unref(pl) ;
The app code will compile but when I run it I get this segfault:
*** glibc detected *** ./src/jackeq: free(): invalid pointer:
0x0000000001b87a60 ***
I can have one g_object_unref for either pl or pc without segfaulting
but not both.
I'm pretty sure this is the last leak I have to catch for the merged
gtkmeter.c/gtkmeterscale.c and I can't release jackeq until it is fixed.
Any assistance with this one is appreciated.
Cheers.
3:37 p.m.
Am Dienstag, den 29.12.2009, 20:22 +0100 schrieb hermann:
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Am Mittwoch, den 30.12.2009, 04:54 +1100 schrieb
Patrick Shirkey:
And when you use style->font_desc, you could move the font discription
to init, and change only the text every 500ms.
Thanks. That's a nicer way of doing things but this call segfaults
pango_layout_new(style->font_desc)
gcc tells me this:
note: expected ‘struct PangoContext *’ but argument is of type ‘struct
PangoFontDescription *’
I have replaced it with this:
pl = pango_layout_new(gtk_widget_get_pango_context(widget));
Ah, okay, I didn't really use pango_layout_new, were for do you use it ?
You have already set the Font style, why don't simply label it ?
Do you use the rect afterwards ?
>
> But still get a memory leak. This makes it happen faster than the
> previous method I was using. Back down to a couple of minutes before I
> see the leak from 10 previously.
>
>
>
>
> Patrick Shirkey
> Boost Hardware Ltd
>
>
>
> >
> > Am Mittwoch, den 30.12.2009, 01:18 +1100 schrieb Patrick Shirkey:
> >
> >> Hi,
> >>
> >> I have some code in gtk2 that is leaking and I can't fix it. Over the
> >> past two nights I have managed to get the leak down from 200MB/minute to
> >> 200MB/10 minutes but I can't get rid of it completely. It's
annoying
> >> because it increments in 200MB blocks so I have to wait for up to 10
> >> mins to see if it is fixed or not. I have tried valgrind but it
doesn't
> >> really like jack and did not give me any useful output. I have traced
> >> the leak through normal debugging and have verified that it does not
> >> happen if I disable this offending code.
> >>
> >> This code is run in the widgets realize event and the event is triggered
> >> every 500ms.
PangoContext *pc = gtk_widget_get_pango_context(widget);
PangoLayout *pl;
PangoFontDescription *pfd;
PangoRectangle rect;
pfd = pango_font_description_new();
pango_font_description_set_family(pfd, "sans");
pango_font_description_set_size(pfd, 8 * PANGO_SCALE);
pango_context_set_font_description(pc, pfd);
pl = pango_layout_new(pc);
pango_layout_set_text(pl, "99", -1);
pango_layout_get_pixel_extents(pl,&rect, NULL);
pango_font_description_free(pfd);
g_object_unref(pc);
If I add another
g_object_unref(pl) ;
The app code will compile but when I run it I get this segfault:
*** glibc detected *** ./src/jackeq: free(): invalid pointer:
0x0000000001b87a60 ***
I can have one g_object_unref for either pl or pc without segfaulting
but not both.
I'm pretty sure this is the last leak I have to catch for the merged
gtkmeter.c/gtkmeterscale.c and I can't release jackeq until it is fixed.
Any assistance with this one is appreciated.
Cheers.
30 Dec
30 Dec
7:51 a.m.
On 12/30/2009 06:37 AM, hermann wrote:
Thanks for your ideas on nailing this bug.
Below is what I have come up with now thanks to your input. I am still
seeing a leak after about 8 mins. The slightly annoying thing to me is
that it increments in a block of 200MB and not gradually. It's as though
pango/gtk is requesting an additional block of memory cache to fill up
each time.
The widget class is a custom class called gtkmeter.c which doesn't have
an internal font description or text value. The code below is for
writing the notch values onto the gtkmeter so this method is called
multiple times for each redraw of the widget. There are 16 instances of
the widget with 11 notch values on each one making a total of 176
requests to this method every 500ms. At 200MB/8 mins that is about 20kb
leak per redraw or approx 120 bytes per request.
db is a float value passed in the method variables.
+++++++++++++++++++++++++++++++++++++++
PangoLayout *pl;
PangoRectangle rect;
GtkStyle *style = gtk_widget_get_style(widget);
char text[3];
snprintf(text, 3, "%.0f", fabs(db));
pl = gtk_widget_create_pango_layout(widget,text);
pango_layout_get_pixel_extents(pl, &rect, NULL);
x = pos - rect.width/2 + 1;
y = width/2 - rect.height / 2 + 1;
if (x < 1) {
x = 1;
} else if (x + rect.width > length) {
x = length - rect.width + 1;
}
gdk_draw_layout(widget->window, widget->style->black_gc, x, y, pl);
last_label_rect->width = rect.width;
last_label_rect->height = rect.height;
last_label_rect->x = x;
last_label_rect->y = y;
g_object_unref (pl);
+++++++++++++++++++++++++++++++++++++++
Patrick Shirkey
Boost Hardware Ltd
>> Am Mittwoch, den 30.12.2009, 01:18 +1100
schrieb Patrick Shirkey:
>>
>>
>>> Hi,
>>>
>>> I have some code in gtk2 that is leaking and I can't fix it. Over the
>>> past two nights I have managed to get the leak down from 200MB/minute to
>>> 200MB/10 minutes but I can't get rid of it completely. It's annoying
>>> because it increments in 200MB blocks so I have to wait for up to 10
>>> mins to see if it is fixed or not. I have tried valgrind but it doesn't
>>> really like jack and did not give me any useful output. I have traced
>>> the leak through normal debugging and have verified that it does not
>>> happen if I disable this offending code.
>>>
>>> This code is run in the widgets realize event and the event is triggered
>>> every 500ms.
>>>
And when you use style->font_desc, you could move the
font discription
to init, and change only the text every 500ms.
8:48 a.m.
Am Mittwoch, den 30.12.2009, 22:50 +1100 schrieb Patrick Shirkey:
Thanks for your ideas on nailing this bug.
Below is what I have come up with now thanks to your input. I am still
seeing a leak after about 8 mins. The slightly annoying thing to me is
that it increments in a block of 200MB and not gradually. It's as though
pango/gtk is requesting an additional block of memory cache to fill up
each time.
The widget class is a custom class called gtkmeter.c which doesn't have
an internal font description or text value. The code below is for
writing the notch values onto the gtkmeter so this method is called
multiple times for each redraw of the widget. There are 16 instances of
the widget with 11 notch values on each one making a total of 176
requests to this method every 500ms. At 200MB/8 mins that is about 20kb
leak per redraw or approx 120 bytes per request.
db is a float value passed in the method variables.
+++++++++++++++++++++++++++++++++++++++
PangoLayout *pl;
PangoRectangle rect;
GtkStyle *style = gtk_widget_get_style(widget);
char text[3];
snprintf(text, 3, "%.0f", fabs(db));
pl = gtk_widget_create_pango_layout(widget,text);
pango_layout_get_pixel_extents(pl, &rect, NULL);
x = pos - rect.width/2 + 1;
y = width/2 - rect.height / 2 + 1;
if (x < 1) {
x = 1;
} else if (x + rect.width > length) {
x = length - rect.width + 1;
}
gdk_draw_layout(widget->window, widget->style->black_gc, x, y, pl);
last_label_rect->width = rect.width;
last_label_rect->height = rect.height;
last_label_rect->x = x;
last_label_rect->y = y;
g_object_unref (pl);
+++++++++++++++++++++++++++++++++++++++
Patrick Shirkey
Boost Hardware Ltd
We use also level meters in guitarix and jcgui, what we do to create the
notch scale is, move it to a background box, a simple hbox, witch we
connect with a expose call. This way the values and scale only redraw
when needed. This is the call we use:
gboolean meter_scale_expose(GtkWidget *wi, GdkEventExpose *ev, gpointer
user_data)
{
cairo_t *cr;
/* create a cairo context */
cr = gdk_cairo_create(wi->window);
cairo_set_font_size (cr, 7.0);
double x0 = wi->allocation.x+1;
double y0 = wi->allocation.y+2;
double rect_width = wi->allocation.width-2;
double rect_height = wi->allocation.height-4;
int db_points[] = { -50, -40, -20, -30, -10, -3, 0, 4 };
char buf[32];
cairo_rectangle (cr, x0,y0,rect_width,rect_height+2);
cairo_set_source_rgb (cr, 0, 0, 0);
cairo_fill (cr);
cairo_pattern_t*pat =
cairo_pattern_create_radial (-50, y0, 5,rect_width-10,
rect_height, 20.0);
cairo_pattern_add_color_stop_rgb (pat, 0, 0.2, 0.2, 0.3);
cairo_pattern_add_color_stop_rgb (pat, 1, 0.05, 0.05, 0.05);
cairo_set_source (cr, pat);
cairo_rectangle (cr, x0+1,y0+1,rect_width-2,rect_height-2);
cairo_fill (cr);
for (uint32_t i = 0; i < sizeof (db_points)/sizeof (db_points[0]);
++i)
{
float fraction = log_meter (db_points[i]);
cairo_set_source_rgb (cr, 0.12*i, 1, 0.1);
cairo_move_to (cr, x0+rect_width*0.2,y0+rect_height -
(rect_height * fraction));
cairo_line_to (cr, x0+rect_width*0.8 ,y0+rect_height -
(rect_height * fraction));
if (i<6)
{
snprintf (buf, sizeof (buf), "%d", db_points[i]);
cairo_move_to (cr, x0+rect_width*0.32,y0+rect_height -
(rect_height * fraction));
}
else
{
snprintf (buf, sizeof (buf), " %d", db_points[i]);
cairo_move_to (cr, x0+rect_width*0.34,y0+rect_height -
(rect_height * fraction));
}
cairo_show_text (cr, buf);
}
cairo_set_source_rgb (cr, 0.4, 0.8, 0.4);
cairo_set_line_width (cr, 0.5);
cairo_stroke (cr);
cairo_pattern_destroy (pat);
cairo_destroy(cr);
return FALSE;
}
it draw a black box with light in the upper left corner, and a scale
with values draw in dark green over light green to red.
regards hermann
8:57 a.m.
On Wed, Dec 30, 2009 at 7:47 AM, hermann <brummer-(a)web.de> wrote:
We use also level meters in guitarix and jcgui, what
we do to create the
notch scale is, move it to a background box, a simple hbox, witch we
connect with a expose call. This way the values and scale only redraw
when needed. This is the call we use:
ardour's Gtkmm2ext::FastMeter optimizes even more. we compute the
difference between the last drawn instance of the meter and the new
appearance and only draw that the delta. this means that we often get
away with drawing just a single row of pixels.
http://subversion.ardour.org/svn/ardour2/branches/2.0-ongoing/libs/gtkmm2ex…
see the vertical_expose() and horizontal_expose() methods. Note that
we are also using precomputed pixbufs and just blitting them.
9:23 a.m.
Am Mittwoch, den 30.12.2009, 07:57 -0500 schrieb Paul Davis:
On Wed, Dec 30, 2009 at 7:47 AM, hermann
<brummer-(a)web.de> wrote:
The LevelMeters we use are highly inspired ( an adaptation) by your
Gtkmm2ext::FastMeter :-) just ported to Gtk+
http://guitarix.svn.sourceforge.net/viewvc/guitarix/trunk/src/GtkFastMeter.…
The expose call I postet here run only when init or redraw after hiden,
and only the scale and notch values.
regards hermann
We use also level meters in guitarix and jcgui,
what we do to create the
notch scale is, move it to a background box, a simple hbox, witch we
connect with a expose call. This way the values and scale only redraw
when needed. This is the call we use:
ardour's Gtkmm2ext::FastMeter optimizes even more. we compute the
difference between the last drawn instance of the meter and the new
appearance and only draw that the delta. this means that we often get
away with drawing just a single row of pixels.
http://subversion.ardour.org/svn/ardour2/branches/2.0-ongoing/libs/gtkmm2ex…
see the vertical_expose() and horizontal_expose() methods. Note that
we are also using precomputed pixbufs and just blitting them.
9:40 a.m.
On 12/30/2009 11:57 PM, Paul Davis wrote:
On Wed, Dec 30, 2009 at 7:47 AM,
hermann<brummer-(a)web.de> wrote:
Thanks for the advice. It's a very cool approach to use except I'm
working with C. I'm not sure I'm up for porting from c++ to c right now.
I am taking a slightly different approach to the visual aspect as I have
added a glassy bubble overlay and the notches sit on top of the overlay.
The meters are redrawing under the overlay to give the effect of being
inside a glassy tube.
So basically I have to redraw the whole thing each time unless I change
the code to use the above method.
The meters by themselves don't add any noticeable load.
Do you think this memory leak can be fixed without having to completely
redo the class to use precomputed bixbufs while porting from c++ to c?
Patrick Shirkey
Boost Hardware Ltd
We use also level meters in guitarix and jcgui,
what we do to create the
notch scale is, move it to a background box, a simple hbox, witch we
connect with a expose call. This way the values and scale only redraw
when needed. This is the call we use:
ardour's Gtkmm2ext::FastMeter optimizes even more. we compute the
difference between the last drawn instance of the meter and the new
appearance and only draw that the delta. this means that we often get
away with drawing just a single row of pixels.
http://subversion.ardour.org/svn/ardour2/branches/2.0-ongoing/libs/gtkmm2ex…
see the vertical_expose() and horizontal_expose() methods. Note that
we are also using precomputed pixbufs and just blitting them.
1:11 p.m.
Hello Patrick et al,
I ported the ardour "fast meters" from C++ to C. Look into guitarix's code
(GtkFastMeter class). It is a direct translation from gtkmm2ext. I picked it up because it
is very CPU friendly, the algorithm focusing only on the "deltas" from one event
to the next. Hermann took care of the layout and that's what he was talking about when
he mentioned something about the box_expose function.
Paul, I mentioned your name and ardour in the guitarix header file. I hope this is fine.
J.
--- On Wed, 12/30/09, Patrick Shirkey <pshirkey(a)boosthardware.com> wrote:
From: Patrick Shirkey
<pshirkey(a)boosthardware.com>
Subject: Re: [LAD] memory leak assistance
To: "Linux Audio Developers" <linux-audio-dev(a)lists.linuxaudio.org>
Date: Wednesday, December 30, 2009, 8:39 AM
On 12/30/2009 11:57 PM, Paul Davis wrote:
compute
the
Thanks for the advice. It's a very cool approach to use
except I'm
working with C. I'm not sure I'm up for porting from c++ to
c right now.
I am taking a slightly different approach to the visual
aspect as I have
added a glassy bubble overlay and the notches sit on top of
the overlay.
The meters are redrawing under the overlay to give the
effect of being
inside a glassy tube.
So basically I have to redraw the whole thing each time
unless I change
the code to use the above method.
The meters by themselves don't add any noticeable load.
Do you think this memory leak can be fixed without having
to completely
redo the class to use precomputed bixbufs while porting
from c++ to c?
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
On Wed, Dec 30, 2009 at 7:47 AM,
hermann<brummer-(a)web.de>
wrote:
> We use also level meters in guitarix and jcgui,
what we do to create the
> notch scale is, move it to a background box,
a
simple hbox, witch we
> connect with a expose call. This way the
values
and scale only redraw
when
needed. This is the call we use:
ardour's Gtkmm2ext::FastMeter optimizes even more. we difference between the last drawn instance of the
meter and the new
appearance and only draw that the delta. this
means
that we often get
away with drawing just a single row of pixels.
http://subversion.ardour.org/svn/ardour2/branches/2.0-ongoing/libs/gtkmm2ex…
see the vertical_expose() and horizontal_expose()
methods. Note that
we are also using precomputed pixbufs and just
blitting them.
2:37 p.m.
On 12/31/2009 04:11 AM, James Warden wrote:
Hello Patrick et al,
I ported the ardour "fast meters" from C++ to C. Look into guitarix's code
(GtkFastMeter class). It is a direct translation from gtkmm2ext. I picked it up because it
is very CPU friendly, the algorithm focusing only on the "deltas" from one event
to the next. Hermann took care of the layout and that's what he was talking about when
he mentioned something about the box_expose function.
Ahhh, I was confused by the file name being GtkFastMeter.cpp so didn't
look into it until now.
My only concern before attempting to switch to this class is that maybe
it won't solve the problem I am seeing. Do the notches get overdrawn by
the meters? It looks like they are separately positioned so as to not
have any conflict.
I guess it shouldn't be a problem because the meters in ardour have
notches and levels in the same coords but I don't really want to find
out that it is after going to the trouble of inserting it to my codebase.
I feel like I am basically finished with these meters if I could fix the
memory leak. I'm wondering if it could be a gtk bug that is being picked
up. Maybe it's just that I shouldn't be making so many calls to pango?
:-/
Patrick Shirkey
Boost Hardware Ltd
3:30 p.m.
Am Donnerstag, den 31.12.2009, 05:36 +1100 schrieb Patrick Shirkey:
On 12/31/2009 04:11 AM, James Warden wrote:
Maybe you try it with cairo, instead pango, :-)
Hello Patrick et al,
I ported the ardour "fast meters" from C++ to C. Look into guitarix's code
(GtkFastMeter class). It is a direct translation from gtkmm2ext. I picked it up because it
is very CPU friendly, the algorithm focusing only on the "deltas" from one event
to the next. Hermann took care of the layout and that's what he was talking about when
he mentioned something about the box_expose function.
Ahhh, I was confused by the file name being GtkFastMeter.cpp so didn't
look into it until now.
My only concern before attempting to switch to this class is that maybe
it won't solve the problem I am seeing. Do the notches get overdrawn by
the meters? It looks like they are separately positioned so as to not
have any conflict.
I guess it shouldn't be a problem because the meters in ardour have
notches and levels in the same coords but I don't really want to find
out that it is after going to the trouble of inserting it to my codebase.
I feel like I am basically finished with these meters if I could fix the
memory leak. I'm wondering if it could be a gtk bug that is being picked
up. Maybe it's just that I shouldn't be making so many calls to pango?
:-/
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
3:53 p.m.
On 12/31/2009 06:30 AM, hermann wrote:
Am Donnerstag, den 31.12.2009, 05:36 +1100 schrieb
Patrick Shirkey:
That's a good idea. Do you have an example of how to use it. it's 6:50am
here and I'm a bit past thinking now :-)
Anyway I have decided to go ahead without the text values for now. I've
run out of time and may not get any more for a couple of weeks. I would
rather release what I have now for people to play with than hold onto it
for any longer.
Thanks for your help though. It was very useful and interesting to get
more details on the meters that are available for gtk.
Cheers.
Patrick Shirkey
Boost Hardware Ltd
On 12/31/2009 04:11 AM, James Warden wrote:
Maybe you try it with cairo, instead pango, :-)
Hello Patrick et al,
I ported the ardour "fast meters" from C++ to C. Look into guitarix's code
(GtkFastMeter class). It is a direct translation from gtkmm2ext. I picked it up because it
is very CPU friendly, the algorithm focusing only on the "deltas" from one event
to the next. Hermann took care of the layout and that's what he was talking about when
he mentioned something about the box_expose function.
Ahhh, I was confused by the file name being GtkFastMeter.cpp so
didn't
look into it until now.
My only concern before attempting to switch to this class is that maybe
it won't solve the problem I am seeing. Do the notches get overdrawn by
the meters? It looks like they are separately positioned so as to not
have any conflict.
I guess it shouldn't be a problem because the meters in ardour have
notches and levels in the same coords but I don't really want to find
out that it is after going to the trouble of inserting it to my codebase.
I feel like I am basically finished with these meters if I could fix the
memory leak. I'm wondering if it could be a gtk bug that is being picked
up. Maybe it's just that I shouldn't be making so many calls to pango?
:-/
9:38 p.m.
On Wed, Dec 30, 2009 at 1:39 PM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
Do you think this memory leak can be fixed without
having to completely
redo the class to use precomputed bixbufs while porting from c++ to c?
Have you tried running under valgrind? a 200meg leak should be simple
to spot with it.
http://live.gnome.org/Valgrind
iain
2 Jan
2 Jan
10:38 a.m.
On Thu, Dec 31, 2009 at 12:39:06AM +1100, Patrick Shirkey wrote:
On 12/30/2009 11:57 PM, Paul Davis wrote:
> ardour's Gtkmm2ext::FastMeter optimizes even more. we compute the
> difference between the last drawn instance of the meter and the new
> appearance and only draw that the delta. this means that we often get
> away with drawing just a single row of pixels.
>
>
http://subversion.ardour.org/svn/ardour2/branches/2.0-ongoing/libs/gtkmm2ex…
>
> see the vertical_expose() and horizontal_expose() methods. Note that
> we are also using precomputed pixbufs and just blitting them.
>
Same for jkmeter and the meters used in AmbDec and TetraProc.
I am taking a slightly different approach to the
visual aspect as I have
added a glassy bubble overlay and the notches sit on top of the overlay.
The meters are redrawing under the overlay to give the effect of being
inside a glassy tube.
So while manufacturers of real HW meters try to do their best to
avoid reflections, you are adding them ? :-)
So basically I have to redraw the whole thing each
time unless I change
the code to use the above method.
No, unless the 'glass' is blurring the picture, all you need is still
two precomputed images.
Ciao,
--
FA
Wie der Mond heute Nacht aussieht !
Ist es nicht ein seltsames Bild ?
5467
days inactive
5471
days old
linux-audio-dev@lists.linuxaudio.org
15 comments
6 participants
participants (6)
-
fons＠kokkinizita.net -
hermann -
Iain -
James Warden -
Patrick Shirkey -
Paul Davis