On Fri, Nov 05, 2004 at 11:52:04PM +0100, Alfredo Braunstein wrote: > Yes, I've arrived to the same conclusion fortunately (and implemented it).
Well done. > One problem that I inmediately had was selections. The whole scheme was too > much dependent on the cursor having good coordinates (which was always > correct because was always on screen), and this was hidding a small > problem: > > You have moved the selection painting code out of rowpainter and put it > between the two drawing steps (after redoParagraph and before paintPar). > The problem was that there, y information of paragraphs was not available > yet and was needed for drawing the selection. Fortunately, I realised that > y information (height and position) for *outer* pars is indeed available > after the redoParagraph scan, and can be then be sent to the cache right > away. The whole is a bit delicate for my taste... maybe I liked the > selection painting in rowpainter was better (what where the > disadvantages?). The problem is that selection painting relies on a warm position cache yet we have the position only _after_ drawing. We need it before, as we want to draw the selection first. Chicken and egg... I think this problem has been there since day one but never emerged to the surface as we always had a warm cache due to the 'extensive' repainting. The only clean solution I can see is to reorganze the current two drawing phases (1. metrics, 2. draw, including pos cache setting) into four: 1. metrics 2. pos cache setting 3. selection drawing 4. text/inset drawing This is conceptually no big change but we would need to touch quite a few inset's draw() methods. Andre'
