Re: (severe) performance issues

[Michael L Torrie <torriem chem byu edu>]

On Thu, 2007-03-29 at 10:48 -0700, David J. Andruczyk wrote:
> --- Michael Ekstrand <mekstran scl ameslab gov> wrote:
> 
> > On Thu, 2007-03-29 at 09:24 -0700, David J. Andruczyk wrote:
> > > Though when a widget implementation causes 5-10x more cpu usage
> > due
> > > to a bad design. I think it warrants attention.
> > >
> > > [suggested fix snipped]
> > >
> > > It would solve the cpu usage problem from the resize triggers
> > and
> > > not break backwards compat.  It's also something that should
> > have
> > > been done 3-5 years ago.
> > 
> > It's open-source software.  If this issue is that important to
> > you,
> > submit a patch.  Criticizing the volunteers working on GTK+, who
> > evidently haven't found this to be a significant enough issue to
> > warrant
> > this kind of attention, isn't a constructive way to promote
> > change.
> > 
> 
> I did my part by SUBMITTING BUG REPORTS, several in fact..
> I'm an not a GTK+ wizard, nor do I know all the intricacies about
> how it renders.  hence I GAVE them the information ,described the
> problems, and it was tossed out.

I am not a GTK developer; I'm more of a list lurker.  But I do use GTK
for developing and I am familiar internal GTK code.  So I merely give my
opinion.  The reasons for this being marked as "won't fix" have been, in
my opinion, fairly clearly expressed on the list.  Unless you can a)
argue persuasively why changing this behavior (the so-called bug) is
worthwhile to the majority of GTK users, preserves the ABI, does not
introduce new behaviors or side effects or b) demonstrate code that does
these things, then you need to accept the opinions of the developers and
move on with your own work-around code.  Complaining here will not bring
about any progress on this issue.  I believe I can summarize the reasons
why GTK developers have dismissed your bug report:

- The bad behavior is only apparent in a corner use case of GtkLabel
that was never an intended use.  GtkLabels were never designed for
constant updating.  The nominal use case is a on-time setup, incurring
no more cost than any other widget setup.  Other uses likely need to be
fulfilled by another built-in widget or custom widget.
- Changing the code to fix this behavioral problem would break the
binary compatibility and likely introduce new bugs and side-effects.  A
new API for GtkLabel should be introduced to the GTK3 work, not GTK2.
Despite what you say, your changes would indeed introduce a new API and
break GTK2.x compatibility (ABI).
- The cost in developer time of changing this behavior is simply too
high.  Since it does not affect the speed and stability of 99% of GTK
apps, developer time should be spent elsewhere.

Another minor issue may have been the way you wrote up the bug report.
Bug reports that give the impression that the GTK developers owe you
something will likely not elicit a favorable response, especially given
the points above.  If it was similar to your posts on this issue, then I
can imagine that the human factor may have played a role.

In short, I think GTK developers have agreed with you that this behavior
of the GtkLabel during updates can cause issues, but given the points I
mentioned, will not fix this corner case for you in the stable GTK2
branches.  However they have suggested some very good workarounds,
including writing/borrowing your own GtkLabel widget that would work
better for your use case.  In fact they even told you where to go to see
exactly such code.

cheers,
Michael


> 
> 
> 
> -- David J. Andruczyk
> 
> 
>