FLTK logo

STR #3410

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]

STR #3410

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:4 - High, e.g. key functionality not working
Scope:3 - Applies to all machines and operating systems
Subsystem:Image Support
Summary:Fl_Shared_Image:find() doesn't find some existing images
Version:1.3.4
Created By:AlbrechtS
Assigned To:AlbrechtS
Fix Version:1.3.9
Fix Commit:c10183379fdc0497f9275385d23d174c0f2d4461
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 AlbrechtS
06:02 Oct 02, 2017
shared_image.cxx
8k
 
 
#2 AlbrechtS
06:35 Oct 02, 2017
compare.diff
2k
 
 
#3 AlbrechtS
06:36 Oct 02, 2017
compare_1.4.diff
1k
 
     

Trouble Report Comments:


Name/Time/Date Text  
 
#1 AlbrechtS
05:46 Oct 02, 2017
Fl_Shared_Image:find() and hence Fl_Shared_Image:get() can miss existing shared images if more than one image of the same name is cached. This is due to the way the binary search algorithm or, to be precise, Fl_Shared_Image::compare() is implemented.

Note that this is not a regression - it is probably the case since the first implementation of the binary search algorithm in Fl_Shared_Image (around 2002 or earlier) and up to current svn r 12473 in FLTK 1.3.4 and FLTK 1.4.0.

As long as shared images could be loaded only from files, Fl_Shared_Image::get() would reload the file, and this would make the program work as expected, although with some performance issues, because the image would be reloaded from the file. As Roman noted in omment #1 on STR #3297 [3] this could also cause memory leaks.

For further information see fltk.general, thread "FL_Shared_Image::get(...) returns NULL for an exists image" [1] and [2]

[1] https://groups.google.com/d/msg/fltkgeneral/MIf_bXBs5rw/_KxdXjehBgAJ
[2] https://groups.google.com/d/msg/fltkgeneral/vMNaF0s5RHc/JQ_zAuCnBgAJ
[3] http://www.fltk.org/str.php?L3297
 
 
#2 AlbrechtS
06:02 Oct 02, 2017
The attached demo program shared_image.cxx shows that some of the images are not found if used with the original software (svn r 12473 or earlier).

This demo uses an image file loaded from memory. In this case Fl_Shared_Image::get() doesn't find the image and can't load it from a file (as described above), so it fails to load some of the images.

The key point for the failure is that the shared images are sorted by name, width, and height. Hence the original image can be at an arbitrary position within the list of images with the same name. Thus the binary search applied in Fl_Shared_Image::find() is not guaranteed to hit the original image in the list and may fail.
 
 
#3 AlbrechtS
06:35 Oct 02, 2017
The proposed solution is to ensure that the original image is always the first image of those with the same name so the binary search with width==0 will always find the original image because it is always compared 'less than' any other image with the same name.

Attached patch compare.diff can be applied to FLTK 1.3.x svn without changes.
 
 
#4 AlbrechtS
06:36 Oct 02, 2017
Attached patch compare_1.4.diff can be applied to FLTK 1.4.0 svn without changes. The only difference is the copyright year (not patched).  
 
#5 AlbrechtS
11:51 Dec 04, 2021
Raised priority to "High" - this should really be in 1.4.0!

It is long overdue but IIRC the relevant code might have changed meanwhile. Needs investigation...

See also GitHub Issue #188: "Fl_Shared_Image Improvements"
 
 
#6 AlbrechtS
05:35 Dec 07, 2023
FTR: We (thanks, Matt) made good progress on issue #188 for branch-1.3 (release 1.3.9).
commit 783d50e6b1ab9ed26eb7e066473725fb16e7a7f1 fixes all currently known issues in FLTK 1.3.

I'm leaving this STR "active" with "Fix Version: 1.3.9" for now since we still need an equivalent patch for 1.4.0 (Git 'master'). I did not yet update the "Fix Commit" field intentionally.
 
 
#7 AlbrechtS
12:54 Dec 13, 2023
Fixed in Git repository.

Finally also fixed in Git master (1.4.0) by git commit c10183379fdc0497f9275385d23d174c0f2d4461 by Matt. Thanks.

Closing now.
 
     

Return to Bugs & Features ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.