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?
JMarc
