Image loading error reporting / handling

[Lubomir Nerad]

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
>>
>