]> git.lyx.org Git - lyx.git/blobdiff - development/PAINTING_ANALYSIS
Update PAINTING_ANALYSIS
[lyx.git] / development / PAINTING_ANALYSIS
index f3b8a4760b40a14d9b74aff54dcf7340fec43e08..4934c5e1b6b10289c3511545fe3f58eaac3512f8 100644 (file)
@@ -18,14 +18,6 @@ tm::TextMetrics
 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.
@@ -38,50 +30,128 @@ SingleParUpdate shall be removed.
 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.
+
+The global idea would be to extend FitCursor to cover also horizontal
+cursor.
+
+
+* Proposals
+
+* Clean-up of drawing code
+
+The goal is to make painting with drawing disable fast enough that it
+can be used after every metrics computation. Then we can separate real
+drawing from metrics.
+
+** DONE RowPainter
+
+Inset position is set in paintInset, paintOnlyInsets, and paintText.
+This should be done only once in paintInset
+
+** DONE TextMetrics::drawParagraph
+
+We can really simplify the code when drawing is disabled only
+paintInset needs to be called.
+ + do right at the start when drawing is already disabled
+ + do it in the loop for rows that are not visible on screen.
 
-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 only thing we want to do here is to set inset positions (for
+text). The other insets still use the painter with drawing disabled.
 
-** What happens with FitCursor when the cursor is already OK?
+** Painter::text
 
-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?
+We cannot remove (or make private) the version that uses a
+FontInfo because it is used by PainterInfo::draw. Document this and
+remove unused arguments rtl and double spacing. This would become a specialized helper.
+Proposed solution: keep the existing function, but private and without
+optional arguments.
+
+Avoid to return (and thus compute) the width of strings?
+ + used by InsetSpecialChar (fixable)
+ + used by textDecoration() in text(): more difficult to fix
+
+Idea: add a version of text where wordspacing and textwidth (giving
+the width of strings) are required parameters and remove optional
+version.
+
+==> more versions, no optional parameters.
+
+** Set inset position during metrics phase
+
+In order to do that, a no-paint drawing will be initiated after every
+redoParagraph. This code path will need to be made as fast as possible.
+
+Effect: avoid depending on actual drawing having taken place. In turn,
+it will allow to do drawing on paint events, like any reasonable
+application would do.
+
+** Cleanup after complete metrics
+   Then the following can be done:
+   + remove hack in InsetMathNest::drawSelection
+   + remove painting when not inside in drawParagraph
+   + remove Cursor::inCoordCache?
+
+** Use Row for MathData
+
+It may not be so difficult. Implement x2pos and pos2x from
+the TM:cursorX and TM::getPosNearX, and use them for both text and
+math.
+
+Will the strings display OK if drawing string-wise?
+
+Then it would be possible to streamline drawing with disabled painter.
+
+** Paint directly to screen
+
+Instead of using an intermediary pixmap. I have no idea of how
+difficult it will prove.
+One benefit will be that subpixel aliasing will work again (#9972)
 
 ** 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.
+
+The difficuly 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.
 
 
-* 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,
@@ -89,7 +159,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
@@ -111,7 +180,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
@@ -126,7 +195,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.