GraphicsConfiguration Lies!!!

[Thomas E Deweese <th...@kodak.com>]

Hi all,

   I'm in the process of verifying my changes and I came across an
ugly fact.  The Graphics2D.getDeviceConfiguration call shares
GraphicsConfigurations between 'similar' BufferedImages.

   This means that the graphics configuration object from
BufferedImages of different sizes will report the same bounds if the
run time thinks they are similar.  It also means that they will report
the same ColorSpace.  I'm not certain when this sharing is broken but
it definitely isn't broken based on ColorSpace or the size of the
image.

   My best solution to this is to introduce a BufferedImage Rendering
hint that will contain a reference to the BufferedImage that we must
_religiously_ set when creating a Graphics from a BufferedImage
(usually via the 'createGraphics' call).

   This is _slightly_ better than the pre-existing AOI hint since it
only needs to be set when the Graphics is first created, and never
needs to be 'updated' through processing.  It also does make a few
things possible that weren't possible previously, such as doing
copies, or even rendering directly into the BufferedImage instead of a
sequence of Graphics2D.drawImage operations (although drawImage tends
to be quick anyway).

   Any better ideas, other suggestions?

tref inheritance

[Bill Haneman <bi...@ireland.sun.com>]

Hi folks:

In tracking down the source of the tref text selection bug,
I have discovered that tref elements do not appear to 
inherit properties as I expect.

For instance in this example:

<text x="100">
    <tref xlink:href="some_url"/>
<text>

there is no "x" attributed defined on the tref element
(I don't mean the referenced element, I mean the tref element
itself).

Can someone explain this?  I would have thought that tref would
inherit from the text parent, and that the tref's content
(including other attributes, which might override those that
were inherited) would come from the URI.

In the example above, tref needs to inherit "x" in order to
give the text element the appropriate attributes.  If you 
change the example to

<text>
    <tref x="100" xlink:href="some_url"/>
</text>


then it works, the explicit attributed on tref are found 
when building the text string's attribute map - so it
seems reasonable that the tref _inherited_ attributes should
be visible also...  but they are not, if I try to
get the CSS attribute "x", it is undefined on the
first example though defined in the second.

-Bill
--------------
Bill Haneman
+1 353 1 849 0495

Re: GraphicsConfiguration Lies!!!

[Vincent Hardy <vh...@eng.sun.com>]

Thomas,

Thomas E Deweese wrote:
> 
> Hi all,
> 
>    I'm in the process of verifying my changes and I came across an
> ugly fact.  The Graphics2D.getDeviceConfiguration call shares
> GraphicsConfigurations between 'similar' BufferedImages.
> 
>    This means that the graphics configuration object from
> BufferedImages of different sizes will report the same bounds if the
> run time thinks they are similar.  It also means that they will report
> the same ColorSpace.  I'm not certain when this sharing is broken but
> it definitely isn't broken based on ColorSpace or the size of the
> image.
> 
>    My best solution to this is to introduce a BufferedImage Rendering
> hint that will contain a reference to the BufferedImage that we must
> _religiously_ set when creating a Graphics from a BufferedImage
> (usually via the 'createGraphics' call).
> 
>    This is _slightly_ better than the pre-existing AOI hint since it
> only needs to be set when the Graphics is first created, and never
> needs to be 'updated' through processing.  It also does make a few
> things possible that weren't possible previously, such as doing
> copies, or even rendering directly into the BufferedImage instead of a
> sequence of Graphics2D.drawImage operations (although drawImage tends
> to be quick anyway).
> 
>    Any better ideas, other suggestions?

No better idea or suggestion. If this is more robust than our AOI 
hint, I am all for it.

V.