gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some diffs to optimize drawing


From: Nicola Pero
Subject: Re: Some diffs to optimize drawing
Date: Sat, 1 Feb 2003 05:27:29 +0000 (GMT)

On Wed, 29 Jan 2003, Benhur Stein wrote:

> Hi all.
> 
> Here are some diffs to lots of classes in gui that do some 
> optimizations in the way things are drawn.
> 
> Basically what is done is the following:
> 
> Remove lockFocus from draw methods in cell (and view) classes. Those
> methods should always be called with focus locked.

Ok.

Yes - I think you are right, and we have been basically wrong for quite a
long time. :-)

It makes a lot more sense to assume that NS*Cell -drawWithFrame:inView: is
called with the focus already locked on the view.  That removes *a lot* of
unnecessary lockFocus/unlockFocus calls.

You always invoke that method from within a NSView -drawRect: anyway.

Basically, there are certain methods which are 'drawing' methods.  I think
everything having a name beginning with 'draw' is in that class - all
those methods should be called with the focus already locked.  Of couse we
should document which methods are to be called with the focus already
locked, and which with not.

Before removing lockFocus/unlockFocus from cell's drawing methods, I also
did some tests on Apple Mac OS X and I think they do the same too.


> Added lock/unlock methods on other methods that call draw... methods.
> 
> Tried to diminish the frequency of calls to flushWindow.
> Many changes have been made to NSMatrix in this area. I think this class
> needs some refactoring or maybe some rewriting, it's very complex and uses
> many different ways of doing the same things.

Yes - it's horrible. :-)

I applied your patch - except the few changes to NSWindow and NSView's
locking stuff as I need to look at it separately (but no time for it
today/tomorrow ... maybe Adam or Richard want to look at them in the
meanwhile).

I applied all the rest ... and extended it a lot - I hope I've covered all
classes in gnustep-gui.

NSMatrix was difficult, and while the new version works (and it feels a
lot faster to me, I'm not sure if it's real or an impression), by playing
with the save panel I could get it into some sort of infinite loop with
cpu panting - had to kill it.  So I think we need to check that out a
little bit better.  :-)

Still, given that it's a common complain that the gui is slow :-), I
applied the stuff.

I hope people are happy with the speed improvement.  And yes, working more
on the flushing might definitely have beneficial effects on speed.  I
don't have time to work on it myself.

I suggest small incremental improvements ... it's quite possible to work
that way.
 

> Of the ones I looked, the ones that I think need some reworking (independently
> of this patch) are:
> - NSMatrix: it is too complex and probably wrong in some places (keyboard
> navigation of radio buttons seems broken, for example).
> 
> - NSTableHeaderView -mouseDown is also too complex.

Yes - looking at the code for those classes, I was scared - we really need
to refactor and rewrite properly - some of those are horrible. :-)

Btw, speaking of complexity, in NSTableView.m there is a monster function
of around 2500 lines ... to compute selections.  That *has* to be
simplified or rewritten somewhat to be manageable. :-)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]