On Tue, Dec 20, 2005 at 03:37:30PM +0100, Jean-Marc Lasgouttes wrote:
> >>>>> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> 
> Martin> Ah, I see what it is. Two humble brackets:
> 
> Indeed it helps a lot:) The patch seems to work well AFAICS. What
> would be nice is to extend it to work also when selecting: this is an
> operation that feels quite slow with LyX IMO.

The problem here is the following.

<lecture>
When rendering a lyxtext, we proceed in the following three steps 
_in this order_:

1) paint (blank) the background (in an inset, use the inset's background
colour if different)
2) paint the selection in light blue
3) print the text.

In the main text, we first paint a rectangle in background colour
covering the visible (within-viewport) part of the text. This happens in
paintText, the fillRectangle statement. Then we paint the selection: the
call to text->drawSelection. The we paint the paragraphs, one by one.

In order to be able to _selectively_ re-paint rows within paragraphs
(i.e., only some of them, but not all), you have to also be able to
_selectively_ paint background. I did this by splitting the lyxtext
rectangle into single-row rectangles. This happens inside paintPar,
inside the row loop.

Now, if we have a selection, you also have to split up the drawSelection
routine into row-by-row pieces. E.g., write a paintSelection method in
rowpainter.C. Undoubtedly doable, but IMHO not for 1.4.0. 
</lecture>

I decided to compromise. People will accept a bit of slowness during a
rare operation like selecting, but not during basic typing-in.
 
> Also, could you tell why this cannot work with inner insets too? After
> all, the main text is in an inset also.

<lecture>
The same process happens with inner insets too. Look at
RowPainter::paintInset. 

1,2) First call inset->drawSelection (which also paints the inset
background) and 
3) then call inset->draw, which draws the text.

I have successfully suppressed the background painting here and caused
the inset background _and_ text to be painted row-selectively inside the
inset, using the sixth parameter of paintPar, a bool. It works (for the
case of no selection, see above). However, there were a number of
problems. I'll only mention the serious ones here.

A) When you have an inset that's being row-selectively rendered, you
have to suppress -- or rather, "row-selectivise" -- not only its own
background painting, you have also to suppress the background painting
for its containing row in the main text. But that again should only
happen if it is a _non-collapsed, non-inlined_ inset.

B) When you implement the above, you should nevertheless take care that
the containing paragraph's background _is_ painted if you have scrolled
up or down, i.e., if vi.singlerow is false. Because in that case all
rows in the inset will be forcibly refreshed anyway (see the clear()
statement in paintText).

C) Even if you get that under control, I found that there remain
obnoxious rendering bugs in the case that you edit the text inside an
inset such, that the number of rows becomes less. 

D) Insets within insets :-(

At that point I just gave up. I don't know though how much of my grief
came from the { } bug that we just killed.
</lecture>

Hmmm... do you still think I should give it a try for 1.4.0? I expect it
to require major reconstructive surgery, and still not work reliably.

- Martin
 

Attachment: pgpfBEP66Lz2q.pgp
Description: PGP signature

Reply via email to