lyx_mirror/development/PAINTING_ANALYSIS
Jean-Marc Lasgouttes 8d8988de47 Allow multiple calls to processUpdateFlags before redraw
The goal of this commit is to ensure that a processUpdateFlags call
that requires no redraw will not override a previous one that did
require a redraw.

To this end, the semantics of the flag argument is now different: its
value is now OR'ed with a private update_flags_ variable. This
variable is only reset after the buffer view has actually been
redrawn.

A new Update::ForceRedraw flag has been added. It requires a full
redraw but no metrics computation. It is not used in the main code
(yet), but avoids to compute metrics repeatedly in consecutive
processUpdateFlags calls.

The process is now as follows:
- if flags is just None, return immediately, there is nothing to do.
- the Force flag is honored (full metrics computation) and replaced
  with ForceDraw.
- the FitCursor flag is honored and removed from the flags.
- the SinglePar update is added if ForceDraw is not in flags and only
  the current par has been modified.

The remaining flags are only then added to the BufferView update
flags, and the update strategy is computed for the next paint event.

Finally the dubious call to updateMacros in updateMetrics has been
removed for performance reasons.
2017-10-24 22:25:29 +02:00

173 lines
6.5 KiB
Org Mode

# -*- org -*-
Understanding the painting process
This file tries to describe the state of the metrics/painting
mechanism, and identify the improvements that could be made. The first
section can be read alone, although the context for them is really
given in the following ones.
Please keep this file up to date as the code evolves!!!
Abbreviations:
bv: BufferView
pm: ParagraphMetrics
tm::TextMetrics
* Questions / Ideas
These questions are consequences of the description made in the
following section. Some actions are proposed.
** SinglePar update
The flag Update::SinglePar is set in many places but never acted on.
Instead, metrics update is skipped whenever the recorded height of
current paragraph did not change and Update::Force was not specified.
Is it better to keep that (which incurs extra work) or to condition it
on Update::SinglePar? If the first solution is kept, the flag
SingleParUpdate shall be removed.
Moreover, I fail to see (yet) where the 'single' part of the program
is acted on.
** Buffer::change issues
When calling Buffer::changed outside of bv::processUpdateFlags,
how do we know that the update strategy is set correctly? It is
possible to reset the strategy at the end of bv::draw. What would be
a good value? NoScreenUpdate?
On a related note, what is the semantics of a call to
Buffer::changed(false)? What does the caller mean?
** How to avoid redraw with FitCursor when the cursor is already OK?
In this case, we invoke Buffer::change(false) with drawing disabled
and NoScreenUpdate strategy.
In the draw phase, bv::checkCursorScrollOffset (the horizontal
scrolling machinery) will change the strategy to FullScreenUpdate if
the current row needs further scrolling.
When the update strategy it kept to NoScreenUpdate, there is currently
a no-draw full repaint, which should not be necessary. It would be
possible to avoid that if the call to checkCursorScrollOffset was done
in bv::processUpdateFlags instead of bv::draw.
The global idea would be to extend FitCursor to cover also horizontal
cursor.
* Clean-up of drawing code
** When a paragraph ends with a newline, compute correctly the height of the extra row.
** Merging bv::updateMetrics and tm::metrics
While the full metrics computation tries hard to limit the number of
paragraphs that are rebroken, the version that is used for inner inset
does not try any such optimization. This can be very bad for very tall
insets. We should re-use the bv::updateMetrics logic: + transfer all the logic of bv::updateMetrics to tm.
+ Main InsetText should not be special.
The difficulty for a tall table cell for example, is that it may be
necessary to break the whole contents to know the width of the cell.
* Description of current drawing mechanism
** Three-stage drawing
There are three parts to drawing the work area: + the metrics phase computes the size of insets and breaks the
paragraphs into rows. It stores the dimension of insets (both
normal and math) in bv::coordCache.
+ the nodraw drawing phase paints the screen (see below) with a null
painter. The only useful effect is to store the inset positions. + an update() signal is sent. This in turn will trigger a paint
event, and the actual screen painting will happen then.
The machinery is controlled via bv::processUpdateFlags. This method is
called at the end of bv::mouseEventDispatch and in
GuiApplication::dispatch, via the updateCurrentView method. There are
also several calls in code related to dialogs. We should evaluate
whether this is correct.
Depending on the Update::flags passed to the method, it sets an update
strategy in (NoScreenUpdate, SingleParUpdate, FullScreenUpdate,
DecorationUpdate). It triggers a recomputation of the metrics when either:
+ Update::Force has been specified + Update::FitCursor has been specified and there is a need to scroll
the display.
+ the current paragraph, after rebreak, does not have the same height as in
existing metrics. Note that the Update::SinglePar flag is *never*
taken into account.
If a computation of metrics has taken place, Force is removed from the
flags and ForceDraw is added instead.
It is OK to call processUptateFlags several times before an update. In
this case, the effects are cumulative.processUpdateFlags execute the
metrics-related actions, but defers the actual drawing to the next
paint event.
The screen is drawn (with appropriate update strategy), except when
update flag is Update::None.
** Metrics computation (and nodraw drawing phase)
This is triggered by bv::updateMetrics, which calls tm::redoParagraph for
all visible paragraphs. Some Paragraphs above or below the screen (needed
for page up/down) and computed as needed.
tm::redoParagraph will call Inset::metrics for each inset. In the case
of text insets, this will invoke recursively tm::metrics, which redoes
all the paragraphs of the inset.
At the end of the function, bv::updatePosCache is called. It triggers
a repaint of the document with a NullPainter (a painter that does
nothing). This has the effect of caching all insets positions.
** Drawing the work area.
This is done in bv::draw. This method is triggered by a paint event,
mainly called through Buffer::changed, which draws all the work areas
that show the given buffer.
Note that, When Buffer::changed is called outside of
bv::processUpdateFlags, it is not clear whether the update strategy
has been set to a reasonable value beforehand.
The action depends on the update strategy: + NoScreenUpdate: repaint the whole screen with drawing disabled.
This is only needed to update the inset positions. I am not sure
when this is necessary, actually. This is triggered when:
- Update::FitCursor is set but the cursor is already visible. It is
not clear why something needs to be done in this case, since this
should be equivalent to Update::None.
- this is also set when update flag is Update::None, but this value
is AFAICS not acted on in the code (meaning that nothing happens
at all in this case).
+ FullScreenUpdate: repaint the whole screen. This is set when:
- updateMetrics has been invoked.
- scroll value of current row has changed (although this should not
be necessary). + DecorationUpdate: actually like FullScreenUpdate, although it is
intended to only update inset decorations. This triggers when:
- Update::Decoration is set (without Update::Force) as flag.
- An hovered inset is detected.
+ SingleParUpdate: only tries to repaint current paragraph in a way
that is not yet very clear to me.
BufferView::draw can also be called with a null painter from
BufferView::updateMetrics().