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:

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 Handling stacking contexts. Parents should not draw children in flow for which dw::core::StackingContextMgr::handledByStackingContextMgr returns true.
Interrupted drawing: via dw::core::Widget::drawInterruption; see Interrupted drawing.

Similar rules apply to handling mouse events (dw::core::Widget::getWidgetAtPoint).

Interrupted drawing

→ 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?

Widgets out of flow

dw::Textblock::getGeneratorWidth

Re-evaluate dw::Textblock::getGeneratorWidth (especially the limitation on instances of dw::Textblock) for positioned elements. Is this method really only called for floats?

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.

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 RTFL:

(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