[Kst] Performance

Barth Netterfield netterfield at astro.utoronto.ca
Thu Dec 16 19:01:16 CET 2004


On December 16, 2004 11:36 am, George Staikos wrote:
> On Thursday 16 December 2004 10:16, Barth Netterfield wrote:
> > It seems to me that the order we should be attacking this is:
> > -Make sure there are no updates or redraws we don't need
> > -Make sure that anything we do in the updates or redraws that we don't
> > need to do isn't done. (eg, don't redraw hidden plots, don't recalculate
> > psds if input doesn't change)
>
>    Do we want to redraw on tab click?  It's messy with multiple windows
> too...

In real time mode it is an easy call: it doesn't make sense to redraw every 
time in case someone might change tabs.  I think this is *really* important.

How about this: on a paint event on a hidden tab, just set _dirty.
On a paint event on a shown tab, check _dirty...

Then, they are only drawn if they are visible, but swaping tabs after the 
first redraw will be fast for static data.

With the other MDI modes there is no reliable optimizations possible, so we 
won't do them.

> > -Make sure things aren't waiting for things that they don't need to be
> > waiting for...
>
>     Include X11 calls, which is what QCursor::pos() does.  It's a
> roundtrip...

How long on a local machine?  Over the web, obviously, this is open ended...
1 per mouse I assume...

> > -Come up with a way of testing for regressions in this.
>
>    Would -really- help if we had this.
>
> > -Improve the algorithms within the updates.
>
>     This is part of #2 also.

Statistical optimizations, etc was what I was refering to here.  Local 
optimizations.



More information about the Kst mailing list