Hi Roman,
On Wed, Feb 07, 2007 at 10:12:03AM +0100, Roman Kennke wrote:
> I am currently implementing VolatileImage for a rather exotic system
> (WindML). If I understand it correctly, the VolatileImage class is meant
> to support HW accelerated offscreen images. There are two ways to get
> hold of a VolatileImage, Component.createVolatileImage() and
> GraphicsConfiguration.createCompatibleVolatileImage(). I am wondering
> about the following:
>
> 1. What are these methods supposed to do in the case when there is no
> video RAM left? Should they return null, or something suboptimal? From
It should return a "suboptimal" image. The developer can use
Image.getCapabilities() method to find out if the image is
truly accelerated.
> the API specs this is not clear to me. Some of these methods even accept
> an ImageCapabilities object to specify the requirements (e.g.
> accelerated), but what if the backend can't fullfill these requirements?
This is actually documented in the spec:
Throws:
AWTException - if the supplied image capabilities could not be
met by this graphics configuration
> 2. Since JDK5 the GC methods have variants for accepting a transparency
> value. What if the transparency requirements can't be met? For instance,
> on my system there is no way that the graphics chip can render into a
> translucent bitmap. The best thing I can do is software rendering.
If user requested an accelerated image (via ImageCapabilities),
and you can't fulfill the request, then AWTException should be thrown.
In other cases you can return an unaccelerated image (essentially a
BufferedImage disguised as VolatileImage).
> As far as I can see there would be 3 possibilities:
> 1. Ignore the ImageCapabilities and/or transparency hint and return the
> best that the backend can offer.
Again, if you can't provide requested capabilities, you just throw
an exception, as the spec requires.
> 2. Return the best that the backend can offer that fullfills the hints.
> This would result in software rendering for some cases.
Yes, that's what should happen.
> 3. Return null to indicate to the application that such a VolatileImage
> is not available.
create[Compatible]VolatileImage is not specified to return
null, and in Sun's implementation it never did, so this would
be a bad idea.
> It seems that #1 could be confusing, when an app exclicitly expects for
> example TRANSLUCENT and gets an OPAQUE only image. #2 would probably be
> better handled by returning null to let the app know that there is no
> support on the backend, and let the app try to get a BufferedImage
> instead.
>
> Any insights here?
>
> In any case, I think it would be helpful (for both application
> developers and API implementors) to add some bits to the specs.
I think most of your questions are actually covered by the
spec.
Thanks,
Dmitri
Java2D Team
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
