Image loading error reporting / handling

Tue Jul 10 06:55:24 PDT 2012

Hi Richard,

On 7/2/2012 4:47 PM, Richard Bair wrote:
> I was also wondering if we shouldn't reuse the Worker API for this.

For what exactly? Having Image.getLoadWorker can only partially satisfy 
RT-17645 and doesn't add on* handlers requested in RT-976. It is almost 
complementary to ImageLoader.

> However I have another question as well, which is how does ImageLoader work in a declarative environment, such as FXML?

ImageLoader doesn't remove the possibility to create images through 
Image constructors, so FXML will still have that possibility. If we want 
to make ImageLoader usable from FXML, we can always add an additional 
Image constructor with an ImageLoader parameter. This will specify which 
ImageLoader to use to load that particular Image. Then one can create an 
instance of ImageLoader in the "fx:define" section (can attach event 
handlers to it there) and then reference it from the defined scene graph 
through its "fx:id".

Alternatively if we don't need that level of control, we can allow to 
define a default ImageLoader for a FXMLLoader or event to define it for 
the whole FX platform (Platfom.setImageLoader?). But this might 
introduce unwanted dependencies.

> 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

I am not against introducing Image.getLoadWorker. But how do we address 
the duplicated properties it will create?

Image.progress vs Image.loadWorker.progress
Image.cancel vs Image.loadWorker.cancel
Image.error vs Image.loadWorker.state

Would you allow deprecation in this case?

>   and (c) could be used declaratively.
>

How? I tried to use web engine load worker in FXML and was quite 
unsuccessful with it. First I don't know how to attach a property 
listener to a property declaratively in FXML and even if that is 
possible somehow, how to dereference WebView.engine and the 
WebEngine.loadWorker. The only way which seemed promising was to use the 
properties of load worker in expression bindings, but that tried to 
access the properties through the internal WebEngine.LoadWorker class 
instead of the public Worker interface and so it ended with an Exception 
(FXML bug?).

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

Lubo

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