On 04/12/12 12:02, Greg Ercolano wrote:
> Fl_Tree
> |
> |--> Fl_Tree_Item -> Fl_Button
> |--> Fl_Tree_Item -> Fl_Button
> |--> Fl_Tree_Item -> Fl_Button
>
> ..whereas if Fl_Tree_Item derived from Fl_Widget, then you
> could probably create something more memory frugal, such as:
>
> Fl_Tree
> |
> |--> Fl_Tree_Item::Fl_Button
> |--> Fl_Tree_Item::Fl_Button
> |--> Fl_Tree_Item::Fl_Button
>
> ..where the item's xywh values are also Fl_Button's.
>
> Thing is, I don't know how to wedge Fl_Tree_Item's
> data in there if you do that; the tree needs each
> item to have e.g. an open/close state to manage the
> tree properly, so I'm not sure how you'd redefine
> the array of Fl_Tree_Items to instead be an array
> of Fl_Tree_Items that also inherit Fl_Button.
Just to elaborate on this a bit: this is a bit different
than the general case of e.g. an Fl_Group.
Fl_Group can manage anything derived from Fl_Widget,
because internally that base class has all the info
it needs to operate internally.
Fl_Tree needs to manage more info per-item; open/close
info, Fl_Tree_Prefs, etc. So it needs to manage widgets
derived from Fl_Tree_Item to do this.
Which means if you want Fl_Tree to manage items that
are each an Fl_Button, for instance, you'd have to derive
a class from Fl_Tree_Item, and include an Fl_Button in it.
I'm not sure you could benefit from this if Fl_Tree_Item
derived from Fl_Widget, but perhaps one could if it derived
from Fl_Group.
This way the derived class could simply add an Fl_Button
to the Fl_Tree_Item::Fl_Group.
But if you did this, I don't think it would save memory
for either of the possible cases the Fl_Tree might manage:
o A tree of simple 'native' text items
o A tree of FLTK widgets
As it is now, Fl_Tree managing native text items
would come out to ~136 bytes per item:
Fl_Tree
|
|-- Fl_Tree_Item -- 136 bytes
|-- Fl_Tree_Item -- 136 bytes
[..]
..and to manage eg. Fl_Buttons would be:
Fl_Tree
|
|-- Fl_Tree_Item -- 136 bytes \__ 264 bytes
| |-- Fl_Button -- 128 bytes /
|
|-- Fl_Tree_Item -- 136 bytes \__ 264 bytes
| |-- Fl_Button -- 128 bytes /
[..]
These values are based on actual sizeof() values I just found now
with FLTK 1.3.x:
sizeof(Fl_Widget): 120
sizeof(Fl_Button): 128
sizeof(Fl_Tree_Item): 136
sizeof(Fl_Group): 160
If Fl_Tree_Item were modified to derive from Fl_Group,
with optimizations to avoid redundant data, (basically
Fl_Tree_Item's current size minus the size of an Fl_Widget
plus the size of an Fl_Group), you'd then have..
Fl_Tree managing native text items would come out to ~176 bytes
per item:
Fl_Tree
|
|-- Fl_Tree_Item::Fl_Group -- 176 bytes
|-- Fl_Tree_Item::Fl_Group -- 176 bytes
[..]
..and to manage one Fl_Button per item, 304 bytes per item:
Fl_Tree
|
|-- Fl_Tree_Item::Fl_Group -- 176 bytes \__ 304 bytes
| |-- Fl_Button -- 128 bytes /
|
|-- Fl_Tree_Item::Fl_Group -- 176 bytes \__ 304 bytes
| |-- Fl_Button -- 128 bytes /
[..]
So in the end you'd still end up with a /larger/ memory use
I think, as well as some extra overhead for event delivery,
since each Fl_Group would involve its own array for the Fl_Button
child.
But perhaps I'm missing a way to optimize this better, not sure.
eg. there might be tricks with multiple inheritance..?
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs
