Re: Re: button.cc opengl application much slower than button.c and button.pl
- From: Mitchell Laks <mlaks post harvard edu>
- To: gtkmm-list gnome org
- Subject: Re: Re: button.cc opengl application much slower than button.c and button.pl
- Date: Thu, 10 Jan 2008 11:36:12 -0500
On 09:26 Thu 10 Jan , Murray Cumming wrote:
>
> On Thu, 2008-01-10 at 00:24 -0500, Mitchell Laks wrote:
> > I solved this one I think. I noticed that the gears example is just as fast on each one.
> >
> > So I looked and found that the button example uses timeouts while
> > the gears uses timers.
> >
> > I found that if I just speeded up the timeout on the button from 10 seconds
> > to 3 seconds for gtkglextmm it was just as fast as 10 seconds on gtkglext. And
> > at 1 second it was faster.
> >
> > So it turns out to be something about how the timout is implemented in gtkmm
>
> This is unlikely. gtkmm is a thin wrapper. I think that some other
> investigation is needed.
>
Dear Murray,
I apologize. I misspoke!
gtkmm implements gtk timeouts exactly! (Thank you deeply Murray for all your work!
I have have learned so much from reading your writings on your website!)
What I meant to say that this behavior seems to be a function of timeouts in gtk in general.
Naofumi used timeouts for the buttons (jumping torus) example.
timeouts are plagued with a function interaction problem (and differ from timers which are better).
As the GTK API (and gtkmm) documentation of timeout says
"Note that timeout functions may be delayed, due to the processing of other event sources. Thus they should not be relied on for precise timing. After each call to the timeout function, the time of the next timeout is recalculated based on the current time and the given interval (it does not try to 'catch up' time lost in delays)."
There are more function calls in gtkmm thus greater interaction probability!
However, my naive changing of the PRIORITY_DEFAULT to PRIORITY_HIGH
void GLScene::timeout_add()
{
if (!m_ConnectionTimeout.connected())
m_ConnectionTimeout = Glib::signal_timeout().connect(
sigc::mem_fun(*this, &GLScene::on_timeout), TIMEOUT_INTERVAL);
}
to
void GLScene::timeout_add()
{
if (!m_ConnectionTimeout.connected())
m_ConnectionTimeout = Glib::signal_timeout().connect(
sigc::mem_fun(*this, &GLScene::on_timeout), TIMEOUT_INTERVAL, Glib::PRIORITY_HIGH);
}
did not fix the problem.
On the other hand the changing of the TIMEOUT_INTERVAL from 10 to 3 or 1 changed the behavior from
slower : equal : faster than the buttons.c version of the application.
Am I correct?
Thank you again!
Mitchell
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]