Re: Some diffs to optimize drawing

[Nicola Pero]

> >> 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. :-)
>
> I think this is because Adam and I decided to leave it that (some years ago
> now), as removing the lockFocus caused a lot of real life cases of matrixes
> to look a complete mess, with text from one cell getting drawn over into an
> adjacent cell etc.
>
> Of course this was the wrong thing to do ... what should have been done
> was to fix the text drawing to constrain itsself to the cell rectangle 
> properly,
> but neither of us had the time/knowhow to fix that correctly ... so we opted
> for inefficient code which at least made the apps at the time usable.

Yes, right!  But that's a different issue :-)

I think you are really talking about clipping the text drawn in cells ...
which was a performance inefficiency we had (and we still have it!), but
is not related to the change we did, which is a completely new idea,
pointed out by Benhur (thanks Benhur, brilliant).

The change we did is about an additional lockFocus which was performed by
cells, probably caused by a misinterpretaion of the API (we thought [I
definitely thought years ago] that -drawWithFrame:inView: should lock
focus on control view instead of assuming it's already locked - but common
sense [at least, my common sense *now*], some old OpenStep doc on the web,
and the current Apple Mac OS X implementation agree that we can assume
it's already locked).

In theory, with this change nothing has changed except the API and speed -
we have just moved the '[controlView lockFocus]' out of the the cell's
drawWithFrame:inView: and into the caller; the advantage being that
because most of the times the caller can be sure that the lock focus is
already locked on the control view (for example because the caller is
actually drawRect: of that control view), it can avoid the call altogether
- but with no change in what happens when drawing.  So, we get a lot more
speed with no actual change in what is done during drawing (expect for not
locking/unlocking the same view a lot of times, but just once) :-)

Regarding clipping text in cells - I remember what you say - discussing
this issue - years ago - and instead of fixing the text system to only
draw in the given rect, hacking it inefficiently by clipping the drawing
in the cell.  The hack is still there, but hidden down there in the system
- we've moved it inside the string drawing code itself, it's no longer in
the cell.  The string drawing code, when given a rect to draw, actually
clips drawing to the rect, then forgets about it and inefficiently draws
the whole string, even parts of the string which extend outside the rect.

Fixing this issue is still an open task! :-)

But thanks for reminding us - maybe Alexander, in his text system
rewriting/upgrade, is interested in looking at that too ? :-)
 

> So ... I agree that this change is the 'right' thing to to, but it's quite 
> likely it
> has still been masking some other problems, and we need to look out for
> and fix them as soon as we can.

Definitely in the sense that all these changes to locking/drawing are very
delicate.  Probably the lockFocus didn't break much (unless we've
forgotten to update a caller); what might have broken things in
non-trivial ways is that Benhur also tried to remove some of the
inefficient redrawing in NSMatrix, where a lot of code was redisplay to
screen immediately instead of marking stuff as needing redisplay (and
letting them be redisplayed later in a single sweep).  This sort of
changes is very delicate, selections were involved etc.