Re: Dispatch of GObject virtual functions in GtkMM

[Murray Cumming <murrayc murrayc com>]

Did you ever get this to work?

I really like to know if there really are performance problems
associated with the callbacks, so we can fix them if necessary.

On Fri, 2007-01-12 at 21:58 +0100, Murray Cumming wrote:
> On Thu, 2007-01-11 at 08:20 -0600, Matt Hoosier wrote:
> > Oh, sorry; typographical errors didn't make my meaning very clear.
> > 
> > The test program which I attached earlier
> 
> Of course I had to comment out the on_expose_event() method, because it
> calls the now non-existant Window::on_expose_event(). I found it rather
> odd that it called Main::quit() anyway.
> 
> >  hangs forever on the
> > Window::add() call.
> 
> It works for me. It shows a matrix of buttons and checkboxes. 
> 
> I built glibmm with
>   --enable-vfuncs=no --enable-default-signal-handlers=no
> and then I rebuilt gtkmm with
>   --enable-demos=no --enable-examples=no
> 
> Could you post your exact test case and also the stacktrace, please.
> 
> Another thought: If these slowdowns are real and significant, then you
> could invesigate them with a tool such as kcachegrind (after getting the
> data from valgrind). kcachegrind isn't useful for IO-bound performance
> problems, but should be fine for this.
> 
> >  When I take a look at the stacktrace in a
> > debugger, the results make no sense:
> > 
> > There's only one thread, and none of the frames in its stack are
> > resolvable to any known symbol. Not even the bottommost one, which
> > should be main().
> > 
> > This is the exact set of symptoms that showed up when I was debugging
> > the problem in glibmm which turned out to be caused by a wrong
> > C_GNUC_NORETURN annotation.
> > 
> > But none of the various overrides of Container::add() seems to put
> > that annotation on, so I'm out of obvious suspects to consider.
> 
-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com