Re: [fltk.bugs] [MOD] STR #2795: Fl_Tree: needs to be optimized tohandleverylarge contents (10000)
On 04/17/12 06:49, Fabien Costantini wrote: That said, flu combo tree rely on the full tree which permits path navigations, not sure the Fl_Tree permits that ? (i.e. /foo/bar would reference a root foo with a child bar) Yes -- Fl_Tree supports paths (see examples which all use them): add(path) lets you add items with pathnames, auto-creating any parents in the path that don't exist (similar to 'mkdir -p') find_item(path) returns the item* for given path item_pathname(item) returns the path for the given item ..and many other Fl_Tree methods support paths as well, offering both item and paths as arguments (eg. is_selected(), is_open(), etc) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2795: Fl_Tree: needs to be optimized tohandleverylarge contents (10000)
On 04/16/12 18:45, Fabien Costantini wrote:
From the top of mind (I might miss some other flu goodies):
- Show leaves + Show branches - selectable independently
- Sorted, Front, Back, reverse insert api
- Shaded entries
- Multiple selection drag ignore
- {Vertical|Widget} Gap (Fl_Tree has horizontal and top bottom)
- Animate: no really useful but so nice :)
I've opened a new STR for these as RFE's for Fl_Tree:
STR#2828:
http://fltk.org/str.php?L2828
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2795: Fl_Tree: needs to be optimized tohandleverylarge contents (10000)
On 04/17/12 06:49, Fabien Costantini wrote:
Also, on the previous related Fl_Tree design discussion(selection list
as opposed to traverse tree like selection approach) , I wouldn't buy the
performance point on redraw() as you still know what to be redrawn from
the externalized selection list and can rebuild your needed redraw
context in similar ways though it now introduces ptr indirection.
I'd like to understand what you mean, but I don't.. can you
elaborate? I'm probably missing something..
The way I see it, if the selection list is managed as an array
of item ptrs (instead of as a per-item bit flag), then when
Fl_Tree runs its draw() loop, wouldn't it have to do a lookup
on this array each time it has to check if an item is selected
(in order to draw it properly)?
Effectively, the pseudocode:
for (item=first_visible_item; itemlast_visible_item; item++ ) {
if ( is_item_selected(item) )
draw_selected()
else
draw_unselected()
bool is_item_selected(item) {
for (i2=0; i2total_selected_items(); i2++) //
argh: lookup loop
if ( item == selected_array[i2] ) return(true);
return(false)
}
..the problem here being here 'is_item_selected()' becomes
a lookup on a potentially large array, instead of a bit flag test.
If someone did a ^A (select all) on 80k widgets,
the selected_array[] would become 80k large, and so that
array would need to be walked to draw each item.
And whenever the selection is modified (eg. with a Ctrl-Drag
or Shift-Drag), again the array needs to be walked on each
update.
This, as opposed to walking the array once whenever someone
wants to get the selection as an array (ie. a convenience
function). Isn't it better to do that, to prevent constant
array lookups?
I think a bitflag is the better approach, and just compute
the selection list when it's requested (as a single pass at
the array)
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2795: Fl_Tree: needs to be optimized tohandleverylarge contents (10000)
If it's just the tree widget that's needed, I guess I have
to ask, before we embark on having two tree widgets in the
FLTK api.. perhaps I'm missing something obvious, but:
What exactly are the benefits of Flu's tree
over Fl_Tree?
From the top of mind (I might miss some other flu goodies):
- Show leaves + Show branches - selectable independently
- Sorted, Front, Back, reverse insert api
- Shaded entries
- Multiple selection drag ignore
- {Vertical|Widget} Gap (Fl_Tree has horizontal and top bottom)
- Animate: no really useful but so nice :)
C. Fabien's RFE regarding getting selected items as an array
instead of walking the tree (as we do with Fl_Browser)
This could be done, but it shouldn't be default, because it
means a large memory impact for apps that might not need it.
Not necessarily so much more , as if you maintain an array list then you don't
need to store internally the item state - could have readonly items (modified
only at creation time) think about the safe feeling it can provide to guaranty
by design that selection would not alter an item internal state ...
Also there would still be some more work to get th Fl_tree more convivial to
use.
i.e.: the color scheme permits independent fg bg colors per item, nice but when
you change the color in fluid they don't colorize correctly-too sad.
Of course I know about (and I use) the custom API for changing default color
for items to be created but it's a bit of pain for 99 of the use I have of it
and I might not be the only one...
Yet, I am open to keep only one tree class if more conservative opinions are
emitted,as Fl_Tree is definitly a class to be ashamed of in any ways.
We could improve it continually instead ...
As a user of the fltk library, I like choice ; and would be keen on having an
Fl_Tree2 alternative or whatever it could be called.
As a developer, I also understand that maintaining 2 differents implementations
is a bit more work.
That probably has to be ponderated by which class represent the most work to
achieve the same level of functionality as the other ?
Like I said, I'm open on the question.
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2795: Fl_Tree: needs to be optimized tohandleverylarge contents (10000)
Of course read below : *NOT* to be ashamed of in any ways. Yet, I am open to keep only one tree class if more conservative opinions are emitted,as Fl_Tree is definitly a class to be ashamed of in any ways. We could improve it continually instead ... ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2795: Fl_Tree: needs to be optimized tohandleverylarge contents (10000)
On 04/16/12 18:45, Fabien Costantini wrote:
If it's just the tree widget that's needed, I guess I have
to ask, before we embark on having two tree widgets in the
FLTK api.. perhaps I'm missing something obvious, but:
What exactly are the benefits of Flu's tree
over Fl_Tree?
From the top of mind (I might miss some other flu goodies):
- Show leaves + Show branches - selectable independently
Yes, I didn't implement that one, but I take it to mean
one can show the tree as 'branches only' (such as
'directory browser' only shows folders, without files),
and vice versa.
I think it can be added trivially though by adding
a global preference, and adding a simple change
to the draw() routine.
- Sorted, Front, Back, reverse insert api
I think this is in there already:
Sorted -- Fl_Tree::sort_order(FL_TREE_SORT_ASCENDING)
Front -- Fl_Tree::add()
Back -- Fl_Tree::insert(pos=0)
Reverse -- Fl_Tree::sort_order(FL_TREE_SORT_DESCENDING)
I could add Front and Back so that 'Front' changes
add() to call insert(pos=0).
- Shaded entries
Yes, I think of these as 'ruler lines', where every other
item is colored a slightly darker shade.
Should be easy to add of global fg/bg colors are implemented;
see below (**).
Perhaps too, a value to let one to set /how many/ items
are drawn in alternating colors, ie. 1 for odd vs. even,
2 for every two elements, etc.
- Multiple selection drag ignore
Hmm, yes, if I understand that right, a per-item flag
that lets one disable some items from being 'selectable'.
I should probably change the open/visible/active/selected 'char'
to be a single 8 bit char flag, so as to be more memory conservative.
(in the end it might still take 4 bytes, because most compilers
probably like to keep structs/classes 'word aligned')
- {Vertical|Widget} Gap (Fl_Tree has horizontal and top bottom)
Yes, sounds like an omission.
It sounds easy to add, but would have to look.
- Animate: no really useful but so nice :)
Yes, I didn't delve into animation effects because none of
the FLTK 1.x widgets go there, so I decided to be 'consistent' ;)
FLTK has no precedent for such features either, and I didn't
want to pioneer one. To be done right, I could see users wanting
speed control, custom behavior control via virtuals, callbacks,
or derived classes.. didn't wanna go there ;)
C. Fabien's RFE regarding getting selected items as an array
instead of walking the tree (as we do with Fl_Browser)
This could be done, but it shouldn't be default, because it
means a large memory impact for apps that might not need it.
Not necessarily so much more , as if you maintain an array list then you don't
need to store internally the item state
Ah, but I think you do have to store item state internally
to keep redraw() and mouse selection fast.
If during a redraw() every item involved a lookup on
the selection array, doing simple things like scrolling
and dragging mouse selection would be slow.
Also: if I switched the Fl_Tree_Item to using bitflags
for open/visible/active/selected instead of separate chars,
the added memory would be 1/8th of a byte ;)
- could have readonly items
(modified only at creation time) think about the safe feeling it can
provide to guaranty by design that selection would not alter an item internal
state ...
Heh, never-the-less, I'm unmoved. ;)
Pretty sure the need for draw speed and memory footprint
trumps that.
But if there's a way draw() and general selection overhead
can be kept trivial without heavily impacting memory, I'd
be more open.
I think the only way to get the best of both worlds is to
make it an 'option' that is default off, with a method
that returns an array by either taking a single pass at
the tree (if the option is off), or refers to a selection
array (managed by the tree if the option is on).
I think this is a big thing to implement for what I imagine
is a small use case. (I wouldn't think an app that deals with
large lists of data would need the selection list often
enough to need such an optimization where a single pass at
the list would be too slow. This can also be worked around
by other means, such as with selection state callbacks)
I also defer to Fl_Browser's current and long tested behavior;
to find a list of selected items, walk the list to determine it,
with a convenience function that does the same.
But I'd take
Re: [fltk.bugs] [MOD] STR #2795: Fl_Tree: needs to be optimized tohandleverylarge contents (10000)
Yes, glad I read this first ;) On 04/16/12 18:49, Fabien Costantini wrote: Of course read below : *NOT* to be ashamed of in any ways. Yet, I am open to keep only one tree class if more conservative opinions are emitted,as Fl_Tree is definitly a class to be ashamed of in any ways. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
