-# -*- 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
These questions are consequences of the description made in the
following section. Some actions are proposed.
-** Inset cache
-
-Why do we store inset dimensions both in bv::coordCache and in
-pm::insetDimension? The later one is bad when same
-buffer is shown in different views.
-
-I propose to get rid of pm::insetDimension.
-
** SinglePar update
The flag Update::SinglePar is set in many places but never acted on.
Moreover, I fail to see (yet) where the 'single' part of the program
is acted on.
-** Two phase drawing
-
-Why is it necessary to set the inset positions in the drawing phase?
-It seems to me that everything can be done in the metrics phase (at
-least for non-math insets).
-
** Buffer::change issues
When calling Buffer::changed outside of bv::processUpdateFlags,
-how do we now that the update strategy is set correctly? It is
+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?
-** Metrics outside of visible area
+** 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.
-Why is it required to compute metrics on page above and below the
-visible area? Couldn't this be done on demand? I suspect this could be
-made transparent by doing it in the proper metrics-fetching method.
+The global idea would be to extend FitCursor to cover also horizontal
+cursor.
-** What happens with FitCursor when the cursor is already OK?
-In this case, we invoke Buffer::change(false) with drawing disabled,
-which means that the paint machinery is invoked to update inset
-positions. Why is this necessary at all?
+* Proposals
+
+** set inset position during metrics phase
+
+This implies to set inset positions relative to outer inset during
+metrics phase and then in a second loop to descend into insets and
+update positions correctly.
+
+Effect: avoid going through the painter machinery when it is not necessary.
** 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. How difficult would it be to re-use the bv::updateMetrics logic?
+insets. We should re-use the bv::updateMetrics logic:
+ + transfer all the logic of bv::updateMetrics to tm.
+ + Main InsetText should not be special.
+
+** Metrics outside of visible area
+Currently metrics are computed for current visible paet of text, the
+page above and the page below. It should be possible to compute hidden
+rows ony on demand, although it might be a bit slow.
-* Two phase drawing
+There was a proposal to always compute _all_ rows, but this may become
+expensive for large files. This would though help scrolling.
+
+
+* Description of current drawing mechanism
+
+** Two stage drawing
There are two 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, and the size of normal
- insets in pm::insetDimension.
+ normal and math) in bv::coordCache.
+ the drawing phase draws the contents and caches the inset
positions. Since the caching of positions is useful in itself,
thing we want is to cache inset positions
(Painter::setDrawingEnabled).
-
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
+ Update::Force has been specified
+ Update::FitCursor has been specified and there is a need to scroll
the display.
- + the current paragraph, after rebreak, has the same height as in
+ + 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.
projects / lyx.git / blobdiff