98 lines
3.5 KiB
Plaintext
98 lines
3.5 KiB
Plaintext
/** \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?
|
|
|
|
|
|
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.
|
|
|
|
<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 original 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 number (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>
|
|
|
|
*/
|