]> git.lyx.org Git - lyx.git/blob - development/PAINTING_ANALYSIS
Small refactorings
[lyx.git] / development / PAINTING_ANALYSIS
1 # -*- org -*-
2 Understanding the painting process
3
4 This file tries to describe the state of the metrics/painting
5 mechanism, and identify the improvements that could be made. The first
6 section can be read alone, although the context for them is really
7 given in the following ones.
8
9 Please keep this file up to date as the code evolves!!!
10
11 Abbreviations:
12 bv: BufferView
13 pm: ParagraphMetrics
14 tm::TextMetrics
15
16 * Questions / Ideas
17
18 These questions are consequences of the description made in the
19 following section. Some actions are proposed.
20
21 ** SinglePar update
22
23 This flag only has an effect in the current BufferView, but I think it
24 is useful in other views too. Doing this will require some work on the
25 update pipeline, though.
26
27 ** Buffer::change issues
28
29 When calling Buffer::changed outside of bv::processUpdateFlags,
30 how do we know that the update strategy is set correctly? It is
31 possible to reset the strategy at the end of bv::draw. What would be
32 a good value? NoScreenUpdate?
33
34 On a related note, what is the semantics of a call to
35 Buffer::changed(false)? What does the caller mean?
36
37
38 ** How to avoid redraw with FitCursor when the cursor is already OK?
39
40 In this case, we invoke Buffer::change(false) with drawing disabled
41 and NoScreenUpdate strategy.
42
43 In the draw phase, bv::checkCursorScrollOffset (the horizontal
44 scrolling machinery) will change the strategy to FullScreenUpdate if
45 the current row needs further scrolling.
46
47 When the update strategy it kept to NoScreenUpdate, there is currently
48 a no-draw full repaint, which should not be necessary. It would be
49 possible to avoid that if the call to checkCursorScrollOffset was done
50 in bv::processUpdateFlags instead of bv::draw.
51
52 The global idea would be to extend FitCursor to cover also horizontal
53 cursor.
54
55
56 * Clean-up of drawing code
57
58 ** Set Row::changed() in a finer way
59
60 *** singleParUpdate
61
62 When the height of the current paragraph changes, there is no need for
63 a full screen update. Only the rows after the current one need to have
64 their position recomputed.
65
66 This is also true when scrolling (how to do that?)
67
68 *** redoParagraph
69
70 It should be possible to check whether the new row is the same as the
71 old one and keep its changed() status in this case. This would reduce
72 a lot the amount of stuff to redraw.
73
74 ** Put labels and friends in the Row as elements
75
76 It should not be necessary to access the Paragraph object to draw.
77 Adding the static elements to Row is a lot of work, but worth it IMO.
78
79 ** Create a unique row by paragraph and break it afterwards
80
81 This should be a performance gain (only if paragraph breaking still
82 shows as expensive after the rest is done)
83
84 ** do not add the vertical margin of main text to first/last row
85
86 Would make code cleaner. Probably no so difficult.
87
88 ** When a paragraph ends with a newline, compute correctly the height of the extra row.
89 ** Merging bv::updateMetrics and tm::metrics
90
91 While the full metrics computation tries hard to limit the number of
92 paragraphs that are rebroken, the version that is used for inner inset
93 does not try any such optimization. This can be very bad for very tall
94 insets. We should re-use the bv::updateMetrics logic:
95  + transfer all the logic of bv::updateMetrics to tm.
96  + Main InsetText should not be special.
97
98 The difficulty for a tall table cell for example, is that it may be
99 necessary to break the whole contents to know the width of the cell.
100
101
102 * Description of current drawing mechanism
103
104 ** Three-stage drawing
105
106 There are three parts to drawing the work area:
107
108  + the metrics phase computes the size of insets and breaks the
109    paragraphs into rows. It stores the dimension of insets (both
110    normal and math) in bv::coordCache.
111
112  + the nodraw drawing phase paints the screen (see below) with a null
113    painter. The only useful effect is to store the inset positions.
114
115  + an update() signal is sent. This in turn will trigger a paint
116    event, and the actual screen painting will happen then.
117
118 The machinery is controlled via bv::processUpdateFlags. This method is
119 called at the end of bv::mouseEventDispatch and in
120 GuiApplication::dispatch, via the updateCurrentView method. There are
121 also several calls in code related to dialogs. We should evaluate
122 whether this is correct.
123
124 Depending on the Update::flags passed to the method, it sets an update
125 strategy in (NoScreenUpdate, SingleParUpdate, FullScreenUpdate,
126 DecorationUpdate). It triggers a recomputation of the metrics when either:
127
128  + Update::Force has been specified
129  + Update::FitCursor has been specified and there is a need to scroll
130    the display.
131  + Update::SinglePar has been specified and the current paragraph has
132    not changed height.
133
134 If a computation of metrics has taken place, Force is removed from the
135 flags and ForceDraw is added instead.
136
137 It is OK to call processUpateFlags several times before an update. In
138 this case, the effects are cumulative. processUpdateFlags executes the
139 metrics-related actions, but defers the actual drawing to the next
140 paint event.
141
142 The screen is drawn (with appropriate update strategy), except when
143 update flag is Update::None.
144
145
146 ** Metrics computation (and nodraw drawing phase)
147
148 This is triggered by bv::updateMetrics, which calls tm::redoParagraph for
149 all visible paragraphs. Some Paragraphs above or below the screen (needed
150 for page up/down) and computed as needed.
151
152 tm::redoParagraph will call Inset::metrics for each inset. In the case
153 of text insets, this will invoke recursively tm::metrics, which redoes
154 all the paragraphs of the inset.
155
156 At the end of the function, bv::updatePosCache is called. It triggers
157 a repaint of the document with a NullPainter (a painter that does
158 nothing). This has the effect of caching all insets positions.
159
160 ** Drawing the work area.
161
162 This is done in bv::draw. This method is triggered by a paint event,
163 mainly called through Buffer::changed, which draws all the work areas
164 that show the given buffer.
165
166 Note that, When Buffer::changed is called outside of
167 bv::processUpdateFlags, it is not clear whether the update strategy
168 has been set to a reasonable value beforehand.
169
170 The action depends on the update strategy:
171
172  + NoScreenUpdate: repaint the whole screen with drawing disabled.
173    This is only needed to update the inset positions. I am not sure
174    when this is necessary, actually. This is triggered when:
175    - Update::FitCursor is set but the cursor is already visible. It is
176      not clear why something needs to be done in this case, since this
177      should be equivalent to Update::None.
178    - this is also set when update flag is Update::None, but this value
179      is AFAICS not acted on in the code (meaning that nothing happens
180      at all in this case).
181
182  + FullScreenUpdate: repaint the whole screen. This is set when:
183    - updateMetrics has been invoked.
184    - scroll value of current row has changed (although this should not
185      be necessary).
186
187  + DecorationUpdate: actually like FullScreenUpdate, although it is
188    intended to only update inset decorations. This triggers when:
189    - Update::Decoration is set (without Update::Force) as flag.
190    - An hovered inset is detected.
191
192  + SingleParUpdate: only tries to repaint current paragraph in a way
193    that is not yet very clear to me.
194
195 BufferView::draw can also be called with a null painter from
196 BufferView::updateMetrics().