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
pgpfBEP66Lz2q.pgp
Description: PGP signature