• Type: Bug
• Component: javafx
• Sub-Component: graphics
• Affected Version: fx2.0

• Priority: P5
• Status: Open
• Resolution: Unresolved

• Submitted: 2011-08-15
• Updated: 2022-10-21

Other
tbdUnresolved

Note that the current state of this API where it completely ignores incoming images that are not found in the pool can cause problems with the new ManagedResource mechanism. Formerly, if we ignored the images, they would drop on the floor and eventually be reclaimed. I'm guessing that embedded with its limited resources may have run into resource constraints there, but desktops can usually absorb the loss of those resources much more robustly. Now with ManagedResources we actually print warnings at the moment we detect a Texture that was dropped on the floor without explicitly unlocking it, so anyone who calls "create, then release" will cause the next pulse to print out warnings until the image is reclaimed by the garbage collector... 17-10-2013 Another option is to change the name of these methods to be clearer: createCompatibleImage(...) getPoolImage(...); releasePoolImage(...); Since this would be almost as invasive as creating a sub-interfaces "PoolFilterable extends Filterable", we should probably do both together. 15-08-2011 This method is not supposed to free the textures, it is supposed to release it back to the pool so that subsequent calls to getCompatibleImage() can re-use it. This is clearly documented in the method. Right now it silently ignores calls with images that weren't retrieved from the pool. Options for how we should handle this include: - Silently ignore it like we do now (but this could cause bugs when others are confused about the operation of these methods). - Throw an exception (which might break some applications *if* we have a bug that only triggers on rare conditions where we accidentally "release" a non-pool image - on the other hand, such an image would not be aggressively reclaimed which is probably what the calling code thought it was doing in the first place - so we would be trading a silent problem for a visible problem that might get in someone's way, but would encourage fixing the code sooner. - Print an error statement that would annoy people into requesting a fix if there was ever any errant code, but wouldn't actually break anything. - Flush the image (which is probably what the caller wanted, but they are still confused about the use of these methods) - Flush it and either throw the exception or print an annoyance error message. - Change the return value of "getCompatibleImage" to "PoolFilterable extends Filterable" and have release only take a PoolFilterable so we never get confused - but this would require a massive API update. - Log the problem. 15-08-2011