X-Git-Url: https://git.lyx.org/gitweb/?a=blobdiff_plain;f=development%2FPAINTING_ANALYSIS;h=d1da54baa2c55baf0a91b96b708bf63e438c7457;hb=42f1f5841809eec3751490a3f1177c7d20e16885;hp=08afa500ed7c84a59b7a73c24358438df52e0e08;hpb=c4da9b9e37848909a0f6be2053c5d49225c1a641;p=lyx.git

diff --git a/development/PAINTING_ANALYSIS b/development/PAINTING_ANALYSIS
index 08afa500ed..d1da54baa2 100644
--- a/development/PAINTING_ANALYSIS
+++ b/development/PAINTING_ANALYSIS
@@ -33,34 +33,36 @@ is acted on.
 ** 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?
 
-** What happens with FitCursor when the cursor is already OK?
+** How to avoid redraw 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.
+In this case, we invoke Buffer::change(false) with drawing disabled
+and NoScreenUpdate strategy.
 
-Actually, this was added as part of the horizontal scrolling GSoC
-work. We need to investigate how costly this is.
+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.
 
-* Proposals
-
-** get rid of pm::insetDimension.
+The global idea would be to extend FitCursor to cover also horizontal
+cursor.
 
-The information contained there is already in bv::coordCache.
 
-Effect: only code simplification.
+* Proposals
 
 ** set inset position during metrics phase
 
-This implies to set inset positions relative to outer isnet during
+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.
 
@@ -85,14 +87,15 @@ There was a proposal to always compute _all_ rows, but this may become
 expensive for large files. This would though help scrolling.
 
 
-* Two phase drawing
+* 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,
@@ -100,7 +103,6 @@ There are two parts to drawing the work area:
    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
@@ -122,7 +124,7 @@ The screen is drawn (with appropriate update strategy), except when
 update flag is Update::None.
 
 
-* Metrics computation
+** Metrics computation
 
 This is triggered by bv::updateMetrics, which calls tm::redoParagraph for
   + all visible paragraphs
@@ -137,7 +139,7 @@ of text insets, this will invoke recursively tm::metrics, which redoes
 all the paragraphs of the inset.
 
 
-* Drawing the work area.
+** Drawing the work area.
 
 This is done in bv::draw. This method is triggered mainly by
 Buffer::changed, which draws all the work areas that show the given buffer.