From: Patrick Lam (plam@plam.lcs.mit.edu)
Date: Sun Aug 04 2002 - 20:16:35 EDT
On Sun, Aug 04, 2002 at 12:50:15PM +1000, Martin Sevior wrote:
>
> I'm strongly not in favour of threads unless it can directly
> demonstrated that only threads can solve the problem at hand and even
> then I'd be worried. I'm by no means convinced that threads will help
> the cursor blinking problem, even with the nicely abstracted code from
> Mike's cursor class. Looking at this code it is clear that this really
> affects a lot of the code. I'd be really wary of implementing it unless
> the person doing the job was fully committed to following through on it
> and had no other major job with AbiWord.
Insertion point updating should be easy, but it's hard because it's
implemented in a silly way. It should be entirely transparent to the
code.
Here's what I will do:
mutex lock on gr_UnixGraphics to prevent two threads from
attempting to do a graphics operation at the same time.
add a GR_Caret field to gr_Graphics which represents the cursor
associated with that graphics context.
GR_Caret class (so this won't live in text/), with a total API of:
- enable()
- disable()
- isEnabled()
- setBlink()
- setCoords()
- some support for bidi carets
When you call setCoords, it explicitly redraws the caret. When you
draw on the GR_Graphics, the caret is undrawn for the duration of the
graphics operation, then drawn again. No cursor dirt is possible under
this new regime.
So all of the places where we go '_eraseInsertionPoint' and
'_drawInsertionPoint' go away completely. We just need to put in a few
enables and disables (and there are much fewer of those than we had
_erase and _draw calls!)
The Unix implementation of the caret will use threads. Other
implementations don't have to, although it's probably a good
implementation strategy to avoid problems with overlapping timers like
we're having now.
> Pat, you know how hard it is debug abi code, imagine if you had to deal
> with threads within the text/* directories.
I'm well aware of that. This is OK, because the total communication
with the main thread is: (1) enable/disable signals; (2) new cursor
positions. No layouts, no containers, no piece table. I feel much
better about this than about incremental loading.
pat
This archive was generated by hypermail 2.1.4 : Sun Aug 04 2002 - 20:23:47 EDT