| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3294
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | Fl_Tree_Item usericon poor performance w/ 10304 |
|---|
| Version: | 1.3.4 |
|---|
| Created By: | mikesart |
|---|
| Assigned To: | greg.ercolano |
|---|
| Fix Version: | 1.3.4 (SVN: v11840) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | mikesart
08:02 Mar 08, 2016 |
| Putting this in here so it doesn't get lost. Started discussion on:
https://groups.google.com/forum/#!topic/fltkcoredev/z6O2qvfWGSU
Also prio 3 because it can _really_ cause massive performance problems.
I'm writing a p4win type client for git, and I've found that when using fltk w/ abi version 10304, the usericon() call can be incredibly slow.
I'm doing this type of thing (adding several entries):
Fl_Tree_Item *item = add( entry.c_str() );
if ( delta_status == 'A' )
item->usericon( s_pixmap_add );
else if ( delta_status == 'D' )
item->usericon( s_pixmap_delete );
The usericon() call is allocating new copies for the dactivated icon every time:
void usericon(Fl_Image *val) {
_usericon = val;
#if FLTK_ABI_VERSION >= 10304
// Update deactivated version of icon..
if ( _userdeicon ) delete _userdeicon;
if ( _usericon ) {
_userdeicon = _usericon->copy();
_userdeicon->inactive();
} else {
_userdeicon = 0;
}
#endif
recalc_tree(); // may change tree geometry
} | |
| |
| #2 | greg.ercolano
17:16 Jul 13, 2016 |
| This can probably be solved as an ABI feature this way:
usericon(Fl_Image *val, int copy=1)
..so that in your case you could set 'copy' to 0.
Internally, there's some unused bits in the '_flags' variable
that can be used to do internal bookkeeping as to whether
the pointer should be delete'ed or not which changed or destroyed. | |
| |
| #3 | greg.ercolano
17:29 Jul 13, 2016 |
| Oops: that last sentence should have ended with:
..pointer should be delete'ed or not WHEN THE ITEM IS changed or destroyed. | |
| |
| #4 | greg.ercolano
22:39 Jul 14, 2016 |
| OK, I've rethought this, and came up with clean/obvious solution.
Seems the best "FLTK way" to do this is to dump the whole idea of
automatically creating the deicon image, and just document how to
the app can set up the 'deactivated copy', so it can manage creating it.
I hadn't anticipated the automatic behavior would be a big memory hit,
but I can see how it would be for many items.
So this new change would restore performance, keeping both usericon()
and userdeicon() implementations simple and fast; no copies are made,
and no automatic creation of the deicon.
Attaching patch suggestion userdeicon_v1.patch to solve.
In the patch, docs for userdeicon(Fl_Image*) show how to create the "grayed out"
copy of the icon, and how the one copy can be applied to all the items,
making efficient use of memory, etc.
Patch also modifies the test/tree program to make use of creating/using
deactivated icons (when the FLTK_ABI_VERSION is set to 10304).
Since 1.3.4 hasn't released yet, I'm not concerned with backing out
the ABI 1.3.4 automatic deicon behavior (currently in SVN). | |
| |
| #5 | greg.ercolano
17:52 Jul 20, 2016 |
| Fixed in Subversion repository.
Applied v1 patch, closed. | |
[ Return to Bugs & Features ]
|
| |
