Image loading error reporting / handling
lubomir.nerad at oracle.com
Wed Jun 27 08:50:55 PDT 2012
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.
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.
> 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
>> Image/Media need consistent error reporting
>> 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 (!)
>> 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?
More information about the openjfx-dev