Image loading error reporting / handling

[John Smith]

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
>