1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
/** \page dw-miscellaneous Miscellaneous Notes on Dw
This is a barely sorted list of issues which I consider noteworthy,
but have yet to be moved to other parts of the documentation (which is
partly to be created).
General
=======
Widget allocation outside of parent allocation
----------------------------------------------
A widget allocation outside of the allocation of the parent is
allowed, but the part outside is not visible.
Which widgets may be drawn?
---------------------------
All drawing starts with the toplevel widget
(cf. dw::core::Widget::queueDrawArea, dw::core::Layout::queueDraw, and
dw::core::Layout::expose), and a widget has to draw its children, in a
way consistent with their stacking order.
There are two exceptions:
1. Direct descendants, which are not children, may be drawn, if the
parent can distinguish them and so omit drawing them a second
time. See dw::core::StackingContextMgr and \ref dw-stacking-context.
Parents should not draw children in flow for which
dw::core::StackingContextMgr::handledByStackingContextMgr returns
true.
2. Interrupted drawing: via dw::core::Widget::drawInterruption; see
\ref dw-interrupted-drawing.
Similar rules apply to handling mouse events
(dw::core::Widget::getWidgetAtPoint).
Interrupted drawing
-------------------
→ \ref dw-interrupted-drawing.
Similar rules apply to handling mouse events
(dw::core::Widget::getWidgetAtPoint).
Extra space
-----------
Should dw::core::Widget::calcExtraSpace be called from
dw::core::Widget::getExtremes?
Widget sizes
============
Relation between dw::core::Widget::markSizeChange and dw::core::Widget::queueResize
------------------------------------------------------------------------------------
The following comment should be re-evaluated. Implementing incremental resizing
for dw::oof::OOFFloatsMgr seems to fix the performance problems, but this should
be examined further.
<div style="text-decoration: line-through; color: #606060">
dw::oof::OOFFloatsMgr::markSizeChange (called from
dw::Textblock::markSizeChange) calls dw::oof::OOFAwareWidget::updateReference,
whose implementation dw::Textblock::updateReference calls
dw::core::Widget::queueResize. This may result in a recursion,
- for which it is not clear whether it ends in all cases (although endless cases
are not known yet), and
- which nevertheless may take much time in cases where the number of calls
increases exponentially with the depth of the widget tree.
The recent change in dw::Textblock::updateReference (`if (lines->size () > 0)`)
seems to fix the performance problem, but the issue should be examined further,
albeit with lower priority. Especially, it has to be determined, under which
conditions it is allowed to (directly or indirectly) call
dw::core::Widget::queueResize within an implementation of
dw::core::Widget::markSizeChange.
Here is the orginal test case (slow, when `if (lines->size () > 0)` is removed
again):
(for i in $(seq 1 20); do echo '<div style="float:left"><div></div>'; done) > tmp.html; src/dillo tmp.html
You may change the numner (20), or examine smaller cases with
<a href="http://home.gna.org/rtfl/">RTFL</a>:
(for i in $(seq 1 3); do echo '<div style="float:left"><div></div>'; done) > tmp.html; src/dillo tmp.html | rtfl-objview -OM -A "*" -a resize -a resize.oofm
</div>
*/
|
