Hi,
Please review the following fix in JDK9 at your convenience:
Bug : https://bugs.openjdk.java.net/browse/JDK-6294607
Webrev : http://cr.openjdk.java.net/~jdv/6294607/webrev.00/
Issue : When we call ImageWriteParam.getCompressionTypes() for GIF it returns
two compression types
This seems fine to me. Perhaps the test could be reworked to
look for any plugin that reports a duplicate compression type ?
That may be more useful as a test ..
Is this the only plugin that exhibits such duplication ?
-phil.
On 10/04/2016 04:39 AM, Jayathirth D V wrote:
Hi,
Please review th
Hi Jim,
On 10/4/2016 1:05 AM, Jim Graham wrote:
Hi Anton,
Yes, the numbers you are describing are consistent with performing
that standard boilerplate using an origin/translate that is not
exactly at an integer pixel location.
My comments about our mechanisms not allowing for scale-aware
a
On 10/4/16 1:01 PM, Anton Tarasov wrote:
- Simply ask for a large enough integer to make sure you got the entire clip to
fit in it and let the allocator give
you an even larger image. It doesn't matter if you paint into a larger image
(other than having to allocate an extra
row/column on occasi
On 10/4/16 1:01 PM, Anton Tarasov wrote:
Anyway, I roughly tried your approach mentioned in the previous e-mail, but
forcing RM to paint via offscreen
BufferedImage, not volatile (just for a quick check).
It solved the shift issue of the demo listed in 8162350, which is cool. It also
solved the
I wasn't familiar with the test code for this particular case. Is it in a bug
report somewhere?
...jim
On 10/4/16 1:01 PM, Anton Tarasov wrote:
Also, the problem with primitives rendering
(http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-150-percent.png) is
still
On 10/4/2016 11:30 PM, Jim Graham wrote:
I wasn't familiar with the test code for this particular case. Is it
in a bug report somewhere?
Jim, I'm re-attaching it (it was in my first e-mail).
Thanks,
Anton.
...jim
On 10/4/16 1:01 PM, Anton Tarasov wrote:
Also, the problem with p
Probably some methods can be made final also (at least setters and getters)?
because it always a problem when we validate something in the
setter(constructor), but the user returns something unspecified from the
overriden getter.
On 03.10.16 22:51, Brian Burkhalter wrote:
Good point. I think
Hi Phil,
I have verified all plugins only GIF has this duplication problem.
Thanks,
Jay
From: Phil Race
Sent: Tuesday, October 04, 2016 9:54 PM
To: Jayathirth D V; 2d-dev
Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-6294607: GIFWriter returns the same
compression type twice
This see
