[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Image loading error reporting / handling
From:       lubomir.nerad () oracle ! com (Lubomir Nerad)
Date:       2012-06-27 15:50:55
Message-ID: 4FEB2BDF.50009 () oracle ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]