> On 25 Oct 2017, at 12:21, Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote: > > Le 23/10/2017 à 23:34, Patrick De Visschere a écrit : >> With the patch in place, SingleParUpdate in bufferView::draw is never >> reached. > > So finally you mean that an UpdateRequest is really fired for each update > event (which makes sense :), right?
The patch turns every update into a FullScreenUpdate and SingleParUpdate is then obsolete. Every call to viewport()->update() leads to a QEvent::updateRequest I guess. > >>> It would be interesting to set a break on QWindow::requestUpdate and see >>> whether to is something we do that triggers this effect. >> I did and it’s never triggered. > > OK. btw this was about the function requestUpdate(), not the QEvent. > >>>> If I pass the coordinates of the paragraph, I notice that >>>> “SingleParUpdate" actually means “SingleRowUpdate". Since only the >>>> current paragraph is painted black now, except for the current row. > > What happens is that the painting code (in TextMetrics::drawParagraph) only > paints the rows of the paragraph that have changed. This is why you see that > only the row cursor is repainted. If you do a change that changes the cursor > row and the next one (by inserting a character), you should see several rows > repainted. Yes I found the crcCheck on a row. But when forcing a FullScreenUpdate this code becomes useless, since with pi.full_repaint=true every line is redrawn. > > I do not like much the idea of just restricting the update area, since it > seems very fragile. But we can return to it if needed. There are ways to get > all the coordinates that we need. I agree. The dimensions passed via update(x,y,w,h) and the actual area painted must match exactly. I cannot judge the penalty of the screen redraws. I doesn’t seem to hurt very much. Nevertheless I have now something which works mostly. There are still problems when dragging a selection but I believe these can be solved by fine tuning. The other problem is that when opening a document the screen stil turns black. > > There is a point that I would like to clear though: is the screen turned to > black at each event (insertion of a character...), or only when certain > things happen, like the example of doing a PDF preview like Stephan described > at the beginning of this thread? When typing, the whole screen stays black, except for the current line, which looks normal. You don’t have to do anything special to get this. That’s what I expect: when typing a single character in a row, only that row will be repainted but the update() triggers a full screen erase. With a big document it’s sufficient to scroll a little bit to trigger a FullScreenUpdate. So maybe when not typing and moving the mouse around it might not always be obvious. And within a table there is no problem, meaning that the cells do not turn black. Moving the mouse over a table seems to trigger a FullScreenUpdate. > >> I’m still having problems with the basics. I thought there existed a >> document describing the basics of textMetrics, paragraphMetrics … . >> I found something on the wiki but not so much. > > Did you take a look at development/PAINTING_ANALYSIS? I try to maintain it > while doing changes, but it is incomplete, and probably wrong in some places. Yes I found that and it helped. > > JMarc
smime.p7s
Description: S/MIME cryptographic signature
