Image loading error reporting / handling

[Richard Bair]

I was also wondering if we shouldn't reuse the Worker API for this. However I have another question as well, which is how does ImageLoader work in a declarative environment, such as FXML?

It seems like having Image have a getLoadWorker() would be better in that it would (a) be consistent with web engine, (b) present a consistent API with the other places where we do background monitoring / loading work and (c) could be used declaratively.

Which is not to say that having an ImageLoader wouldn't be nice (especially if it means we can make what is now a private implementation public rather than adding a new class), but I don't think it is sufficient since it would require procedural programming.

Richard

On Jun 27, 2012, at 8:50 AM, Lubomir Nerad wrote:

> Hi John,
> 
> good question, but I don't think it will be useful in this case. Worker interface is more suitable to track loading of a single Image and most of the information available through that interface is already provided by the Image class. Or we can try to define ImageLoader as a javafx.concurrent.Service, but in that case we would inherit some unwanted methods and loose the possibility to attach some additional information to the reported events.
> 
> Thanks,
> Lubo
> 
> On 6/27/2012 2:19 AM, John Smith wrote:
>> Could (or should) a Worker interface be used as the API to monitor and control Image loading - similar to how webEngine.getLoadWorker() can be used to monitor and control web page loading?
>> 
>> -----Original Message-----
>> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Martin Desruisseaux
>> Sent: Tuesday, June 26, 2012 10:32 AM
>> To: openjfx-dev at openjdk.java.net
>> Subject: Re: Image loading error reporting / handling
>> 
>> One advantage that I see with the proposed ImageLoader class would be
>> its similarity with javax.imageio.ImageWriter, which may make easier to
>> write adapters for interoperability between the two frameworks.
>> 
>>      Martin
>> 
>> 
>> Le 26/06/12 17:18, Lubomir Nerad a écrit :
>>> Hi all,
>>> 
>>> I have two feature requests which ask for better error reporting /
>>> handling of image loading.
>>> 
>>> The issues are:
>>> 
>>> Make Image class support exceptions for both asynchronous and
>>> synchronous loading
>>> (http://javafx-jira.kenai.com/browse/RT-17645)
>>> Image/Media need consistent error reporting
>>> (http://javafx-jira.kenai.com/browse/RT-976)
>>> 
>>> Currently my idea of fixing them is through a new ImageLoader class.
>>> 
>>> This class will have two sets of instance methods for image loading:
>>> 
>>> Image load(...) - Used for foreground image loading. The difference
>>> between them and the Image constructors would be that by default (!)
>>> they will throw an exception if image loading fails [RT-17645]
>>> (instead of returning an Image with error set to true).
>>> 
>>> Image loadAsync(...) - Used for background image loading. Will throw
>>> only when input arguments are null or invalid.
>>> 
>>> Then there will be methods for registering image loading event
>>> handlers [RT-976]. I can think of the following basic set of events:
>>> 
>>> loading started (setOnLoadingStarted)
>>> loading progress (setOnLoadingProgress)
>>> loading finished
>>>     loading succeeded (setOnLoadingSucceeded)
>>>     loading failed (setOnLoadingFailed)
>>> 
>>> They will use a new ImageLoadingEvent and possibly
>>> ImageLoadingFailedEvent (with an added exception field). The
>>> ImageLoadingEvent will report the image for which the event has been
>>> generated (null for foreground images?).
>>> 
>>> Image loading errors will be reported as runtime (!)
>>> ImageLoadingException-s.
>>> 
>>> ImageLoader instances will be created through constructor(s) with
>>> possibility to pass some configuration parameters (for example the
>>> maximum number of images being loaded at the same time).
>>> 
>>> For "logging only" image loaders we might want to allow to configure
>>> (constructor parameter? loadingFailedEvent.consume()?) whether the
>>> load methods will throw ImageLoadingException or merely create Images
>>> with error flags set (as is the case of Image constructors).
>>> 
>>> This is just a basic outline of my proposal. We can focus on details
>>> when/if this approach is accepted. Alternatively the issues could be
>>> fixed by additional properties / methods on Image class. I didn't like
>>> it, because the added properties would be useful only during short
>>> period of the whole image lifetime and absolutely unusable for some
>>> images (images created from scratch). I also think that the
>>> ImageLoader approach makes uniform error handling of image loading
>>> easier (one handler for several images instead of one handler per image).
>>> 
>>> What is your preference / opinion about this?
>>> 
>>> Thanks,
>>> Lubo
>>> 
>>