> On 25 Oct 2017, at 16:28, Jean-Marc Lasgouttes <[email protected]> wrote: > > Le 25/10/2017 à 16:15, Patrick De Visschere a écrit : >>> 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. > > Yes, I meant without the patch that does a full repaint on each full paint > event. > >> btw this was about the function requestUpdate(), not the QEvent. > > I suspect they are the same, but the Qt source is really too big for me. I > tried to understand what happens, but it is hard to grasp. > >> 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. > > Of course, if we force, we force. > >>> 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. > > And the other problem is that we do a lot of useless painting (that is > ignored by the clipping but probably still costs us). > >>> 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. > > OK, assume that you managed to get afull repaint (with some scrolling for > example). Now, if you type a character, does it turn the whole work area to > black? >
Yes (except for some insets, as always) and when in a table the whole table remains normal. > JMarc
smime.p7s
Description: S/MIME cryptographic signature
