From james.graham at oracle.com  Thu May  1 00:44:38 2014
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 30 Apr 2014 17:44:38 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8042103 Deserialization of
 empty java.awt.geom.Path2D will cause an exception
In-Reply-To: <53611C5A.8080303@oracle.com>
References: <53611C5A.8080303@oracle.com>
Message-ID: <536198F6.1050109@oracle.com>

Hi Sergey,

I think the bug is in the readObject routine.  It sets the initial size 
of the arrays based on if the number of segments/coords is "< 0" and it 
sets them to INIT_SIZE or INIT_SIZE*2 accordingly.  Those tests should 
be "< INIT_SIZE(*2)"...

			...jim

On 4/30/14 8:52 AM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 9.
> needRoom() method does not take into account that current array of types
> can be empty. In this case it fails to increase it.
> I handle this case and increase the size of the array by 1 instead of
> INIT_SIZE, because I assume that the user intentionally try to decrease
> memory usage.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8042103
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8042103/webrev.00
>


From Sergey.Bylokhov at oracle.com  Mon May  5 13:30:28 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 05 May 2014 17:30:28 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8042103 Deserialization of
 empty java.awt.geom.Path2D will cause an exception
In-Reply-To: <536198F6.1050109@oracle.com>
References: <53611C5A.8080303@oracle.com> <536198F6.1050109@oracle.com>
Message-ID: <53679274.5090304@oracle.com>

Hi, Jim.
On 01.05.2014 4:44, Jim Graham wrote:
> Hi Sergey,
>
> I think the bug is in the readObject routine.  It sets the initial 
> size of the arrays based on if the number of segments/coords is "< 0" 
> and it sets them to INIT_SIZE or INIT_SIZE*2 accordingly.  Those tests 
> should be "< INIT_SIZE(*2)"...

It was my first thought, but we have an API, which allows to set 
starting value of capacity to 0.
Copy from the bug description:
1.Path2D path = Path2D.Float(int rule, int initialCapacity); while 
initialCapacity is 0
2.Path2D path = Path2D.Double(int rule, int initialCapacity);
3.Path2D path = Path2D.Float(Shape s); while s is empty Path2D
4.Path2D path = Path2D.Float(Shape s, AffineTransform at);
5.Path2D path = Path2D.Double(Shape s);
6.Path2D path = Path2D.Double(Shape s, AffineTransform at);

based on these I assume that empty capacity is correct value, and 
needRoom should be ready for that.

>
>             ...jim
>
> On 4/30/14 8:52 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk 9.
>> needRoom() method does not take into account that current array of types
>> can be empty. In this case it fails to increase it.
>> I handle this case and increase the size of the array by 1 instead of
>> INIT_SIZE, because I assume that the user intentionally try to decrease
>> memory usage.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042103
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8042103/webrev.00
>>


-- 
Best regards, Sergey.



From anthony.petrov at oracle.com  Mon May  5 14:12:21 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 05 May 2014 18:12:21 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> Dont use libjpeg-internal macros in
 splashscreen
In-Reply-To: <536168DC.3000203@oracle.com>
References: <20140430204832.GB2584@redhat.com> <53616753.9060704@oracle.com>
	<536168DC.3000203@oracle.com>
Message-ID: <53679C45.9000303@oracle.com>

The fix looks good to me, too.

--
best regards,
Anthony

On 5/1/2014 1:19 AM, Phil Race wrote:
> Trying again with awt as "To:" rather than bcc: ..
>
> -phil.
>
> On 4/30/2014 2:12 PM, Phil Race wrote:
>> Looks OK to me, but adding awt-dev as splashscreen is owned by AWT.
>>
>> -phil.
>>
>> On 4/30/2014 1:48 PM, Omair Majid wrote:
>>> Hi,
>>>
>>> As indicated in the libjpeg API documentation [1], the standard libjpeg
>>> headers are: jpeglib.h, jerror.h, jconfig.h, jmorecfg.h.
>>>
>>> splashscreen_jpeg.c violates this layering and uses the SIZEOF macro
>>> from the non-public header jinclude.h directly. This macro is a wrapper
>>> over sizeof. The code in splashscreen_jpeg.c already uses sizeof in
>>> multiple places so it seems like it should be okay to use it in some
>>> more.
>>>
>>> The following webrev fixes it:
>>> http://cr.openjdk.java.net/~omajid/webrevs/libjpeg-internal-macros/01/
>>>
>>> One motivation of having this patch is that if/when we add
>>> system-libjpeg support, the header jinclude.h will become inaccessible.
>>>
>>> Thanks,
>>> Omair
>>>
>>> [1] http://svn.code.sf.net/p/libjpeg-turbo/code/trunk/libjpeg.txt
>>>
>>
>


From philip.race at oracle.com  Mon May  5 22:51:45 2014
From: philip.race at oracle.com (Phil Race)
Date: Mon, 05 May 2014 15:51:45 -0700
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8039109 : Fix unchecked and
 raw lint warnings in java.awt
In-Reply-To: <53680F11.9010007@oracle.com>
References: <53618183.2090008@oracle.com> <53666E71.3020308@oracle.com>
	<53680F11.9010007@oracle.com>
Message-ID: <53681601.6060300@oracle.com>

I added 2-dev to have this recorded there since 13/20 files  in the 
webrev are 2D.

I didn't see any thing that's a definite problem although I don't
see what difference the following makes. How does it suppress a warning ?

  Collections.EMPTY_SET  = > Collections.emptySet()

I expect see you added the tmp var here as somewhere to hang the annotation
as I presume it must be on a declaration .. unfortunately a bit yucky tho'

  262             @SuppressWarnings("unchecked")
  263             Vector<TrayIcon> tmp = (Vector<TrayIcon>)AppContext.getAppContext().get(TrayIcon.class);
  264             icons = tmp;

-phil.

On 5/5/2014 3:22 PM, Jim Graham wrote:
> I took a look at the j.a.image and j.a.geom files and everything 
> looked fine.
>
>             ...jim
>
> On 5/4/14 9:44 AM, Joe Darcy wrote:
>> Hello,
>>
>> Any further comments on the latest version
>>
>>       http://cr.openjdk.java.net/~darcy/8039109.3/
>>
>> Thanks,
>>
>> -Joe
>>
>> On 4/30/2014 4:04 PM, Joe Darcy wrote:
>>> Hi R?mi,
>>>
>>>> Hi Joe,
>>>>
>>>> in AWTKeyStroke, instead of
>>>>
>>>> Class<AWTKeyStroke> clazz =
>>>> (Class<AWTKeyStroke>)AppContext.getAppContext().get(AWTKeyStroke.class); 
>>>>
>>>>
>>>> I should have the right type Class<? extends ...> (the class is a
>>>> subclass of AWTKeyStroke) and
>>>> do a classcheck at runtime when the class is extracted instead of 
>>>> later
>>>>
>>>> Class<? extends AWTKeyStroke> clazz =
>>>> ((Class<?>)AppContext.getAppContext().get(AWTKeyStroke.class)).asSubClass(AWTKeyStroke.class); 
>>>>
>>>>
>>>
>>> As I'm not overly familiar with this code and the app context
>>> mechanism, in the context of this lint removal exercise, I'd prefer to
>>> leave the timing of the checks as they are today.
>>>
>>>>
>>>> and I think the second @SuppressWarnings in getCachedStroke() is
>>>> unnecessary.
>>>
>>> Right you are; I've removed the second @SuppressWarnings in the next
>>> iteration of the patch.
>>>
>>>>
>>>>
>>>> in GraphicsEnvironment, the last line of your diff can be simplified,
>>>>
>>>> ge = GraphicsEnvironment.class.cast(geCls.newInstance());
>>>>
>>>> can be written
>>>>
>>>> ge = (GraphicsEnvironment)geCls.newInstance();
>>>>
>>>> which is more readable IMO but will also generate exactly the same
>>>> bytecode as the current implementation.
>>>
>>> Yes, since the type being cast to is unchanging, it is not necessary
>>> to do the cast using core reflection; updated in the next iteration.
>>>
>>>>
>>>>
>>>> in KeyboardFocusManager,
>>>>
>>>> private Set<AWTKeyStroke>[] defaultFocusTraversalKeys = new Set[4];
>>>>
>>>> should be
>>>>
>>>> private Set<AWTKeyStroke>[] defaultFocusTraversalKeys = new Set<?>[4];
>>>>
>>>> so @SuppressWarnings("rawtypes") is not needed.
>>>
>>> Actually, javac objects to the code you've proposed:
>>>
>>> src/share/classes/java/awt/KeyboardFocusManager.java:352: error:
>>> incompatible types: Set<?>[] cannot be converted to Set<AWTKeyStroke>[]
>>>     private Set<AWTKeyStroke>[] defaultFocusTraversalKeys = new
>>> Set<?>[4];
>>>
>>> (IIRC, I ran into this when I was first putting the changeset 
>>> together.)
>>>
>>>>
>>>>
>>>> in DragGestureEvent, the newEvents should be a List<? extends
>>>> InputEvent>,
>>>> and @SuppressWarnings("rawtypes") should be a
>>>> @SuppressWarnings("unchecked")
>>>
>>> For the purposes of this clean up effort, I'm not eager to take on
>>> more extensive updates to DragGestureEvent than adding the one
>>> @SuppressWarnings. I would encourage the awt team to consider the
>>> update you've suggested.
>>>
>>>>
>>>> in RenderableImageOp,
>>>> getRenderableSources() should return a Vector of RenderableImage,
>>>>
>>>>        public Vector<RenderableImage> getSources() {
>>>>           getRenderableSources();
>>>>        }
>>>>           private Vector<RenderableImage> getRenderableSources() {
>>>>           Vector<RenderableImage sources = null;
>>>
>>> Petr made the same observation and I've addressed that in the second
>>> iteration of the patch:
>>>
>>>     http://cr.openjdk.java.net/~darcy/8039109.2/
>>>
>>>>
>>>> all other modifications are OK for me.
>>>
>>> Newest iteration at:
>>>
>>>     http://cr.openjdk.java.net/~darcy/8039109.3/
>>>
>>> Thanks for the review,
>>>
>>> -Joe
>>>
>>



From joe.darcy at oracle.com  Mon May  5 23:00:39 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 05 May 2014 16:00:39 -0700
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8039109 : Fix unchecked and
 raw lint warnings in java.awt
In-Reply-To: <53681601.6060300@oracle.com>
References: <53618183.2090008@oracle.com> <53666E71.3020308@oracle.com>
	<53680F11.9010007@oracle.com> <53681601.6060300@oracle.com>
Message-ID: <53681817.7050804@oracle.com>

Hi Phil,

On 5/5/2014 3:51 PM, Phil Race wrote:
> I added 2-dev to have this recorded there since 13/20 files  in the 
> webrev are 2D.
>
> I didn't see any thing that's a definite problem although I don't
> see what difference the following makes. How does it suppress a warning ?
>
>  Collections.EMPTY_SET  = > Collections.emptySet()

Collections.emptySet() is a generic method and when it is used, javac 
can infer a site-specific value of the type parameter, inferring a 
Set<String> instead of a Set<Integer>, etc. In contrast, the field 
Collections.EMPTY_SET only has a single type. However, calling 
Collections.emptySet() still uses a single shared empty set instance 
across types.

>
> I expect see you added the tmp var here as somewhere to hang the 
> annotation
> as I presume it must be on a declaration .. unfortunately a bit yucky 
> tho'
>
>  262             @SuppressWarnings("unchecked")
>  263             Vector<TrayIcon> tmp = 
> (Vector<TrayIcon>)AppContext.getAppContext().get(TrayIcon.class);
>  264             icons = tmp;

For this sort of change, annotation must be applied to declarations. If 
there is not a local variable, the condition for the entire method has 
to be suppressed, which is usually a worse trade-off.

Thanks,

-Joe

>
> -phil.
>
> On 5/5/2014 3:22 PM, Jim Graham wrote:
>> I took a look at the j.a.image and j.a.geom files and everything 
>> looked fine.
>>
>>             ...jim
>>
>> On 5/4/14 9:44 AM, Joe Darcy wrote:
>>> Hello,
>>>
>>> Any further comments on the latest version
>>>
>>>       http://cr.openjdk.java.net/~darcy/8039109.3/
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> On 4/30/2014 4:04 PM, Joe Darcy wrote:
>>>> Hi R?mi,
>>>>
>>>>> Hi Joe,
>>>>>
>>>>> in AWTKeyStroke, instead of
>>>>>
>>>>> Class<AWTKeyStroke> clazz =
>>>>> (Class<AWTKeyStroke>)AppContext.getAppContext().get(AWTKeyStroke.class); 
>>>>>
>>>>>
>>>>> I should have the right type Class<? extends ...> (the class is a
>>>>> subclass of AWTKeyStroke) and
>>>>> do a classcheck at runtime when the class is extracted instead of 
>>>>> later
>>>>>
>>>>> Class<? extends AWTKeyStroke> clazz =
>>>>> ((Class<?>)AppContext.getAppContext().get(AWTKeyStroke.class)).asSubClass(AWTKeyStroke.class); 
>>>>>
>>>>>
>>>>
>>>> As I'm not overly familiar with this code and the app context
>>>> mechanism, in the context of this lint removal exercise, I'd prefer to
>>>> leave the timing of the checks as they are today.
>>>>
>>>>>
>>>>> and I think the second @SuppressWarnings in getCachedStroke() is
>>>>> unnecessary.
>>>>
>>>> Right you are; I've removed the second @SuppressWarnings in the next
>>>> iteration of the patch.
>>>>
>>>>>
>>>>>
>>>>> in GraphicsEnvironment, the last line of your diff can be simplified,
>>>>>
>>>>> ge = GraphicsEnvironment.class.cast(geCls.newInstance());
>>>>>
>>>>> can be written
>>>>>
>>>>> ge = (GraphicsEnvironment)geCls.newInstance();
>>>>>
>>>>> which is more readable IMO but will also generate exactly the same
>>>>> bytecode as the current implementation.
>>>>
>>>> Yes, since the type being cast to is unchanging, it is not necessary
>>>> to do the cast using core reflection; updated in the next iteration.
>>>>
>>>>>
>>>>>
>>>>> in KeyboardFocusManager,
>>>>>
>>>>> private Set<AWTKeyStroke>[] defaultFocusTraversalKeys = new Set[4];
>>>>>
>>>>> should be
>>>>>
>>>>> private Set<AWTKeyStroke>[] defaultFocusTraversalKeys = new 
>>>>> Set<?>[4];
>>>>>
>>>>> so @SuppressWarnings("rawtypes") is not needed.
>>>>
>>>> Actually, javac objects to the code you've proposed:
>>>>
>>>> src/share/classes/java/awt/KeyboardFocusManager.java:352: error:
>>>> incompatible types: Set<?>[] cannot be converted to 
>>>> Set<AWTKeyStroke>[]
>>>>     private Set<AWTKeyStroke>[] defaultFocusTraversalKeys = new
>>>> Set<?>[4];
>>>>
>>>> (IIRC, I ran into this when I was first putting the changeset 
>>>> together.)
>>>>
>>>>>
>>>>>
>>>>> in DragGestureEvent, the newEvents should be a List<? extends
>>>>> InputEvent>,
>>>>> and @SuppressWarnings("rawtypes") should be a
>>>>> @SuppressWarnings("unchecked")
>>>>
>>>> For the purposes of this clean up effort, I'm not eager to take on
>>>> more extensive updates to DragGestureEvent than adding the one
>>>> @SuppressWarnings. I would encourage the awt team to consider the
>>>> update you've suggested.
>>>>
>>>>>
>>>>> in RenderableImageOp,
>>>>> getRenderableSources() should return a Vector of RenderableImage,
>>>>>
>>>>>        public Vector<RenderableImage> getSources() {
>>>>>           getRenderableSources();
>>>>>        }
>>>>>           private Vector<RenderableImage> getRenderableSources() {
>>>>>           Vector<RenderableImage sources = null;
>>>>
>>>> Petr made the same observation and I've addressed that in the second
>>>> iteration of the patch:
>>>>
>>>>     http://cr.openjdk.java.net/~darcy/8039109.2/
>>>>
>>>>>
>>>>> all other modifications are OK for me.
>>>>
>>>> Newest iteration at:
>>>>
>>>>     http://cr.openjdk.java.net/~darcy/8039109.3/
>>>>
>>>> Thanks for the review,
>>>>
>>>> -Joe
>>>>
>>>
>



From philip.race at oracle.com  Wed May  7 18:26:21 2014
From: philip.race at oracle.com (Phil Race)
Date: Wed, 07 May 2014 11:26:21 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in
 finding class implementing sun.java2d.pipe. RenderingEngine
Message-ID: <536A7ACD.8040507@oracle.com>


https://bugs.openjdk.java.net/browse/JDK-8038875
http://cr.openjdk.java.net/~prr/8038875/

This is in support of modularisation (ie jigsaw). After the fix 
alternate implementations
are loaded using Class.forName() as specified by the system property
sun.java2d.renderer. Note that only the built-in ones are actually supported
The mechanism is just for testing.

BTW since it happens that Oracle JDK includes the pisces classes as well
as the closed source ductus I note that its possible to compare the 
performance
or other characteristics easily in a closed build which has both by 
specifying
to use pisces instead of ductus.

There's no regression test associated with this. I tested open & closed 
builds
(created for all platforms) with standard demos.

-phil.


From Sergey.Bylokhov at oracle.com  Wed May  7 19:10:46 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 07 May 2014 23:10:46 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8041129 [OGL] surface->sw
 blit is extremely slow
In-Reply-To: <535FFC8D.2010300@oracle.com>
References: <53552890.4060108@oracle.com> <5355309C.1000402@oracle.com>
	<535826BD.6060106@oracle.com> <53585132.6080301@oracle.com>
	<535FFC8D.2010300@oracle.com>
Message-ID: <536A8536.6010902@oracle.com>

Hello, Jim.
I have started to implement the second solution, and a prototype looks 
good to me.
But I got a problem with an appropriate test, do I understand correctly 
that there is no way to understand is transparent volatile image 
premultiply alpha or not?
Because if I draw a transparent volatile image to the 
bufferedImage_argb_pre, i get completely different results from getRGB() 
on different pipelines.

For example what is correct value in the attached test:
2000080 - when I draw directly to BI_ARGB_PRE, (on my opengl prototype i 
get the same value when draw via transparent VI).
2008080 - when I draw to BI_ARGB_PRE via transparent VI(on d3d and gdi)?
Who is right?

On 29.04.2014 23:25, Sergey Bylokhov wrote:
> Hello, Jim.
> I have started working with another issue, which touches the same code.
> https://bugs.openjdk.java.net/browse/JDK-8017626
> The problem is clear our surface in opengl contains data in 
> premultiplied mode[1][2], but we have only one surface->sw loop in 
> opengl which is:
>             new OGLSurfaceToSwBlit(SurfaceType.IntArgb, 
> OGLSurfaceData.PF_INT_ARGB);
>
> Note that both parameters are argb. As you remember this blit is 
> implemented via glReadPixels which transfer data without modification. 
> So we are in trouble in case of translucent volatile image, when alpha 
> != 1.0.
> I see two possible solutions:
>  1. Change the type of the surface->sw blit to _pre and change all 
> related code to fail back to this blit, other draws will be done via 
> intermediate backbuffer.
>  2. Restore the colors during the flip operation for case of argb blit 
> + create new blit to cover argb_pre(it will have current implementation).
>
> What do you think?
>
> [1] 
> http://mail.openjdk.java.net/pipermail/2d-dev/2013-October/003783.html
> [2] https://bugs.openjdk.java.net/browse/JDK-8017626
>
> On 4/24/14 3:48 AM, Jim Graham wrote:
>> The benchmark spreads look much better and the code looks good, but I 
>> worry that we are being inconsistent in whether or not we set the 
>> SKIP_ values.  This function sets them back to 0 when done, but can 
>> we assume that about all code that uses these methods?
>>
>>             ...jim
>>
>> On 4/23/14 1:46 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review an updated version of the fix.
>>>
>>> Bugs which were found in the previous version:
>>>   - Destination vertical offset was
>>> ignored(j2d_glPixelStorei(GL_PACK_SKIP_ROWS, dsty)) now we take it into
>>> account using PtrAddBytes(pDst, dsty * dstInfo.scanStride)
>>>   - srcy wasn't recalculated for the correct direction
>>>   - In the first version of the fix scanStride was used for iteration
>>> over destination memory and as a parameter of memcpy. This is 
>>> incorrect,
>>> because we should flip only a drawable part of destination. Now memcpy
>>> uses pixelStride * width
>>>
>>> Because no one of these problems were not found by the tests a new ones
>>> were added.
>>>
>>> I filed another issue related to the surface->sw blit, opengl and d3d
>>> ignore the clip of the destination JDK-8041644
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041129
>>> Webrev can be found at:
>>> http://cr.openjdk.java.net/~serb/8041129/webrev.03/webrev
>>>
>>> Benchmarks: to decrease the spread I increased the time per test from
>>> 2500 ms to 25 seconds
>>> =======================================================================
>>> Windows 7 x64, lenovo T410, nvidia NVS 3100M
>>> http://cr.openjdk.java.net/~serb/8041129/webrev.03/J2DBench/results-nvidia-windows.txt 
>>>
>>>
>>> Summary:
>>>    OGL-base-nvidia-windows:
>>>      Number of tests:  10
>>>      Overall average:  1943.4318817726798
>>>      Best spread:      0.36% variance
>>>      Worst spread:     4.16% variance
>>>      (Basis for results comparison)
>>>
>>>    OGL-fix2-nvidia-windows:
>>>      Number of tests:  10
>>>      Overall average:  181165.51031119752
>>>      Best spread:      0.35% variance
>>>      Worst spread:     2.57% variance
>>>      Comparison to basis:
>>>        Best result:      19142.77% of basis
>>>        Worst result:     97.75% of basis
>>>        Number of wins:   8
>>>        Number of ties:   2
>>>        Number of losses: 0
>>>
>>>    D3D-base-nvidia-windows:
>>>      Number of tests:  10
>>>      Overall average:  30046.475416066532
>>>      Best spread:      0.05% variance
>>>      Worst spread:     4.56% variance
>>>      Comparison to basis:
>>>        Best result:      13660.29% of basis
>>>        Worst result:     9.34% of basis
>>>        Number of wins:   6
>>>        Number of ties:   1
>>>        Number of losses: 3
>>>
>>> =======================================================================
>>> OSX 10.8.5, macbook pro retina, nvidia GeForce GT 650M 1024 MB
>>> http://cr.openjdk.java.net/~serb/8041129/webrev.03/J2DBench/results-nvidia-osx.txt 
>>>
>>>
>>> Summary:
>>>    OGL-base-nvidia-osx:
>>>      Number of tests:  10
>>>      Overall average:  719.3548194040994
>>>      Best spread:      0.1% variance
>>>      Worst spread:     4.09% variance
>>>      (Basis for results comparison)
>>>
>>>    OGL-fix2-nvidia-osx:
>>>      Number of tests:  10
>>>      Overall average:  11050.087724732544
>>>      Best spread:      0.11% variance
>>>      Worst spread:     3.54% variance
>>>      Comparison to basis:
>>>        Best result:      4713.13% of basis
>>>        Worst result:     175.51% of basis
>>>        Number of wins:   10
>>>        Number of ties:   0
>>>        Number of losses: 0
>>>
>>> =======================================================================
>>> OSX 10.8.5, macbook pro retina, Intel HD Graphics 4000
>>> http://cr.openjdk.java.net/~serb/8041129/webrev.03/J2DBench/results-intel-osx.txt 
>>>
>>>
>>> Summary:
>>>    OGL-base-intel-osx:
>>>      Number of tests:  10
>>>      Overall average:  3958.228739879219
>>>      Best spread:      0.4% variance
>>>      Worst spread:     8.09% variance
>>>      (Basis for results comparison)
>>>
>>>    OGL-fix2-intel-osx:
>>>      Number of tests:  10
>>>      Overall average:  10098.091503211792
>>>      Best spread:      0.35% variance
>>>      Worst spread:     17.97% variance
>>>      Comparison to basis:
>>>        Best result:      477.95% of basis
>>>        Worst result:     105.42% of basis
>>>        Number of wins:   10
>>>        Number of ties:   0
>>>        Number of losses: 0
>>>
>>> On 21.04.2014 18:52, Andrew Brygin wrote:
>>>> Hello Sergey,
>>>>
>>>>  the fast path skips j2d_glPixelStorei(GL_PACK_SKIP_ROWS, dsty).
>>>>
>>>>  Could you please clarify why? I think that initial value of dsty
>>>>  (dstInfo.bounds.y1) can be non-zero, and this operation
>>>>  seem to be required...
>>>>
>>>> Thanks,
>>>> Andrew
>>>>
>>>> On 4/21/2014 6:17 PM, Sergey Bylokhov wrote:
>>>>> Hello.
>>>>> Please review the fix for jdk 9.
>>>>> This issue initially was found in FX[1], and there is description of
>>>>> this problem.
>>>>> In the fix the flip operation is done using memcpy after the whole
>>>>> image was moved from gpu to cpu.
>>>>>
>>>>> [1] https://javafx-jira.kenai.com/browse/RT-30035
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041129
>>>>> Webrev can be found at:
>>>>> http://cr.openjdk.java.net/~serb/8041129/webrev.01
>>>>>
>>>>> Benchmarks:
>>>>> ==========================================================
>>>>> Windows 7 x64, lenovo T410, nvidia NVS 3100M
>>>>> http://cr.openjdk.java.net/~serb/8041129/J2DBench/results
>>>>> base ogl vs base d3d vs fixed ogl
>>>>> Summary:
>>>>>   OGL-base-nvidia-windows:
>>>>>     Number of tests:  10
>>>>>     Overall average:  2239.9261323744704
>>>>>     Best spread:      1.72% variance
>>>>>     Worst spread:     88.61% variance
>>>>>     (Basis for results comparison)
>>>>>
>>>>>   OGL-fix-nvidia-windows:
>>>>>     Number of tests:  10
>>>>>     Overall average:  166667.93024226945
>>>>>     Best spread:      1.23% variance
>>>>>     Worst spread:     66.19% variance
>>>>>     Comparison to basis:
>>>>>       Best result:      13719.74% of basis
>>>>>       Worst result:     97.17% of basis
>>>>>       Number of wins:   8
>>>>>       Number of ties:   1
>>>>>       Number of losses: 1
>>>>>
>>>>>   D3D-base-nvidia-windows:
>>>>>     Number of tests:  10
>>>>>     Overall average:  29755.21747098
>>>>>     Best spread:      0.34% variance
>>>>>     Worst spread:     61.12% variance
>>>>>     Comparison to basis:
>>>>>       Best result:      12068.41% of basis
>>>>>       Worst result:     8.05% of basis
>>>>>       Number of wins:   6
>>>>>       Number of ties:   0
>>>>>       Number of losses: 4
>>>>>
>>>>> ==========================================================
>>>>> OSX 10.8.5, macbook pro retina, nvidia GeForce GT 650M 1024 MB
>>>>> http://cr.openjdk.java.net/~serb/8041129/J2DBench-osx/results-nvidia-osx.txt 
>>>>>
>>>>>
>>>>> Summary:
>>>>>   OGL-base-nvidia-osx:
>>>>>     Number of tests:  10
>>>>>     Overall average:  710.7070782394075
>>>>>     Best spread:      0.73% variance
>>>>>     Worst spread:     5.72% variance
>>>>>     (Basis for results comparison)
>>>>>
>>>>>   OGL-fix-nvidia-osx:
>>>>>     Number of tests:  10
>>>>>     Overall average:  11032.674771293528
>>>>>     Best spread:      0.62% variance
>>>>>     Worst spread:     8.14% variance
>>>>>     Comparison to basis:
>>>>>       Best result:      4659.95% of basis
>>>>>       Worst result:     169.66% of basis
>>>>>       Number of wins:   10
>>>>>       Number of ties:   0
>>>>>       Number of losses: 0
>>>>>
>>>>> ==========================================================
>>>>> OSX 10.8.5, macbook pro retina, Intel HD Graphics 4000
>>>>> http://cr.openjdk.java.net/~serb/8041129/J2DBench-osx/results-intel-osx.txt 
>>>>>
>>>>>
>>>>> Summary:
>>>>>   OGL-base-intel-osx:
>>>>>     Number of tests:  10
>>>>>     Overall average:  3993.5366388495613
>>>>>     Best spread:      0.65% variance
>>>>>     Worst spread:     20.91% variance
>>>>>     (Basis for results comparison)
>>>>>
>>>>>   OGL-fix-intel-osx:
>>>>>     Number of tests:  10
>>>>>     Overall average:  10197.361705976433
>>>>>     Best spread:      0.72% variance
>>>>>     Worst spread:     38.4% variance
>>>>>     Comparison to basis:
>>>>>       Best result:      491.0% of basis
>>>>>       Worst result:     108.61% of basis
>>>>>       Number of wins:   10
>>>>>       Number of ties:   0
>>>>>       Number of losses: 0
>>>>>
>>>>> Thanks to Anton for the initial version of the fix.
>>>>>
>>>>
>>>
>>>
>
>


-- 
Best regards, Sergey.

-------------- next part --------------
import java.awt.AlphaComposite;
import java.awt.Color;
import java.awt.Graphics2D;
import java.awt.GraphicsConfiguration;
import java.awt.GraphicsEnvironment;
import java.awt.Image;
import java.awt.image.BufferedImage;
import java.awt.image.VolatileImage;

import static java.awt.image.BufferedImage.TRANSLUCENT;
import static java.awt.image.BufferedImage.TYPE_INT_ARGB_PRE;

public final class IncorrectAlphaPreSurface2SW2 {

    private static final int S = 1;

    public static void main(final String[] args) {
        GraphicsEnvironment ge = GraphicsEnvironment
                .getLocalGraphicsEnvironment();
        GraphicsConfiguration gc = ge.getDefaultScreenDevice()
                                     .getDefaultConfiguration();

        BufferedImage bi = new BufferedImage(S, S, TYPE_INT_ARGB_PRE);
        BufferedImage gold = new BufferedImage(S, S, TYPE_INT_ARGB_PRE);
        VolatileImage vi = gc.createCompatibleVolatileImage(S, S, TRANSLUCENT);
        fill(gold);
        fill(vi);
        Graphics2D big = bi.createGraphics();
        big.setComposite(AlphaComposite.Src);
        big.drawImage(vi, 0, 0, S, S, null);
        big.dispose();
        System.out.printf("gold.getRGB(0,0) = %1$h\n", gold.getRGB(0, 0));
        System.out.printf("bi.getRGB(0,0) = %1$h\n", bi.getRGB(0, 0));
    }

    private static void fill(final Image image) {
        Graphics2D graphics = (Graphics2D) image.getGraphics();
        graphics.setComposite(AlphaComposite.Src);
        graphics.setColor(new Color(23, 127, 189, 2));
        graphics.fillRect(0, 0, S, S);
        graphics.dispose();
    }
}

From mandy.chung at oracle.com  Wed May  7 19:26:41 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 07 May 2014 12:26:41 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in
 finding class implementing sun.java2d.pipe. RenderingEngine
In-Reply-To: <536A7ACD.8040507@oracle.com>
References: <536A7ACD.8040507@oracle.com>
Message-ID: <536A88F1.7020206@oracle.com>

On 5/7/2014 11:26 AM, Phil Race wrote:
>
> https://bugs.openjdk.java.net/browse/JDK-8038875
> http://cr.openjdk.java.net/~prr/8038875/
>

Thanks for taking this on.  I have some minor comments:

line 129: if sun.java2d.renderer is set,  it finds a custom 
RenderingEngine from the bootclasspath (as the current class loader is 
the bootstrap class loader).   On the other hand, in the original 
implementation, the service loader loads from the extension class 
loader.  I'm not proposing to use a different class loader since this is 
not a supported way to plugin a custom rendering engine. Just to mention 
it to call out the difference.

You may consider to use the 3-arg version of Class.forName and not to 
initialize the class.  This is called within a doPrivileged block and 
it's generally a good convention to invoke the class initialization of 
the specified class (from the system property) outside the doPrivileged 
block.  Static analysis tool may consider catching the 1-arg version of 
Class.forName and flag it as a warning.

line 134-140: PiscesRenderingEngine is always present, right?  Would it 
be better just to return "new PiscesRenderingEngine()"?

otherwise, looks good.
Mandy

> This is in support of modularisation (ie jigsaw). After the fix 
> alternate implementations
> are loaded using Class.forName() as specified by the system property
> sun.java2d.renderer. Note that only the built-in ones are actually 
> supported
> The mechanism is just for testing.
>
> BTW since it happens that Oracle JDK includes the pisces classes as well
> as the closed source ductus I note that its possible to compare the 
> performance
> or other characteristics easily in a closed build which has both by 
> specifying
> to use pisces instead of ductus.
>
> There's no regression test associated with this. I tested open & 
> closed builds
> (created for all platforms) with standard demos.
>
> -phil.



From philip.race at oracle.com  Wed May  7 19:40:00 2014
From: philip.race at oracle.com (Phil Race)
Date: Wed, 07 May 2014 12:40:00 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in
 finding class implementing sun.java2d.pipe. RenderingEngine
In-Reply-To: <536A88F1.7020206@oracle.com>
References: <536A7ACD.8040507@oracle.com> <536A88F1.7020206@oracle.com>
Message-ID: <536A8C10.7010208@oracle.com>

On 5/7/14 12:26 PM, Mandy Chung wrote:
> On 5/7/2014 11:26 AM, Phil Race wrote:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8038875
>> http://cr.openjdk.java.net/~prr/8038875/
>>
>
> Thanks for taking this on.  I have some minor comments:
>
> line 129: if sun.java2d.renderer is set,  it finds a custom 
> RenderingEngine from the bootclasspath (as the current class loader is 
> the bootstrap class loader).   On the other hand, in the original 
> implementation, the service loader loads from the extension class 
> loader.  I'm not proposing to use a different class loader since this 
> is not a supported way to plugin a custom rendering engine. Just to 
> mention it to call out the difference.

Probably it should always have been the bootstrap class loader
since this is a test mechanism for replacing an internal body of code.
But permissions are the same in both cases, aren't they ?

>
> You may consider to use the 3-arg version of Class.forName and not to 
> initialize the class.  This is called within a doPrivileged block and 
> it's generally a good convention to invoke the class initialization of 
> the specified class (from the system property) outside the 
> doPrivileged block.  Static analysis tool may consider catching the 
> 1-arg version of Class.forName and flag it as a warning.
I suppose could do that but I'm not sure how much it matters besides 
shutting up a tool
given that
a) its going to be on the bootclasspath
b) its got to be specified by a property that can only be set on the 
command line
or privileged code
>
> line 134-140: PiscesRenderingEngine is always present, right? Would it 
> be better just to return "new PiscesRenderingEngine()"?
It looked as if it is always there, although I'm not sure if that was 
intended or is just
the way the build happened to work. So I'd prefer to leave it as  ..

-phil.

>
> otherwise, looks good.
> Mandy
>
>> This is in support of modularisation (ie jigsaw). After the fix 
>> alternate implementations
>> are loaded using Class.forName() as specified by the system property
>> sun.java2d.renderer. Note that only the built-in ones are actually 
>> supported
>> The mechanism is just for testing.
>>
>> BTW since it happens that Oracle JDK includes the pisces classes as well
>> as the closed source ductus I note that its possible to compare the 
>> performance
>> or other characteristics easily in a closed build which has both by 
>> specifying
>> to use pisces instead of ductus.
>>
>> There's no regression test associated with this. I tested open & 
>> closed builds
>> (created for all platforms) with standard demos.
>>
>> -phil.
>



From mandy.chung at oracle.com  Wed May  7 19:40:42 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 07 May 2014 12:40:42 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in
 finding class implementing sun.java2d.pipe. RenderingEngine
In-Reply-To: <536A88F1.7020206@oracle.com>
References: <536A7ACD.8040507@oracle.com> <536A88F1.7020206@oracle.com>
Message-ID: <536A8C3A.6070702@oracle.com>

On 5/7/2014 12:26 PM, Mandy Chung wrote:
> On 5/7/2014 11:26 AM, Phil Race wrote:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8038875
>> http://cr.openjdk.java.net/~prr/8038875/
>>
>
> Thanks for taking this on.  I have some minor comments:
>
> line 129: if sun.java2d.renderer is set,  it finds a custom 
> RenderingEngine from the bootclasspath (as the current class loader is 
> the bootstrap class loader).   On the other hand, in the original 
> implementation, the service loader loads from the extension class 
> loader.  I'm not proposing to use a different class loader since this 
> is not a supported way to plugin a custom rendering engine. Just to 
> mention it to call out the difference.
>
> You may consider to use the 3-arg version of Class.forName and not to 
> initialize the class.  This is called within a doPrivileged block and 
> it's generally a good convention to invoke the class initialization of 
> the specified class (from the system property) outside the 
> doPrivileged block.  Static analysis tool may consider catching the 
> 1-arg version of Class.forName and flag it as a warning.

The class will need to be initialized in the newInstance() call. The 
above comment might not apply.   Is the doPrivileged block needed for 
the RenderingEngine instantiation?  I was wondering if it was needed for 
the service loader only or not.

Mandy

>
> line 134-140: PiscesRenderingEngine is always present, right? Would it 
> be better just to return "new PiscesRenderingEngine()"?
>
> otherwise, looks good.
> Mandy
>
>> This is in support of modularisation (ie jigsaw). After the fix 
>> alternate implementations
>> are loaded using Class.forName() as specified by the system property
>> sun.java2d.renderer. Note that only the built-in ones are actually 
>> supported
>> The mechanism is just for testing.
>>
>> BTW since it happens that Oracle JDK includes the pisces classes as well
>> as the closed source ductus I note that its possible to compare the 
>> performance
>> or other characteristics easily in a closed build which has both by 
>> specifying
>> to use pisces instead of ductus.
>>
>> There's no regression test associated with this. I tested open & 
>> closed builds
>> (created for all platforms) with standard demos.
>>
>> -phil.
>



From mandy.chung at oracle.com  Wed May  7 20:16:09 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 07 May 2014 13:16:09 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in
 finding class implementing sun.java2d.pipe. RenderingEngine
In-Reply-To: <536A8C10.7010208@oracle.com>
References: <536A7ACD.8040507@oracle.com> <536A88F1.7020206@oracle.com>
	<536A8C10.7010208@oracle.com>
Message-ID: <536A9489.7090306@oracle.com>


On 5/7/2014 12:40 PM, Phil Race wrote:
> On 5/7/14 12:26 PM, Mandy Chung wrote:
>> On 5/7/2014 11:26 AM, Phil Race wrote:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8038875
>>> http://cr.openjdk.java.net/~prr/8038875/
>>>
>>
>> Thanks for taking this on.  I have some minor comments:
>>
>> line 129: if sun.java2d.renderer is set,  it finds a custom 
>> RenderingEngine from the bootclasspath (as the current class loader 
>> is the bootstrap class loader).   On the other hand, in the original 
>> implementation, the service loader loads from the extension class 
>> loader.  I'm not proposing to use a different class loader since this 
>> is not a supported way to plugin a custom rendering engine. Just to 
>> mention it to call out the difference.
>
> Probably it should always have been the bootstrap class loader
> since this is a test mechanism for replacing an internal body of code.

Okay good.

> But permissions are the same in both cases, aren't they ?

yes.  The only difference is that previously someone could put the 
service provider implementation into the extension directory that will 
be loaded.   As this is a test mechanism, what you have is good.

>
>>
>> You may consider to use the 3-arg version of Class.forName and not to 
>> initialize the class.  This is called within a doPrivileged block and 
>> it's generally a good convention to invoke the class initialization 
>> of the specified class (from the system property) outside the 
>> doPrivileged block.  Static analysis tool may consider catching the 
>> 1-arg version of Class.forName and flag it as a warning.
> I suppose could do that but I'm not sure how much it matters besides 
> shutting up a tool
> given that
> a) its going to be on the bootclasspath
> b) its got to be specified by a property that can only be set on the 
> command line
> or privileged code

Agree this doesn't matter much.   As I replied in another email, it may 
be good to follow up if the doPrivileged block is needed or not after 
this change.

>>
>> line 134-140: PiscesRenderingEngine is always present, right? Would 
>> it be better just to return "new PiscesRenderingEngine()"?
> It looked as if it is always there, although I'm not sure if that was 
> intended or is just
> the way the build happened to work. So I'd prefer to leave it as ..

That's fine and I understand.  I generally recommend not using 
reflection unless it's necessary :)

Mandy


From philip.race at oracle.com  Wed May  7 20:26:48 2014
From: philip.race at oracle.com (Phil Race)
Date: Wed, 07 May 2014 13:26:48 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in
 finding class implementing sun.java2d.pipe. RenderingEngine
In-Reply-To: <536A8C3A.6070702@oracle.com>
References: <536A7ACD.8040507@oracle.com> <536A88F1.7020206@oracle.com>
	<536A8C3A.6070702@oracle.com>
Message-ID: <536A9708.7090005@oracle.com>

On 5/7/14 12:40 PM, Mandy Chung wrote:
>
>>
>> You may consider to use the 3-arg version of Class.forName and not to 
>> initialize the class.  This is called within a doPrivileged block and 
>> it's generally a good convention to invoke the class initialization 
>> of the specified class (from the system property) outside the 
>> doPrivileged block.  Static analysis tool may consider catching the 
>> 1-arg version of Class.forName and flag it as a warning.
>
> The class will need to be initialized in the newInstance() call. The 
> above comment might not apply.   Is the doPrivileged block needed for 
> the RenderingEngine instantiation?  I was wondering if it was needed 
> for the service loader only or not.
>
>
Good question. A privilege is obviously needed for the getProperty but
the rest may not need it .. I can try removing it and see if anything 
breaks.

-phil.



From philip.race at oracle.com  Wed May  7 21:57:39 2014
From: philip.race at oracle.com (Phil Race)
Date: Wed, 07 May 2014 14:57:39 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in
 finding class implementing sun.java2d.pipe. RenderingEngine
In-Reply-To: <536A9708.7090005@oracle.com>
References: <536A7ACD.8040507@oracle.com> <536A88F1.7020206@oracle.com>
	<536A8C3A.6070702@oracle.com> <536A9708.7090005@oracle.com>
Message-ID: <536AAC53.7090704@oracle.com>

I did away with the doPrivileged and it seems fine ...
http://cr.openjdk.java.net/~prr/8038875.1/

-phil.

On 05/07/2014 01:26 PM, Phil Race wrote:
> On 5/7/14 12:40 PM, Mandy Chung wrote:
>>
>>>
>>> You may consider to use the 3-arg version of Class.forName and not 
>>> to initialize the class.  This is called within a doPrivileged block 
>>> and it's generally a good convention to invoke the class 
>>> initialization of the specified class (from the system property) 
>>> outside the doPrivileged block.  Static analysis tool may consider 
>>> catching the 1-arg version of Class.forName and flag it as a warning.
>>
>> The class will need to be initialized in the newInstance() call. The 
>> above comment might not apply.   Is the doPrivileged block needed for 
>> the RenderingEngine instantiation?  I was wondering if it was needed 
>> for the service loader only or not.
>>
>>
> Good question. A privilege is obviously needed for the getProperty but
> the rest may not need it .. I can try removing it and see if anything 
> breaks.
>
> -phil.
>



From mandy.chung at oracle.com  Wed May  7 22:12:28 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 07 May 2014 15:12:28 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in
 finding class implementing sun.java2d.pipe. RenderingEngine
In-Reply-To: <536AAC53.7090704@oracle.com>
References: <536A7ACD.8040507@oracle.com> <536A88F1.7020206@oracle.com>
	<536A8C3A.6070702@oracle.com> <536A9708.7090005@oracle.com>
	<536AAC53.7090704@oracle.com>
Message-ID: <536AAFCC.9080505@oracle.com>


On 5/7/2014 2:57 PM, Phil Race wrote:
> I did away with the doPrivileged and it seems fine ...
> http://cr.openjdk.java.net/~prr/8038875.1/

I'm glad that the doPrivileged block is reduced just to 
System.getProperty.  Looks good while I still think it's worth 
considering replacing Class.forName(pisecesREClass) with new 
PiscesRenderingEngine() that will further simplify it.  I'll leave it 
for you and Jim to decide.

thanks
Mandy


From james.graham at oracle.com  Thu May  8 00:18:24 2014
From: james.graham at oracle.com (Jim Graham)
Date: Wed, 07 May 2014 17:18:24 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in
 finding class implementing sun.java2d.pipe. RenderingEngine
In-Reply-To: <536A7ACD.8040507@oracle.com>
References: <536A7ACD.8040507@oracle.com>
Message-ID: <536ACD50.7030308@oracle.com>

If they specify something on the command line, and that doesn't exist, 
then we end up with Pisces even if Ductus is available.  Is that 
intentional?

Also, why the switch from "getProperty(, default)" to the basic 
getProperty() and manually applying the default?

			...jim

On 5/7/14 11:26 AM, Phil Race wrote:
>
> https://bugs.openjdk.java.net/browse/JDK-8038875
> http://cr.openjdk.java.net/~prr/8038875/
>
> This is in support of modularisation (ie jigsaw). After the fix
> alternate implementations
> are loaded using Class.forName() as specified by the system property
> sun.java2d.renderer. Note that only the built-in ones are actually
> supported
> The mechanism is just for testing.
>
> BTW since it happens that Oracle JDK includes the pisces classes as well
> as the closed source ductus I note that its possible to compare the
> performance
> or other characteristics easily in a closed build which has both by
> specifying
> to use pisces instead of ductus.
>
> There's no regression test associated with this. I tested open & closed
> builds
> (created for all platforms) with standard demos.
>
> -phil.


From philip.race at oracle.com  Thu May  8 03:21:36 2014
From: philip.race at oracle.com (Phil Race)
Date: Wed, 07 May 2014 20:21:36 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in
 finding class implementing sun.java2d.pipe. RenderingEngine
In-Reply-To: <536ACD50.7030308@oracle.com>
References: <536A7ACD.8040507@oracle.com> <536ACD50.7030308@oracle.com>
Message-ID: <536AF840.2010009@oracle.com>

On 5/7/14 5:18 PM, Jim Graham wrote:
> If they specify something on the command line, and that doesn't exist, 
> then we end up with Pisces even if Ductus is available.  Is that 
> intentional?

Well, I decided it was OK as the only people likely to use this were 
working on
OpenJDK Pisces improvements so wouldn't be using a build with Ductus anyway
or were trying to specify pisces instead and spelt it wrong or similar ..
The fallback behaviour or whether to signal a problem is something that
could be changed but I expect people who care will be building their own
anyway so no point in over-engineering this.

>
> Also, why the switch from "getProperty(, default)" to the basic 
> getProperty() and manually applying the default?

I changed that in an interim version but it really wasn't needed.
I'll revert tomorrow.

-phil.

>
>             ...jim
>
> On 5/7/14 11:26 AM, Phil Race wrote:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8038875
>> http://cr.openjdk.java.net/~prr/8038875/
>>
>> This is in support of modularisation (ie jigsaw). After the fix
>> alternate implementations
>> are loaded using Class.forName() as specified by the system property
>> sun.java2d.renderer. Note that only the built-in ones are actually
>> supported
>> The mechanism is just for testing.
>>
>> BTW since it happens that Oracle JDK includes the pisces classes as well
>> as the closed source ductus I note that its possible to compare the
>> performance
>> or other characteristics easily in a closed build which has both by
>> specifying
>> to use pisces instead of ductus.
>>
>> There's no regression test associated with this. I tested open & closed
>> builds
>> (created for all platforms) with standard demos.
>>
>> -phil.



From philip.race at oracle.com  Thu May  8 18:32:18 2014
From: philip.race at oracle.com (Phil Race)
Date: Thu, 08 May 2014 11:32:18 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in
 finding class implementing sun.java2d.pipe. RenderingEngine
In-Reply-To: <536AF840.2010009@oracle.com>
References: <536A7ACD.8040507@oracle.com> <536ACD50.7030308@oracle.com>
	<536AF840.2010009@oracle.com>
Message-ID: <536BCDB2.4010401@oracle.com>

See http://cr.openjdk.java.net/~prr/8038875.2

-phil.

On 05/07/2014 08:21 PM, Phil Race wrote:
> On 5/7/14 5:18 PM, Jim Graham wrote:
>> If they specify something on the command line, and that doesn't 
>> exist, then we end up with Pisces even if Ductus is available.  Is 
>> that intentional?
>
> Well, I decided it was OK as the only people likely to use this were 
> working on
> OpenJDK Pisces improvements so wouldn't be using a build with Ductus 
> anyway
> or were trying to specify pisces instead and spelt it wrong or similar ..
> The fallback behaviour or whether to signal a problem is something that
> could be changed but I expect people who care will be building their own
> anyway so no point in over-engineering this.
>
>>
>> Also, why the switch from "getProperty(, default)" to the basic 
>> getProperty() and manually applying the default?
>
> I changed that in an interim version but it really wasn't needed.
> I'll revert tomorrow.
>
> -phil.
>
>>
>>             ...jim
>>
>> On 5/7/14 11:26 AM, Phil Race wrote:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8038875
>>> http://cr.openjdk.java.net/~prr/8038875/
>>>
>>> This is in support of modularisation (ie jigsaw). After the fix
>>> alternate implementations
>>> are loaded using Class.forName() as specified by the system property
>>> sun.java2d.renderer. Note that only the built-in ones are actually
>>> supported
>>> The mechanism is just for testing.
>>>
>>> BTW since it happens that Oracle JDK includes the pisces classes as 
>>> well
>>> as the closed source ductus I note that its possible to compare the
>>> performance
>>> or other characteristics easily in a closed build which has both by
>>> specifying
>>> to use pisces instead of ductus.
>>>
>>> There's no regression test associated with this. I tested open & closed
>>> builds
>>> (created for all platforms) with standard demos.
>>>
>>> -phil.
>



From andrew.brygin at oracle.com  Thu May  8 18:43:09 2014
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Thu, 08 May 2014 22:43:09 +0400
Subject: [OpenJDK 2D-Dev] [9] request for review: 6945174:
 IndexOutOfBoundsException calling ImageIO.read() on malformed PNG
Message-ID: <536BD03D.6040401@oracle.com>

Hello,

could you please review a fix for CR 6945174?

Bug: https://bugs.openjdk.java.net/browse/JDK-6945174
Webrev: http://cr.openjdk.java.net/~bae/6945174/9/webrev.00/

PNG image reader validates the length of chunk's data
when reads image metadata. However, if metadata is ignored,
the length  is used to skip data in the stream without
any validation.

Suggested fix just introduces a validation of the chunk
data length for the case of ignored metadata in a similar
way as it is done for the case of metadata processing.

Supplied regression test demonstrates the problem.

Please take a look.

Thanks,
Andrew.


From philip.race at oracle.com  Thu May  8 22:04:59 2014
From: philip.race at oracle.com (Phil Race)
Date: Thu, 08 May 2014 15:04:59 -0700
Subject: [OpenJDK 2D-Dev] [9] request for review: 6945174:
 IndexOutOfBoundsException calling ImageIO.read() on malformed PNG
In-Reply-To: <536BD03D.6040401@oracle.com>
References: <536BD03D.6040401@oracle.com>
Message-ID: <536BFF8B.4030209@oracle.com>

Looks OK but please fix the typo in the exception string  .. lenght -> 
length

-phil.

On 5/8/14 11:43 AM, Andrew Brygin wrote:
> Hello,
>
> could you please review a fix for CR 6945174?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6945174
> Webrev: http://cr.openjdk.java.net/~bae/6945174/9/webrev.00/
>
> PNG image reader validates the length of chunk's data
> when reads image metadata. However, if metadata is ignored,
> the length  is used to skip data in the stream without
> any validation.
>
> Suggested fix just introduces a validation of the chunk
> data length for the case of ignored metadata in a similar
> way as it is done for the case of metadata processing.
>
> Supplied regression test demonstrates the problem.
>
> Please take a look.
>
> Thanks,
> Andrew.



From james.graham at oracle.com  Thu May  8 22:05:40 2014
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 08 May 2014 15:05:40 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in
 finding class implementing sun.java2d.pipe. RenderingEngine
In-Reply-To: <536AAC53.7090704@oracle.com>
References: <536A7ACD.8040507@oracle.com> <536A88F1.7020206@oracle.com>
	<536A8C3A.6070702@oracle.com> <536A9708.7090005@oracle.com>
	<536AAC53.7090704@oracle.com>
Message-ID: <536BFFB4.3040807@oracle.com>

What about loading native libraries from the 2 engines?  Or are those 
each individually protected by their own doPrivileged?

			...jim

On 5/7/14 2:57 PM, Phil Race wrote:
> I did away with the doPrivileged and it seems fine ...
> http://cr.openjdk.java.net/~prr/8038875.1/
>
> -phil.
>
> On 05/07/2014 01:26 PM, Phil Race wrote:
>> On 5/7/14 12:40 PM, Mandy Chung wrote:
>>>
>>>>
>>>> You may consider to use the 3-arg version of Class.forName and not
>>>> to initialize the class.  This is called within a doPrivileged block
>>>> and it's generally a good convention to invoke the class
>>>> initialization of the specified class (from the system property)
>>>> outside the doPrivileged block.  Static analysis tool may consider
>>>> catching the 1-arg version of Class.forName and flag it as a warning.
>>>
>>> The class will need to be initialized in the newInstance() call. The
>>> above comment might not apply.   Is the doPrivileged block needed for
>>> the RenderingEngine instantiation?  I was wondering if it was needed
>>> for the service loader only or not.
>>>
>>>
>> Good question. A privilege is obviously needed for the getProperty but
>> the rest may not need it .. I can try removing it and see if anything
>> breaks.
>>
>> -phil.
>>
>


From philip.race at oracle.com  Thu May  8 22:11:06 2014
From: philip.race at oracle.com (Phil Race)
Date: Thu, 08 May 2014 15:11:06 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in
 finding class implementing sun.java2d.pipe. RenderingEngine
In-Reply-To: <536BFFB4.3040807@oracle.com>
References: <536A7ACD.8040507@oracle.com> <536A88F1.7020206@oracle.com>
	<536A8C3A.6070702@oracle.com> <536A9708.7090005@oracle.com>
	<536AAC53.7090704@oracle.com> <536BFFB4.3040807@oracle.com>
Message-ID: <536C00FA.10504@oracle.com>

Ductus is definitely wrapping the calls directly at the loadLibrary site.
Pisces is Java only in JDK ..

-phil.

On 5/8/14 3:05 PM, Jim Graham wrote:
> What about loading native libraries from the 2 engines?  Or are those 
> each individually protected by their own doPrivileged?
>
>             ...jim
>
> On 5/7/14 2:57 PM, Phil Race wrote:
>> I did away with the doPrivileged and it seems fine ...
>> http://cr.openjdk.java.net/~prr/8038875.1/
>>
>> -phil.
>>
>> On 05/07/2014 01:26 PM, Phil Race wrote:
>>> On 5/7/14 12:40 PM, Mandy Chung wrote:
>>>>
>>>>>
>>>>> You may consider to use the 3-arg version of Class.forName and not
>>>>> to initialize the class.  This is called within a doPrivileged block
>>>>> and it's generally a good convention to invoke the class
>>>>> initialization of the specified class (from the system property)
>>>>> outside the doPrivileged block.  Static analysis tool may consider
>>>>> catching the 1-arg version of Class.forName and flag it as a warning.
>>>>
>>>> The class will need to be initialized in the newInstance() call. The
>>>> above comment might not apply.   Is the doPrivileged block needed for
>>>> the RenderingEngine instantiation?  I was wondering if it was needed
>>>> for the service loader only or not.
>>>>
>>>>
>>> Good question. A privilege is obviously needed for the getProperty but
>>> the rest may not need it .. I can try removing it and see if anything
>>> breaks.
>>>
>>> -phil.
>>>
>>



From james.graham at oracle.com  Thu May  8 22:11:43 2014
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 08 May 2014 15:11:43 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in
 finding class implementing sun.java2d.pipe. RenderingEngine
In-Reply-To: <536BCDB2.4010401@oracle.com>
References: <536A7ACD.8040507@oracle.com> <536ACD50.7030308@oracle.com>
	<536AF840.2010009@oracle.com> <536BCDB2.4010401@oracle.com>
Message-ID: <536C011F.9060805@oracle.com>

Looks good...

		...jim

On 5/8/14 11:32 AM, Phil Race wrote:
> See http://cr.openjdk.java.net/~prr/8038875.2
>
> -phil.
>
> On 05/07/2014 08:21 PM, Phil Race wrote:
>> On 5/7/14 5:18 PM, Jim Graham wrote:
>>> If they specify something on the command line, and that doesn't
>>> exist, then we end up with Pisces even if Ductus is available.  Is
>>> that intentional?
>>
>> Well, I decided it was OK as the only people likely to use this were
>> working on
>> OpenJDK Pisces improvements so wouldn't be using a build with Ductus
>> anyway
>> or were trying to specify pisces instead and spelt it wrong or similar ..
>> The fallback behaviour or whether to signal a problem is something that
>> could be changed but I expect people who care will be building their own
>> anyway so no point in over-engineering this.
>>
>>>
>>> Also, why the switch from "getProperty(, default)" to the basic
>>> getProperty() and manually applying the default?
>>
>> I changed that in an interim version but it really wasn't needed.
>> I'll revert tomorrow.
>>
>> -phil.
>>
>>>
>>>             ...jim
>>>
>>> On 5/7/14 11:26 AM, Phil Race wrote:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8038875
>>>> http://cr.openjdk.java.net/~prr/8038875/
>>>>
>>>> This is in support of modularisation (ie jigsaw). After the fix
>>>> alternate implementations
>>>> are loaded using Class.forName() as specified by the system property
>>>> sun.java2d.renderer. Note that only the built-in ones are actually
>>>> supported
>>>> The mechanism is just for testing.
>>>>
>>>> BTW since it happens that Oracle JDK includes the pisces classes as
>>>> well
>>>> as the closed source ductus I note that its possible to compare the
>>>> performance
>>>> or other characteristics easily in a closed build which has both by
>>>> specifying
>>>> to use pisces instead of ductus.
>>>>
>>>> There's no regression test associated with this. I tested open & closed
>>>> builds
>>>> (created for all platforms) with standard demos.
>>>>
>>>> -phil.
>>
>


From andrew.brygin at oracle.com  Thu May  8 22:27:57 2014
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Fri, 09 May 2014 02:27:57 +0400
Subject: [OpenJDK 2D-Dev] [9] request for review: 6945174:
 IndexOutOfBoundsException calling ImageIO.read() on malformed PNG
In-Reply-To: <536BFF8B.4030209@oracle.com>
References: <536BD03D.6040401@oracle.com> <536BFF8B.4030209@oracle.com>
Message-ID: <536C04ED.2090308@oracle.com>

Hello Phil,

  I have corrected both occurrences of the typo:

http://cr.openjdk.java.net/~bae/6945174/9/webrev.01/

Thanks,
Andrew

On 5/9/2014 2:04 AM, Phil Race wrote:
> Looks OK but please fix the typo in the exception string  .. lenght -> 
> length
>
> -phil.
>
> On 5/8/14 11:43 AM, Andrew Brygin wrote:
>> Hello,
>>
>> could you please review a fix for CR 6945174?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-6945174
>> Webrev: http://cr.openjdk.java.net/~bae/6945174/9/webrev.00/
>>
>> PNG image reader validates the length of chunk's data
>> when reads image metadata. However, if metadata is ignored,
>> the length  is used to skip data in the stream without
>> any validation.
>>
>> Suggested fix just introduces a validation of the chunk
>> data length for the case of ignored metadata in a similar
>> way as it is done for the case of metadata processing.
>>
>> Supplied regression test demonstrates the problem.
>>
>> Please take a look.
>>
>> Thanks,
>> Andrew.
>



From philip.race at oracle.com  Thu May  8 23:04:03 2014
From: philip.race at oracle.com (Phil Race)
Date: Thu, 08 May 2014 16:04:03 -0700
Subject: [OpenJDK 2D-Dev] [9] request for review: 6945174:
 IndexOutOfBoundsException calling ImageIO.read() on malformed PNG
In-Reply-To: <536C04ED.2090308@oracle.com>
References: <536BD03D.6040401@oracle.com> <536BFF8B.4030209@oracle.com>
	<536C04ED.2090308@oracle.com>
Message-ID: <536C0D63.40903@oracle.com>

Looks good.

-phil.

On 05/08/2014 03:27 PM, Andrew Brygin wrote:
> Hello Phil,
>
>  I have corrected both occurrences of the typo:
>
> http://cr.openjdk.java.net/~bae/6945174/9/webrev.01/
>
> Thanks,
> Andrew
>
> On 5/9/2014 2:04 AM, Phil Race wrote:
>> Looks OK but please fix the typo in the exception string  .. lenght 
>> -> length
>>
>> -phil.
>>
>> On 5/8/14 11:43 AM, Andrew Brygin wrote:
>>> Hello,
>>>
>>> could you please review a fix for CR 6945174?
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6945174
>>> Webrev: http://cr.openjdk.java.net/~bae/6945174/9/webrev.00/
>>>
>>> PNG image reader validates the length of chunk's data
>>> when reads image metadata. However, if metadata is ignored,
>>> the length  is used to skip data in the stream without
>>> any validation.
>>>
>>> Suggested fix just introduces a validation of the chunk
>>> data length for the case of ignored metadata in a similar
>>> way as it is done for the case of metadata processing.
>>>
>>> Supplied regression test demonstrates the problem.
>>>
>>> Please take a look.
>>>
>>> Thanks,
>>> Andrew.
>>
>



From omajid at redhat.com  Thu May  8 23:31:43 2014
From: omajid at redhat.com (Omair Majid)
Date: Thu, 8 May 2014 19:31:43 -0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> Dont use libjpeg-internal macros in
 splashscreen
In-Reply-To: <53679C45.9000303@oracle.com>
References: <20140430204832.GB2584@redhat.com> <53616753.9060704@oracle.com>
	<536168DC.3000203@oracle.com> <53679C45.9000303@oracle.com>
Message-ID: <20140508233142.GH2365@redhat.com>

* Anthony Petrov <anthony.petrov at oracle.com> [2014-05-05 10:12]:
> The fix looks good to me, too.

Thanks. I have pushed it:
http://hg.openjdk.java.net/jdk9/client/jdk/rev/8b9bbe3b2e83

Regards,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681


From philip.race at oracle.com  Fri May  9 22:41:07 2014
From: philip.race at oracle.com (Phil Race)
Date: Fri, 09 May 2014 15:41:07 -0700
Subject: [OpenJDK 2D-Dev] 8038876: Remove use of ServiceLoader in locating
	sun.java2d.cmm.CMMServiceProvider
Message-ID: <536D5983.6060007@oracle.com>

http://cr.openjdk.java.net/~prr/8038876/
https://bugs.openjdk.java.net/browse/JDK-8038876

Another one to help the job of jigsaw ..

-phil.


From mandy.chung at oracle.com  Fri May  9 22:54:47 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 09 May 2014 15:54:47 -0700
Subject: [OpenJDK 2D-Dev] 8038876: Remove use of ServiceLoader in
	locating sun.java2d.cmm.CMMServiceProvider
In-Reply-To: <536D5983.6060007@oracle.com>
References: <536D5983.6060007@oracle.com>
Message-ID: <536D5CB7.9070708@oracle.com>


On 5/9/2014 3:41 PM, Phil Race wrote:
> http://cr.openjdk.java.net/~prr/8038876/
> https://bugs.openjdk.java.net/browse/JDK-8038876
>

Looks good.

> Another one to help the job of jigsaw ..

Thank you for taking care of it.
Mandy


From andrew.brygin at oracle.com  Sat May 10 06:34:23 2014
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Sat, 10 May 2014 10:34:23 +0400
Subject: [OpenJDK 2D-Dev] 8038876: Remove use of ServiceLoader in
	locating sun.java2d.cmm.CMMServiceProvider
In-Reply-To: <536D5983.6060007@oracle.com>
References: <536D5983.6060007@oracle.com>
Message-ID: <536DC86F.7000408@oracle.com>

Hello Phil,

  the change looks fine to me.

Thanks,
Andrew

On 5/10/2014 2:41 AM, Phil Race wrote:
> http://cr.openjdk.java.net/~prr/8038876/
> https://bugs.openjdk.java.net/browse/JDK-8038876
>
> Another one to help the job of jigsaw ..
>
> -phil.



From ag at 4js.com  Mon May 12 07:16:36 2014
From: ag at 4js.com (Alex Geller)
Date: Mon, 12 May 2014 09:16:36 +0200
Subject: [OpenJDK 2D-Dev] [PATCH] JDK-4627340 : RFE: A way to improve text
 printing performance for postscript devices (Improved proposal)
In-Reply-To: <52F0CB37.4000902@4js.com>
References: <52F0CB37.4000902@4js.com>
Message-ID: <53707554.1000301@4js.com>

Hi,
now that my OCA has been processed I would like to bring to attention a 
proposal that I posted earlier this year to this group. Find below a 
repost of the most recent version of the patch.
I don't know if anyone remembers but the idea of the patch is to use 
embedded Type 3 fonts in favor of glyph vectors in calls to 
Graphics2D.drawString().
If required I can summarize the whole topic once more.
Kind regards,
Alex

-------- Original Message --------
Subject: 	[PATCH] JDK-4627340 : RFE: A way to improve text printing 
performance for postscript devices (Improved proposal)
Date: 	Tue, 04 Feb 2014 12:12:55 +0100
From: 	Alex Geller <ag at 4js.com>
To: 	2d-dev at openjdk.java.net



Hi,
my OCA submitted on January 10 didn't make its appearance and I am
guessing it is because I checked the "Vice president" option by mistake.
I have submitted a corrected version and I hope it is OK to continue
posting on this topic in spite of that.
After some minor adjustments to the patch I improved the test program so
that instead of printing a static test document it now reads external
files containing arbitrary attributed text. Based on the new version I
have created a couple of test documents, compared the output under
various settings and performed some benchmarks.

The changes to the patch are:
- For testing purposes the patch can be activated/deactivated by the
temporary system property "PSRenderType3"
- I removed the code that allowed to choose different byte encodings for
the purpose of yielding a more compact Postscript representation mainly
because text extraction via tools like "pstotext" or "ps2pdf" can't work
correctly with anything else then Latin1 encoding anyway (Disregarding
the option to use CID-Keyed fonts).
- I spotted "Font.deriveFont(1000f)" as a source of slowness and
replaced it with code that scales the glyphs of the original font instead.

The test program can now be invoked with some command line options as
list below:
$java PSTest -help
Usage: java PSTest -help|[-inputFileName file name ("example.xml")]
                           [-latinFontName font name ("SansSerif")]
                           [-asianFontName font name ("WenQuanYi Zen Hei")]
                           [-renderingMethod
DrawString|DrawGlyphVector|DrawTextLayout (DrawString)]
                           [-renderIntoBufferedImage true|false (false)]
                           [-useFractionalMetricsForLayoutComputation
true|false (true)]
                           [-useFractionalMetricsForPainting true|false
(true)]
                           [-useAntiAliasingForLayoutComputation
true|false (false)]
                           [-useAntiAliasingForPainting true|false (false)]
                           [-numberOfPrintIterations number (3)]
                           [-paintExpectedStringSizeMarkers number (false)]
                           [-bufferedImageDPI number (300.0)]

I created the following test documents:

-oracle.xml: This is conversion of the Oracle terms and conditions page
(http://www.oracle.com/us/legal/terms/index.html). The document has
about 20,000 characters printed on two pages.
                About 1% of the characters are rendered using the default
rendering due to text colorization (FOREGROUND attribute).
-t-mobile.xml: This is conversion of the T-Mobile terms and conditions
page
(http://www.t-mobile.com/Templates/Popup.aspx?PAsset=Ftr_Ftr_TermsAndConditions&print=true).
The document has about 56,000 characters printed on eight pages.
                About 0.1% of the characters are rendered using the
default rendering due to underlining (UNDERLINE attribute).
-baidu.xml: This is conversion of the Chinese Baidu terms and conditions
page (http://adm.baidu.com/contract.html). The document has about 4,000
characters printed on three pages.
                There are 536 distinct characters in the text. All
characters can be rendered using Type-3 fonts.

-benchmark1.xml: A document containing a page with 64 lines of 100 'a'
characters. This represents the "best case" for the font embedding strategy.
-benchmark2.xml: A document containing 64 lines of 100 characters with
10 different characters
-benchmark2.xml: A document containing 64 lines of 100 characters with
82 different characters
-benchmark4.xml: A document containing a page with 64 lines of 99 'a'
characters and one asian character. This is to test the bit set and to
force the usage of "glyphshow" instead of the
                   more compact "show" string representation
-benchmark5.xml: A document containing a page with 12 lines of unique
characters where each line uses an entirely different font. This
represents the "worst case" for the font embedding strategy.
-benchmark6.xml: Same as benchmark5.xml but just enough non unique
characters are added so that size and performance exceed outline drawing.
-example.xml: A two paged document that replaces the static document
from the previous version.

Other files:
- results.html: Test results. The results include Java execution time,
resulting Postscript file size and the time Ghostscript needed to
rasterize the result.
- results.txt: Detailed test results
- condense.awk: A script that condenses the data in "results.txt"
producing "results.html"
- runtests.sh: A shellscript that produces "results.txt" and "results.html"
- Makefile: A makefile with the targets "run" and "clean"

Running the tests:
The test are run via "make run" which compiles PSTest.java and then runs
the shell script "runtests.sh" which in turn creates the HTML result
file "results.html".
Two of the tests requires a list of fonts. This list is located in
"runtests.sh" and should be adjusted before running.

Measuring rasterization time with Ghostscript:
If "gs" is installed then the script will measure the time Ghostscript
takes to render the document to a 600 DPI raster. As far as I can tell
there is no option to perform
rasterization only. Instead one has to select an output format where
image encoding and file IO does
not dominate the results. After some tests I decided to use the
"pngmono" option with a scaledown of 3.

Regarding the Java performance measurements:
The values "Time for first run" and  "Time for second run" are obtained
by calls to "System.nanoTime()" immediately before and after the code
that sets up and executes the print job.
The JVM startup, the loading of the document and the computation of the
layout are not included in this measure. Each print job is executed
twice from the same JVM hence the differentiation between the values
"first run" and "second run".
The values "Performance for first/second in characters/s" are computed
from those time measurements and the document size.

Summary of results:
The rendering seems to be accurate and the fallback to outline rendering
when required works for all tested cases. Suggestions for additional
tests are very much appreciated since I have only superficial knowledge
in this area.

Rendering speed using Ghostview:
Font embedding is always faster including in the "worst case" scenario
"benchmark5.xml" where there is absolutely no character reuse.
Type 3 font embedding is more than 20 times faster on the Latin
documents "t-mobile.xml" and "oracle.xml" and even with the Chinese
document "baidu.xml" the gain is more than factor 6.

In absolute numbers this means that the 8 page document "t-mobile.xml"
is rendered in under 2 seconds while it takes about 40 seconds using the
current method.
Printing that document on my local DELL 2330dn takes 2 minutes using
embedded fonts while it takes over 40 minutes using the current method.

Rendering speed in Java:
There is a large improvement in speed between the first run and
consecutive runs using the new font embedding strategy for which I have
not yet found an explanation while the effect is not observable when
using outline drawing.
However, even regarding the slower run only, the new method outperforms
the existing method but for the "worst case" scenario where it reaches
only about 80 % of the current performance.
In all other case the improvement is at least factor 3 and gets better
with growing document sizes. For the largest document "t-mobile.xml" the
gain is factor 16 so that it is rendered in less then 300 ms while the
current method takes over 4 seconds.
On a "long running" JVM the gain nearly reached factor 40 so that the
performance went from about 18 thousand characters per second to about
700 thousand characters per second.

Postscript file size:
The examples show an average of about 600 to 700 bytes per character
using outlines for Latin text and 1.5 KB per Chinese glyph.
Using font embedding the initial character definition has the same size
as a outline character but any subsequent character usage requires about
5 bytes for Latin and 20 bytes for Asian text (For non fractional
metrics the values roughly double). The values could be further reduced
a little by using single character shortcuts for the "show", "glyphshow"
and "rmoveto" commands.
The files size varies between factor 400 ("best case" document
"benchmark1.xml") and a 20 % increase of size ("worst case" document
benchmark5.xml). For the two paged latin document "oracle.xml" the gain
is more than factor 40 and for the longer document "t-mobile.xml" the
gain is more than factor 120 so that the document is 300 KB instead of
35 MB. The Chinese document "baidu.xml" is reduced to about 20 % of the
original size. The size difference increases after conversion to PDF so
that for example the "t-mobile" document shrinks from 22 MB to less than
100KB.

Thanks,
Alex




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140512/ed3978bd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PSTest.zip
Type: application/zip
Size: 65412 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140512/ed3978bd/PSTest.zip>

From alexander.v.stepanov at oracle.com  Mon May 12 09:49:24 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Mon, 12 May 2014 13:49:24 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request for 8037511: tidy warnings
 cleanup for java.awt - 2d part
In-Reply-To: <534BBA54.2020307@oracle.com>
References: <533ADC22.705@oracle.com> <533D2092.6090602@oracle.com>
	<534BBA54.2020307@oracle.com>
Message-ID: <53709924.9080103@oracle.com>

Sorry, just a reminder.

Regards,
Alexander

On 14.04.2014 14:37, alexander stepanov wrote:
> Sorry, updated once more (included javax/imageio): 
> http://cr.openjdk.java.net/~yan/8037511/webrev.02/
>
> On 03.04.2014 12:49, alexander stepanov wrote:
>> Please see the updated webrev: 
>> http://cr.openjdk.java.net/~yan/8037511/webrev.01/
>>
>> Files from javax/print were updated too.
>>
>> Thanks,
>> Alexander
>>
>> On 01.04.2014 19:32, alexander stepanov wrote:
>>> Hello,
>>>
>>> Could you please review the fix for the following bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8037511
>>>
>>> Webrev corresponding:
>>> http://cr.openjdk.java.net/~yan/8037511/webrev.00/
>>>
>>> Just a minor cleanup of javadoc to avoid tidy warnings; no other 
>>> code affected.
>>>
>>> Thanks.
>>>
>>> Regards,
>>> Alexander
>>
>



From alexandr.scherbatiy at oracle.com  Mon May 12 14:35:45 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 12 May 2014 18:35:45 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review request for 8029339
 Custom MultiResolution image support on HiDPI displays
In-Reply-To: <535A7509.6050802@oracle.com>
References: <52D51764.8020103@oracle.com> <52DF2F98.3030503@oracle.com>
	<52F4BCEB.9040702@oracle.com> <52F5782A.9060300@oracle.com>
	<52FB7E3E.6050000@oracle.com> <52FC14EC.9080503@oracle.com>
	<53037D3D.80709@oracle.com> <5307E71E.50607@oracle.com>
	<530F3592.40600@oracle.com> <532B00AD.1000704@oracle.com>
	<532B7EC5.9000206@oracle.com> <532C4DD7.1080804@oracle.com>
	<532CD202.5070508@oracle.com> <53302A8E.6090107@oracle.com>
	<53343914.6090004@oracle.com> <533C8DDB.5000406@oracle.com>
	<533E9D42.10409@oracle.com> <53598D86.5020607@oracle.com>
	<535A7509.6050802@oracle.com>
Message-ID: <5370DC41.5080608@oracle.com>


   There was a long thread about the image with sub-pixel resolution 
drawing  on Mac OS X:
http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005559.html

  It was pointed out that Icon images that can be programmatically 
generated also need to have HiDPI support:
http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005566.html
http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005569.html

  All requests about Mac OS X HiDPI support were included to the 
umbrella issue:
    7124410 [macosx] Lion HiDPI support
    https://bugs.openjdk.java.net/browse/JDK-7124410

  Thanks,
  Alexandr.

On 4/25/2014 6:45 PM, Alexander Scherbatiy wrote:
> On 4/25/2014 2:17 AM, Jim Graham wrote:
>> Hi Alexandr,
>>
>> I asked for who was requesting these facilities and you responded 
>> with the solution you are planning to provide.
>>
>> I don't care what the solution looks like if we have nobody asking 
>> for the feature - I am asking who is asking for these capabilities?
>
>    This is the request from the AWT team for the HiDPI support.
>
>    Thanks,
>    Alexandr.
>>
>>             ...jim
>>
>> On 4/4/14 4:53 AM, Alexander Scherbatiy wrote:
>>> On 4/3/2014 2:23 AM, Jim Graham wrote:
>>>> Hi Alexandr,
>>>>
>>>> The back and forth is getting confusing here, so I thought I'd try to
>>>> summarize and start fresh(ish):
>>>>
>>>> 1. We need to support @2x internally for MacOS compatibility (done).
>>>>
>>>> 2. We will need to support _DPI images for Win-DPI compatibility 
>>>> (TBD).
>>>>
>>>> 3. Customers may have their own collection of images to bundle
>>>> together into an MR image (working on that here).  What is the push
>>>> for this?  Is this simply parity with Mac interfaces?
>>>
>>>          ----------
>>>          Image[] resolutionVariants = // get sorted by sizes array of
>>> resolution variants;
>>>          Image mrImage =
>>> Toolkit.getDefaultToolkit().createMRImage(baseImageIndex,
>>> resolutionVariants);
>>>          ----------
>>>
>>>       Here is the proposed patch:
>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.04/
>>>
>>>> 4. Customers may want to synthetically generate images at arbitrary
>>>> resolutions (a variation that is impacting this solution). What is
>>>> the push for this?
>>>          ----------
>>>          Image mrImage =
>>> Toolkit.getDefaultToolkit().createMRImage(baseImageWidth, 
>>> baseImageHeight,
>>>                  new float[][]{{100, 100}, {150, 150}, {200, 200}}, //
>>> resolution variants sizes
>>>                  (rvWidth, rvHeight) -> {  /* generate a resolution
>>> variant */  });
>>>         ----------
>>>
>>>>
>>>> 5. I'm guessing that customers might want to override the logic to
>>>> choose from among multiple resolutions.  That came from me based on
>>>> seeing Mac and Win using different selection logic and our history of
>>>> developers split between those wanting cross-platform consistency and
>>>> those wanting consistency with native apps on each platform. Also,
>>>> the needs of an animator may differ from the needs of a
>>>> resolution-settable-document editor as to how dynamically the images
>>>> shift between resolution variants.
>>>         ----------
>>>          Image[] resolutionVariants = // get sorted by sizes array of
>>> resolution variants;
>>>          Image mrImage = ImageResolutionHelper.createMRImage(
>>>                  (rvWidth, rvHeight, resolutionVariants) -> { /*use a
>>> custom logic to choose a resolution variant from an array of images*/},
>>>                  (logicalDPI, baseImageSize, destImageSize) ->
>>> destImageSize, // calculate the custom aware resolution variant size
>>>                  baseImageIndex, resolutionVariants);
>>>         ----------
>>>
>>>     or just extend the CustomMultiResolutionImage which has Image as 
>>> the
>>> parent class:
>>>
>>> --------------------
>>>   public class CustomMultiResolutionImage extends
>>> AbstractMultiResolutionImage {
>>>
>>>      @Override
>>>      public Image getResolutionVariant(float logicalDPIX, float
>>> logicalDPIY,
>>>              float baseImageWidth, float baseImageHeight,
>>>              float destImageWidth, float destImageHeight) {
>>>          // return a resolution variant based on the given logical DPI,
>>>          // base image size, or destination image size
>>>      }
>>>
>>>      @Override
>>>      public List<Image> getResolutionVariants() {
>>>          // return a list of resolution variants
>>>      }
>>>
>>>      @Override
>>>      protected Image getBaseImage() {
>>>          // return the base image
>>>      }
>>> }
>>> --------------------
>>>>
>>>> Is that a fair summary of all of the considerations so far, or did I
>>>> miss something?
>>>     I think it should cover the main needs.
>>>
>>>      Thanks,
>>>      Alexandr.
>>>>
>>>>             ...jim
>>>>
>>>> On 3/27/14 7:43 AM, Alexander Scherbatiy wrote:
>>>>>
>>>>>   Below are some thoughts about TK.createMRImage(...) method
>>>>>
>>>>> On 3/24/2014 4:52 PM, Alexander Scherbatiy wrote:
>>>>>> Hello,
>>>>>>
>>>>>>   Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.03/
>>>>>>
>>>>>>   - baseImageWidth/Height arguments are added to the
>>>>>> getResolutionVariant(...) method
>>>>>>   - dest image sizes are reverted to included DPI scale
>>>>>>   - AbstractMultiResolutionImage is added. It needs only to 
>>>>>> implement
>>>>>> only 3 methods from the  AbstractMultiResolutionImage class
>>>>>>     to create a custom multi-resolution image. For example:
>>>>>>
>>>>>> On 3/22/2014 3:57 AM, Jim Graham wrote:
>>>>>>>
>>>>>>> Your code example below can be expressed as an implementation of 
>>>>>>> the
>>>>>>> single-method, lambda-compatible interface that expresses just the
>>>>>>> getRV() method. They could easily do:
>>>>>>>
>>>>>>> final Image baseImage = ...;
>>>>>>> TK.createMRImage(new RVInterface() {
>>>>>>>     public Image getRV(...) {
>>>>>>>         // calculate rvWidth and rvHeight
>>>>>>>         // look up rvWidth/rvHeight in a database of images
>>>>>>>         // possibly contruct a new image
>>>>>>>         return rvImage;
>>>>>>>     }
>>>>>>> }, baseImage);
>>>>>>>
>>>>>       The RVInterface mixes the logic that construct an image and
>>>>> chooses the necessary resolution variant.
>>>>>       It is ok if a developer always implements this interface. If it
>>>>> needs to have DPI/Transform/Platform aware RVInterface the image
>>>>> construction logic should be separated.
>>>>>
>>>>>      Does  TK.createMRImage() method implies that Platform aware 
>>>>> logic
>>>>> should be used for a resolution-variant choosing?
>>>>>      If so, may be general createMRImage() can be placed in the
>>>>> ImageResolutionHelper.
>>>>>>> The main issue I see is if you might want the newly constructed
>>>>>>> variants to appear in the List returned from the getVariants()
>>>>>>> method.  I'm not sure what value that would have beyond simply
>>>>>>> returning the base media that the object uses from which to 
>>>>>>> construct
>>>>>>> its variants...?
>>>>>
>>>>>    It can be solved by using something like array of image sizes or
>>>>> other seeds and a mapper that can create an image from the given 
>>>>> seed.
>>>>>
>>>>>   It can look like:
>>>>> -------------------------
>>>>> public class ImageResolutionHelper {
>>>>>      public interface RVChooser {
>>>>>
>>>>>          public Image getRV(
>>>>>                  float logicalDPIX, float logicalDPIY,
>>>>>                  float baseImageWidth, float baseImageHeight,
>>>>>                  float destImageWidth, float destImageHeight,
>>>>>                  final Image... resolutionVariants);
>>>>>      }
>>>>>
>>>>>      public static final RVChooser DPI_AWARE = ...;
>>>>>      public static final RVChooser TRANSFORM_AWARE = ...;
>>>>>
>>>>>      // resolutionVariants is an array of  sorted by width/height 
>>>>> images
>>>>>      static Image createMRImage(final RVChooser rvChooser,
>>>>>              final int baseImageIndex, final Image...
>>>>> resolutionVariants) { ... }
>>>>>
>>>>>      // sorted by width/height images should be generated from seeds
>>>>>      static <Type> Image createMRImage(final RVChooser rvChooser,
>>>>>              final Type baseImageSeed, final Function<Type, Image>
>>>>> mapper, final Type... rvSeeds) {...}
>>>>> }
>>>>>
>>>>> public abstract class Toolkit {
>>>>>      public abstract Image createMRImage(int baseImageIndex, Image...
>>>>> resolutionVariants); // Platform aware rv chooser is used
>>>>>      public abstract RVChooser getPlatformRVChooser() ;
>>>>> }
>>>>> --------------------------
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>>>>
>>>>>>>>      I think it is better to provide both the MultiResolutionImage
>>>>>>>> and
>>>>>>>> its implementation based on the given resolution variants array.
>>>>>>>
>>>>>>> It occurs to me that even if we don't go with a 
>>>>>>> lambda-factory-based
>>>>>>> approach like what I'm describing, it might make sense to provide a
>>>>>>> baseMR implementation that they can subclass to keep them from 
>>>>>>> trying
>>>>>>> to subclass off of BufferedImage instead.  I really would like to
>>>>>>> avoid "custom MR images are subclasses of BufImg" if we can as I
>>>>>>> think the mix of concepts is a little jarring...
>>>>>>>
>>>>>>>             ...jim
>>>>>>>
>>>>>>>>     The implementation could look like:
>>>>>>>> ---------------------------------
>>>>>>>> public class CustomMultiResolutionImage extends Image implements
>>>>>>>> MultiResolutionImage {
>>>>>>>>
>>>>>>>>      int baseImageIndex;
>>>>>>>>      Image[] resolutionVariants;
>>>>>>>>
>>>>>>>>      public CustomMultiResolutionImage(int baseImageIndex,
>>>>>>>>              Image... resolutionVariants) {
>>>>>>>>          this.baseImageIndex = baseImageIndex;
>>>>>>>>          this.resolutionVariants = resolutionVariants;
>>>>>>>>      }
>>>>>>>>
>>>>>>>>      @Override
>>>>>>>>      public int getWidth(ImageObserver observer) {
>>>>>>>>          return getBaseImage().getWidth(null);
>>>>>>>>      }
>>>>>>>>
>>>>>>>>      @Override
>>>>>>>>      public int getHeight(ImageObserver observer) {
>>>>>>>>          return getBaseImage().getHeight(null);
>>>>>>>>      }
>>>>>>>>
>>>>>>>>      @Override
>>>>>>>>      public ImageProducer getSource() {
>>>>>>>>          return getBaseImage().getSource();
>>>>>>>>      }
>>>>>>>>
>>>>>>>>      @Override
>>>>>>>>      public Graphics getGraphics() {
>>>>>>>>          return getBaseImage().getGraphics();
>>>>>>>>      }
>>>>>>>>
>>>>>>>>      @Override
>>>>>>>>      public Object getProperty(String name, ImageObserver 
>>>>>>>> observer) {
>>>>>>>>          return getBaseImage().getProperty(name, observer);
>>>>>>>>      }
>>>>>>>>
>>>>>>>>      @Override
>>>>>>>>      public Image getResolutionVariant(float logicalDPIX, float
>>>>>>>> logicalDPIY,
>>>>>>>>              float destinationImageWidth, float
>>>>>>>> destinationImageHeight) {
>>>>>>>>              // calculate resolution variant width/height
>>>>>>>>          return getResolutionVariant(rvWidth, rvHeight);
>>>>>>>>      }
>>>>>>>>
>>>>>>>>      @Override
>>>>>>>>      public List<Image> getResolutionVariants() {
>>>>>>>>          return Arrays.asList(resolutionVariants);
>>>>>>>>      }
>>>>>>>>
>>>>>>>>      private Image getResolutionVariant(float rvWidth, float
>>>>>>>> rvHeight) {
>>>>>>>>          // return a resolution variant based on the given 
>>>>>>>> width and
>>>>>>>> height
>>>>>>>>      }
>>>>>>>>
>>>>>>>>      private Image getBaseImage() {
>>>>>>>>          return resolutionVariants[baseImageIndex];
>>>>>>>>      }
>>>>>>>> }
>>>>>>>> ---------------------------------
>>>>>>>>
>>>>>>>>    Thanks,
>>>>>>>>    Alexandr.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Then we provide one of these from TK.get/createImage() when the
>>>>>>>>> platform detects @2x, or Win8-style variants.
>>>>>>>>>
>>>>>>>>> For custom images we provide TK.createMRImage(lambda getRV, Image
>>>>>>>>> variants...) and TK.createMRImage(Image variants...);
>>>>>>>>>
>>>>>>>>> Since the get<List> method is just bookkeeping, I don't see them
>>>>>>>>> needing to override it, so the getRV() method is really the only
>>>>>>>>> thing
>>>>>>>>> they might want to override, and we can tie into the new Lambda
>>>>>>>>> capabilities by making a single-method interface for it that they
>>>>>>>>> supply in a factory method.
>>>>>>>>>
>>>>>>>>> I realize that the interface you created is more fundamentally
>>>>>>>>> OO, but
>>>>>>>>> the Image class has always been special in this regard in the AWT
>>>>>>>>> ecosystem (in so far as we do not support someone implementing 
>>>>>>>>> their
>>>>>>>>> own Image subclass even though it is technically possible).
>>>>>>>>> Because of
>>>>>>>>> this special nature of Image, we end up with the situation 
>>>>>>>>> that if
>>>>>>>>> someone were given a need to create a subclass of Image, then 
>>>>>>>>> they
>>>>>>>>> would turn to BufImg as their superclass even though BufImg is
>>>>>>>>> essentially an implementation-specific leaf node on the Image 
>>>>>>>>> class
>>>>>>>>> hierarchy.  This approach with a factory method to create an
>>>>>>>>> internal
>>>>>>>>> subclass of the new MRI class mirrors the existing cases of Image
>>>>>>>>> objects that come from factories as well.
>>>>>>>>>
>>>>>>>>> Thoughts?
>>>>>>>>>
>>>>>>>>>             ...jim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3/20/14 7:52 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>
>>>>>>>>>>    Hello,
>>>>>>>>>>
>>>>>>>>>>    Could you review the updated version of the fix:
>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.01/
>>>>>>>>>>
>>>>>>>>>>   - The "getResolutionVariant(int width, int height)" method 
>>>>>>>>>> from
>>>>>>>>>> MultiResolutionImage class is changed to
>>>>>>>>>>     Image getResolutionVariant(float logicalDPIX, float
>>>>>>>>>> logicalDPIY,
>>>>>>>>>> float width, float height, AffineTransform transform);
>>>>>>>>>>
>>>>>>>>>>   - sun.awt.image.ImageResolutionHelper class is added. The
>>>>>>>>>> sun.awt.image.MultiResolutionToolkitImage and
>>>>>>>>>>      sun.awt.image.MultiResolutionBufferedImage classes are used
>>>>>>>>>> PLATFORM  ImageResolutionHelper.
>>>>>>>>>>
>>>>>>>>>>   The  MultiResolutionImage interface implementation could look
>>>>>>>>>> like:
>>>>>>>>>> ------------------------------
>>>>>>>>>> public class CustomMultiResolutionImage extends BufferedImage
>>>>>>>>>> implements
>>>>>>>>>> MultiResolutionImage {
>>>>>>>>>>
>>>>>>>>>>      private final Image[] resolutionVariants;
>>>>>>>>>>
>>>>>>>>>>      public CustomMultiResolutionImage(int baseIndex, Image...
>>>>>>>>>> images) {
>>>>>>>>>>          super(images[baseIndex].getWidth(null),
>>>>>>>>>> images[baseIndex].getHeight(null),
>>>>>>>>>>                  BufferedImage.TYPE_INT_RGB);
>>>>>>>>>>          this.resolutionVariants = images;
>>>>>>>>>>          Graphics g = getGraphics();
>>>>>>>>>>          g.drawImage(images[baseIndex], 0, 0, null);
>>>>>>>>>>          g.dispose();
>>>>>>>>>>      }
>>>>>>>>>>
>>>>>>>>>>      @Override
>>>>>>>>>>      public Image getResolutionVariant(float logicalDPIX, float
>>>>>>>>>> logicalDPIY,
>>>>>>>>>>              float width, float height, AffineTransform
>>>>>>>>>> transform) {
>>>>>>>>>>          return getResolutionVariant(logicalDPIX * width,
>>>>>>>>>> logicalDPIY *
>>>>>>>>>> height);
>>>>>>>>>>      }
>>>>>>>>>>
>>>>>>>>>>      @Override
>>>>>>>>>>      public List<Image> getResolutionVariants() {
>>>>>>>>>>          return Arrays.asList(resolutionVariants);
>>>>>>>>>>      }
>>>>>>>>>>
>>>>>>>>>>      public Image getResolutionVariant(double width, double
>>>>>>>>>> height) {
>>>>>>>>>>          for (Image image : resolutionVariants) {
>>>>>>>>>>              if (width <= image.getWidth(null) && height <=
>>>>>>>>>> image.getHeight(null)) {
>>>>>>>>>>                  return image;
>>>>>>>>>>              }
>>>>>>>>>>          }
>>>>>>>>>>          return this;
>>>>>>>>>>      }
>>>>>>>>>> }
>>>>>>>>>> ------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    Thanks,
>>>>>>>>>>    Alexandr.
>>>>>>>>>>
>>>>>>>>>> On 2/27/2014 4:54 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>> On 2/22/2014 3:54 AM, Jim Graham wrote:
>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>
>>>>>>>>>>>> On 2/18/14 7:33 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>   Hi Jim,
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Let's divide the discussion into two part.
>>>>>>>>>>>>>
>>>>>>>>>>>>>   1. Where it is better to hold resolution variants?
>>>>>>>>>>>>>      Putting resolution variants in Image class brings some
>>>>>>>>>>>>> questions like:
>>>>>>>>>>>>>    - Some type of images do not need to have resolution 
>>>>>>>>>>>>> variants
>>>>>>>>>>>>>    - Should resolution variants have the same type as the 
>>>>>>>>>>>>> base
>>>>>>>>>>>>> image?
>>>>>>>>>>>>>    - getResolutionVariants() method can return copy of the
>>>>>>>>>>>>> original
>>>>>>>>>>>>> list
>>>>>>>>>>>>> so add/removeRV methods should be also added.
>>>>>>>>>>>>>
>>>>>>>>>>>>>    There are pros and cons for placing resolution variants to
>>>>>>>>>>>>> Image
>>>>>>>>>>>>> class or to a separate intreface.
>>>>>>>>>>>>
>>>>>>>>>>>> I agree that this could be a separate interface. In my 
>>>>>>>>>>>> examples
>>>>>>>>>>>> below I was just sticking them inside an "Image{}" to show 
>>>>>>>>>>>> where
>>>>>>>>>>>> they
>>>>>>>>>>>> lived in the set of involved objects, not a specific
>>>>>>>>>>>> recommendation
>>>>>>>>>>>> that they actually be new methods on the base class itself. I
>>>>>>>>>>>> probably should have put a comment there about that.
>>>>>>>>>>>>
>>>>>>>>>>>> With respect to add/remove - that is assuming a need for 
>>>>>>>>>>>> manual
>>>>>>>>>>>> construction of an image set, right? Forgive me if I'm
>>>>>>>>>>>> forgetting
>>>>>>>>>>>> something, but I seem to recall that manual Multi-Res 
>>>>>>>>>>>> images was
>>>>>>>>>>>> proposed as a way for developers to introduce @2x support
>>>>>>>>>>>> themselves,
>>>>>>>>>>>> but if we are internally managing @2x and -DPI variants for 
>>>>>>>>>>>> them,
>>>>>>>>>>>> then I'm not sure if there is actual developer need to 
>>>>>>>>>>>> manually
>>>>>>>>>>>> construct their own.  Am I forgetting something?
>>>>>>>>>>>    The NSImage has addRepresentation/removeRepresentation
>>>>>>>>>>> methods to
>>>>>>>>>>> work with image representations on Mac OS X.
>>>>>>>>>>>    The java.awt.Image class should provide similar
>>>>>>>>>>> functionality to
>>>>>>>>>>> have the possibilities as Cocoa on HiDPI displays.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>   2. Using scale factor/image sizes/scaled image sizes to
>>>>>>>>>>>>> retreive a
>>>>>>>>>>>>> resolution variant.
>>>>>>>>>>>>>
>>>>>>>>>>>>>    May be it is better to have a structure that provide all
>>>>>>>>>>>>> necessary
>>>>>>>>>>>>> information  to query the resolution variant: scale factor,
>>>>>>>>>>>>> draw area
>>>>>>>>>>>>> width/height, transformed area width/height?
>>>>>>>>>>>>>
>>>>>>>>>>>>>    For example:
>>>>>>>>>>>>>    ---------------------
>>>>>>>>>>>>>      public interface MultiResolutionImage {
>>>>>>>>>>>>>
>>>>>>>>>>>>>          interface DrawAreaInfo {
>>>>>>>>>>>>>
>>>>>>>>>>>>>              float getScaleFactor();
>>>>>>>>>>>>>              float getAreaWidth();
>>>>>>>>>>>>>              float getAreaHeight();
>>>>>>>>>>>>>              float getTransformedAreaWidth();
>>>>>>>>>>>>>              float getTransformedAreaHeight();
>>>>>>>>>>>>>          }
>>>>>>>>>>>>>
>>>>>>>>>>>>>          public Image getResolutionVariant(DrawAreaInfo
>>>>>>>>>>>>> drawAreaInfo) ;
>>>>>>>>>>>>>          public List<Image> getResolutionVariants();
>>>>>>>>>>>>>      }
>>>>>>>>>>>>>    ---------------------
>>>>>>>>>>>>
>>>>>>>>>>>> The problem with a constructor is that this is something 
>>>>>>>>>>>> that is
>>>>>>>>>>>> (potentially) done on every drawImage() call, which means 
>>>>>>>>>>>> we are
>>>>>>>>>>>> inviting GC into the equation.  If we can come up with a 
>>>>>>>>>>>> simple
>>>>>>>>>>>> "just
>>>>>>>>>>>> a couple/3/4 numbers" way to embed that data into a method 
>>>>>>>>>>>> call
>>>>>>>>>>>> argument list then we can make this lighter weight.
>>>>>>>>>>>>
>>>>>>>>>>>> What about simply having floating point (double) dimensions on
>>>>>>>>>>>> the
>>>>>>>>>>>> rendered size
>>>>>>>>>>>       There should be a way to choose a resolution variant
>>>>>>>>>>> based on
>>>>>>>>>>> requested drawing size or transformed drawing size.
>>>>>>>>>>>       At least a current transformation should be included too.
>>>>>>>>>>>> plus a single floating point "logical DPI" for the screen?
>>>>>>>>>>>      There is the ID2D1Factory::GetDesktopDpi method which 
>>>>>>>>>>> returns
>>>>>>>>>>> dpiX and dpiY.
>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316
>>>>>>>>>>>
>>>>>>>>>>>     That means that logicalDPIX/Y can have different values.
>>>>>>>>>>>      At least it is described in the
>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/ff684173
>>>>>>>>>>>      "To get the DPI setting, call the 
>>>>>>>>>>> ID2D1Factory::GetDesktopDpi
>>>>>>>>>>> method. The DPI is returned as two floating-point values, 
>>>>>>>>>>> one for
>>>>>>>>>>> the
>>>>>>>>>>> x-axis and one for the y-axis. In theory, these values can 
>>>>>>>>>>> differ.
>>>>>>>>>>> Calculate a separate scaling factor for each axis."
>>>>>>>>>>>
>>>>>>>>>>>   The getResolutionVariant method could look like:
>>>>>>>>>>>    --------------------------------------
>>>>>>>>>>>     public Image getResolutionVariant(float logicalDPIX, float
>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>             float widthX, float widthY, AffineTransform
>>>>>>>>>>> transform);
>>>>>>>>>>>    --------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>>  If the image is known (either passed as an argument or the
>>>>>>>>>>>> method is
>>>>>>>>>>>> called on the image), then it can provide the original WH.
>>>>>>>>>>>>
>>>>>>>>>>>>>    The MultiResolutionImage default implementation could 
>>>>>>>>>>>>> allow
>>>>>>>>>>>>> to use
>>>>>>>>>>>>> different strategies like scale factor/transfom/OS based
>>>>>>>>>>>>>    to query a resolution variant. The OS based strategy 
>>>>>>>>>>>>> can be
>>>>>>>>>>>>> used by
>>>>>>>>>>>>> default.
>>>>>>>>>>>>
>>>>>>>>>>>> For Mac policy, all we need is the transformed dimensions, 
>>>>>>>>>>>> which
>>>>>>>>>>>> can
>>>>>>>>>>>> be passed in as FP for generality.  For Windows policy, all we
>>>>>>>>>>>> need
>>>>>>>>>>>> is logical DPI for the screen.   What other information 
>>>>>>>>>>>> would we
>>>>>>>>>>>> need, or would an algorithm like to use, that can't be 
>>>>>>>>>>>> computed
>>>>>>>>>>>> from
>>>>>>>>>>>> those 2 pieces?
>>>>>>>>>>>      The aim is to provide a base class that can be used to
>>>>>>>>>>> create a
>>>>>>>>>>> MultiResolutionImage like:
>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/diff/ae53ebce5fa3/src/share/classes/sun/awt/image/MultiResolutionBufferedImage.java 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>      A developer should be able to implement a custom 
>>>>>>>>>>> algorithm to
>>>>>>>>>>> query a resolution variant.
>>>>>>>>>>>
>>>>>>>>>>>     It can be done by overriding the getResolutionVariant 
>>>>>>>>>>> image:
>>>>>>>>>>>    -----------------------
>>>>>>>>>>>         Image mrImage = new MultiResolutionBufferedImage(){
>>>>>>>>>>>             @Override
>>>>>>>>>>>             public Image getResolutionVariant(...) {
>>>>>>>>>>>                 // Custom logic here
>>>>>>>>>>>             }
>>>>>>>>>>>         };
>>>>>>>>>>>    -----------------------
>>>>>>>>>>>
>>>>>>>>>>>    Or it can be done by using resolution variant choosers so a
>>>>>>>>>>> developer can implement custom resolution variant query:
>>>>>>>>>>>    -----------------------
>>>>>>>>>>> public class MultiResolutionBufferedImage implements
>>>>>>>>>>> MultiResolutionImage{
>>>>>>>>>>>
>>>>>>>>>>>     interface ResolutionVariantChooser{
>>>>>>>>>>>         Image getResolutionVariant(dpi, size,..., List<Image>
>>>>>>>>>>> resolutionVariants);
>>>>>>>>>>>     }
>>>>>>>>>>>     ResolutionVariantChooser TRANSFORM_BASED = null;
>>>>>>>>>>>     ResolutionVariantChooser DPI_BASED = null;
>>>>>>>>>>>
>>>>>>>>>>>     ResolutionVariantChooser rvChooser;
>>>>>>>>>>>
>>>>>>>>>>>     @Override
>>>>>>>>>>>     public Image getResolutionVariant(dpi, size,...,) {
>>>>>>>>>>>         return rvChooser.getResolutionVariant(dpi, size,...,
>>>>>>>>>>> getResolutionVariants());
>>>>>>>>>>>     }
>>>>>>>>>>> }
>>>>>>>>>>>    -----------------------
>>>>>>>>>>>
>>>>>>>>>>>   Thanks,
>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2/13/2014 4:42 AM, Jim Graham wrote:
>>>>>>>>>>>>>> On 2/12/14 5:59 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>> On 2/8/2014 4:19 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>> The primary thing that I was concerned about was the
>>>>>>>>>>>>>>>> presence of
>>>>>>>>>>>>>>>> integers in the API when Windows uses non-integer 
>>>>>>>>>>>>>>>> multiples
>>>>>>>>>>>>>>>       It would make sense to pass real numbers to the
>>>>>>>>>>>>>>> getResolutionVariant() method  if the difference between
>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>> variants sizes is 1.
>>>>>>>>>>>>>>>       It seems that it is not a common case.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I was thinking of other API that is related to this, such as
>>>>>>>>>>>>>> the API
>>>>>>>>>>>>>> that queries the scaling factor from a SurfaceManager. I
>>>>>>>>>>>>>> seem to
>>>>>>>>>>>>>> remember some integer return values in that, but Windows 
>>>>>>>>>>>>>> might
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>> the answer 1.4 or 1.8, depending on the screen scaling 
>>>>>>>>>>>>>> factor
>>>>>>>>>>>>>> that was
>>>>>>>>>>>>>> determined from the UI.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In terms of the getResolutionVariant() method here, those
>>>>>>>>>>>>>> non-integer
>>>>>>>>>>>>>> screen scaling factors don't directly impact this API. 
>>>>>>>>>>>>>> But, we
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>> some issues with the use of integers there from other 
>>>>>>>>>>>>>> sources:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - That API assumes that the caller will determine the pixel
>>>>>>>>>>>>>> size
>>>>>>>>>>>>>> needed, but the actual media choice is determined with
>>>>>>>>>>>>>> different
>>>>>>>>>>>>>> techniques on Mac and Windows so this means that the caller
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>> to worry about platform conventions.  Is that the right
>>>>>>>>>>>>>> tradeoff?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - The technique recommended for Mac involves computing the
>>>>>>>>>>>>>> precise
>>>>>>>>>>>>>> size desired using the current transform, which may be a
>>>>>>>>>>>>>> floating
>>>>>>>>>>>>>> point value, so the integer values used in this API are 
>>>>>>>>>>>>>> already
>>>>>>>>>>>>>> approximations and there is no documentation on how to
>>>>>>>>>>>>>> generate the
>>>>>>>>>>>>>> proper integer.  In particular, the current code in SG2D
>>>>>>>>>>>>>> naively
>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>> a cast to integer to determine the values to supply which
>>>>>>>>>>>>>> means a
>>>>>>>>>>>>>> transformed size of W+0.5 will be truncated to W and the 
>>>>>>>>>>>>>> lower
>>>>>>>>>>>>>> resolution image will be used. Does that conform to Mac
>>>>>>>>>>>>>> guidelines? Do
>>>>>>>>>>>>>> they require the truncated size to reach W+1 before the next
>>>>>>>>>>>>>> size is
>>>>>>>>>>>>>> used?  Passing in float or double values would sidestep 
>>>>>>>>>>>>>> all of
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> since then the comparisons would be done with full 
>>>>>>>>>>>>>> precision,
>>>>>>>>>>>>>> but as
>>>>>>>>>>>>>> long as we can determine a "best practices compatible 
>>>>>>>>>>>>>> with all
>>>>>>>>>>>>>> platforms" rule on how to round to integers, then integers
>>>>>>>>>>>>>> are OK
>>>>>>>>>>>>>> there.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - The Windows document you cite below suggests that the
>>>>>>>>>>>>>> determination
>>>>>>>>>>>>>> should be made by looking at the Screen DPI and choosing the
>>>>>>>>>>>>>> next
>>>>>>>>>>>>>> higher media variant based on that screen DPI. They do not
>>>>>>>>>>>>>> specify
>>>>>>>>>>>>>> choosing media based on the current transform as is done for
>>>>>>>>>>>>>> Mac.  If
>>>>>>>>>>>>>> we stick with supplying values that are used to determine 
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>> media
>>>>>>>>>>>>>> to use, then on Windows we should not take the transform 
>>>>>>>>>>>>>> into
>>>>>>>>>>>>>> account,
>>>>>>>>>>>>>> but instead query the SurfaceManager for the scale factor 
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> only
>>>>>>>>>>>>>> transform by those values (even if the current transform was
>>>>>>>>>>>>>> manually
>>>>>>>>>>>>>> overridden to identity).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There are pros and cons to both approaches.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Mac ensures that you are always using the best media for any
>>>>>>>>>>>>>> given
>>>>>>>>>>>>>> render operation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But, Windows ensure more consistency in the face of other
>>>>>>>>>>>>>> scaling.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The thing to consider is that if you have a 500x500 image
>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>> 1000x1000 variant and you rendering it at 500x500 and then
>>>>>>>>>>>>>> 501x501,
>>>>>>>>>>>>>> that first jump will be fairly jarring as the scaled version
>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>> 1000x1000 will not look precisely like the original 500x500
>>>>>>>>>>>>>> did.
>>>>>>>>>>>>>> With
>>>>>>>>>>>>>> @2x images only, this effect is minimized so the 
>>>>>>>>>>>>>> advantage of
>>>>>>>>>>>>>> always
>>>>>>>>>>>>>> using "the best media for a given render operation" may
>>>>>>>>>>>>>> outweigh the
>>>>>>>>>>>>>> inconsistency issue.  But, on Windows where the media are
>>>>>>>>>>>>>> 1.4x or
>>>>>>>>>>>>>> 1.8x
>>>>>>>>>>>>>> in size, a downscaled image will start to show more
>>>>>>>>>>>>>> interpolation
>>>>>>>>>>>>>> noise and so the balance of the two choices may shift more
>>>>>>>>>>>>>> towards not
>>>>>>>>>>>>>> wanting a jarring shift.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We might want one or more of the following:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Developer chooses policy (TX_AWARE, DPI_AWARE,
>>>>>>>>>>>>>> ALWAYS_LARGEST,
>>>>>>>>>>>>>> NONE,
>>>>>>>>>>>>>> PLATFORM) where the last policy would use TX_AWARE on Mac 
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> DPI_AWARE on Windows
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - We create our own policy and always use it (TX_AWARE? or
>>>>>>>>>>>>>> DPI_AWARE?)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - We create our own policy that dynamically chooses one 
>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>> above
>>>>>>>>>>>>>> strategies depending on platform or available media or ???
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - We could create an optional interface for them to install
>>>>>>>>>>>>>> their
>>>>>>>>>>>>>> own
>>>>>>>>>>>>>> algorithm as well.  I think it would work best as a delegate
>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>> that one installs into Image so that it can be used with any
>>>>>>>>>>>>>> image
>>>>>>>>>>>>>> without having to subclass (it wouldn't really have much 
>>>>>>>>>>>>>> to do
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> BufferedImages or VolatileImages, though):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> class Image {
>>>>>>>>>>>>>>     void setResolutionHelper(ImageResolutionHelper foo);
>>>>>>>>>>>>>>     List<Image> getResolutionVariants();
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> or:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> class Graphics {
>>>>>>>>>>>>>>      void setResolutionHelper(ImageResolutionHelper foo);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> or - anywhere else it could be installed more centrally (per
>>>>>>>>>>>>>> App
>>>>>>>>>>>>>> context)?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> and the interface would be something like one of these
>>>>>>>>>>>>>> variants:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> interface ImageResolutionHelper {
>>>>>>>>>>>>>>     // This version would prevent substituting a random 
>>>>>>>>>>>>>> image:
>>>>>>>>>>>>>>     // They have to return an index into the List<Image> for
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> image...
>>>>>>>>>>>>>>     public int chooseVariant(Image img, double dpi, 
>>>>>>>>>>>>>> number w,
>>>>>>>>>>>>>> number h);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> or:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     // This version would allow substituting an arbitrary
>>>>>>>>>>>>>> image:
>>>>>>>>>>>>>>     public Image getVariant(Image img, double dpi, number w,
>>>>>>>>>>>>>> number
>>>>>>>>>>>>>> h);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Since they would be in full control of the policy, 
>>>>>>>>>>>>>> though, we
>>>>>>>>>>>>>> would
>>>>>>>>>>>>>> unfortunately always have to call this, there would be no 
>>>>>>>>>>>>>> more
>>>>>>>>>>>>>> testing
>>>>>>>>>>>>>> in SG2D to see "if" we need to deal with DPI, though 
>>>>>>>>>>>>>> perhaps we
>>>>>>>>>>>>>> could
>>>>>>>>>>>>>> document some internal conditions in which we do not call it
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> common cases (but that would have to be well agreed not to
>>>>>>>>>>>>>> get in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> way of reasonable uses of the API and well documented)?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Note that we would have to do a security audit to make sure
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> random image substitution couldn't allow any sort of "screen
>>>>>>>>>>>>>> phishing"
>>>>>>>>>>>>>> exploit.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and also what policy they use for choosing scaled images.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I don't see a mention of taking the current transform into
>>>>>>>>>>>>>>>> account,
>>>>>>>>>>>>>>>> just physical issues like screen DPI and form factor. They
>>>>>>>>>>>>>>>> talk
>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>> resolution plateaus and in their recommendations 
>>>>>>>>>>>>>>>> section they
>>>>>>>>>>>>>>>> tell the
>>>>>>>>>>>>>>>> developer to use a particular property that tells them the
>>>>>>>>>>>>>>>> screen
>>>>>>>>>>>>>>>> resolution to figure out which image to load if they are
>>>>>>>>>>>>>>>> loading
>>>>>>>>>>>>>>>> manually.  There is no discussion about dynamically 
>>>>>>>>>>>>>>>> loading
>>>>>>>>>>>>>>>> multiple
>>>>>>>>>>>>>>>> versions of the image based on a dynamic program-applied
>>>>>>>>>>>>>>>> transform
>>>>>>>>>>>>>>>> factor as is done on MacOS.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Also, they tell developers to draw images to a specific 
>>>>>>>>>>>>>>>> size
>>>>>>>>>>>>>>>> rather
>>>>>>>>>>>>>>>> than using auto-sizing.  That begs the question as to how
>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>> interpret a call to draw an image just using a location in
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> presence of various DPI factors.
>>>>>>>>>>>>>>>       There is an interesting doc that describes how to 
>>>>>>>>>>>>>>> write
>>>>>>>>>>>>>>> DPI-aware
>>>>>>>>>>>>>>> Win32 applications:
>>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/dd464646%28v=vs.85%29.aspx 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>       It is suggested to handle WM_DPICHANGED message, load
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> graphic
>>>>>>>>>>>>>>> that has slightly greater resolution to the current DPI and
>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>> StretchBlt
>>>>>>>>>>>>>>>       to scale down the image.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>      Thanks,
>>>>>>>>>>>>>>>      Alexandr.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2/7/14 3:00 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>> On 1/22/2014 6:40 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>>> Hi Alexander,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Before we get too far down the road on this API, I 
>>>>>>>>>>>>>>>>>> think we
>>>>>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>>>>> the way in which MacOS processes multi-resolution images
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> HiDPI
>>>>>>>>>>>>>>>>>> screens, but have we investigated the processes that
>>>>>>>>>>>>>>>>>> Windows
>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>> under Windows 8?  My impression is that Windows 8 has
>>>>>>>>>>>>>>>>>> included a
>>>>>>>>>>>>>>>>>> number of new techniques for dealing with the high
>>>>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>>>>> displays
>>>>>>>>>>>>>>>>>> that it will run on in the Windows tablet and mobile
>>>>>>>>>>>>>>>>>> industries
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> that these will also come into play as 4K displays 
>>>>>>>>>>>>>>>>>> (already
>>>>>>>>>>>>>>>>>> available)
>>>>>>>>>>>>>>>>>> become more common on the desktop.  We should make sure
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> what we
>>>>>>>>>>>>>>>>>> come up with here can provide native compatibility with
>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>> platform's policies and standard practices.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If you've investigated the MS policies I'd like to see a
>>>>>>>>>>>>>>>>>> summary so
>>>>>>>>>>>>>>>>>> that we can consider them as we review this API...
>>>>>>>>>>>>>>>>>     There is the Windows Guidelines for scaling to pixel
>>>>>>>>>>>>>>>>> density:
>>>>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/hh465362.aspx 
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     which says that Windows has automatic resource 
>>>>>>>>>>>>>>>>> loading
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>> supports
>>>>>>>>>>>>>>>>> three version of images scaling (100%, 140%, and 180%)
>>>>>>>>>>>>>>>>> --------------------------------
>>>>>>>>>>>>>>>>> Without scaling, as the pixel density of a display device
>>>>>>>>>>>>>>>>> increases, the
>>>>>>>>>>>>>>>>> physical sizes of objects on screen get smaller.
>>>>>>>>>>>>>>>>> When UI would otherwise be too small to touch and when 
>>>>>>>>>>>>>>>>> text
>>>>>>>>>>>>>>>>> gets
>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>> small to read,
>>>>>>>>>>>>>>>>> Windows scales the system and app UI to one of the 
>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>> scaling
>>>>>>>>>>>>>>>>> plateaus:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>      1.0 (100%, no scaling is applied)
>>>>>>>>>>>>>>>>>      1.4 (140% scaling)
>>>>>>>>>>>>>>>>>      1.8 (180% scaling)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Windows determines which scaling plateau to use based 
>>>>>>>>>>>>>>>>> on the
>>>>>>>>>>>>>>>>> physical
>>>>>>>>>>>>>>>>> screen size, the screen resolution, the DPI of the
>>>>>>>>>>>>>>>>> screen, and
>>>>>>>>>>>>>>>>> form
>>>>>>>>>>>>>>>>> factor.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Use resource loading for bitmap images in the app package
>>>>>>>>>>>>>>>>> For
>>>>>>>>>>>>>>>>> bitmap
>>>>>>>>>>>>>>>>> images stored
>>>>>>>>>>>>>>>>> in the app package, provide a separate image for each
>>>>>>>>>>>>>>>>> scaling
>>>>>>>>>>>>>>>>> factor(100%, 140%, and 180%),
>>>>>>>>>>>>>>>>> and name your image files using the "scale" naming
>>>>>>>>>>>>>>>>> convention
>>>>>>>>>>>>>>>>> described
>>>>>>>>>>>>>>>>> below.
>>>>>>>>>>>>>>>>> Windows loads the right image for the current scale
>>>>>>>>>>>>>>>>> automatically.
>>>>>>>>>>>>>>>>> --------------------------------
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   The image name convention for the various scales is:
>>>>>>>>>>>>>>>>>     images/logo.scale-100.png
>>>>>>>>>>>>>>>>>     images/logo.scale-140.png
>>>>>>>>>>>>>>>>>     images/logo.scale-180.png
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>    The 'ms-appx:///images/logo.png' uri is used to 
>>>>>>>>>>>>>>>>> load the
>>>>>>>>>>>>>>>>> image
>>>>>>>>>>>>>>>>> in an
>>>>>>>>>>>>>>>>> application.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>    If we want to support this in the same way as it is 
>>>>>>>>>>>>>>>>> done
>>>>>>>>>>>>>>>>> for Mac
>>>>>>>>>>>>>>>>> OS X
>>>>>>>>>>>>>>>>>    the WToolkit should return MultiResolution image in
>>>>>>>>>>>>>>>>> case if
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> loaded image has .scale-* qualifiers.
>>>>>>>>>>>>>>>>>    The Graphics class can request an image with necessary
>>>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>>>> from the MultiResolution image.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>    It seems that nothing should be changed in the
>>>>>>>>>>>>>>>>> MultiResolution
>>>>>>>>>>>>>>>>> interface in this case.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     Thanks,
>>>>>>>>>>>>>>>>>     Alexandr.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 1/14/14 2:54 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>>>>>>>>>    bug: 
>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8029339
>>>>>>>>>>>>>>>>>>>    webrev:
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.00
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>    This is a proposal to introduce an API that 
>>>>>>>>>>>>>>>>>>> allows to
>>>>>>>>>>>>>>>>>>> create a
>>>>>>>>>>>>>>>>>>> custom
>>>>>>>>>>>>>>>>>>> multi resolution image.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I. It seems reasonable that the API should provide two
>>>>>>>>>>>>>>>>>>> basic
>>>>>>>>>>>>>>>>>>> operations:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>   1. Get the resolution variant based on the requested
>>>>>>>>>>>>>>>>>>> image
>>>>>>>>>>>>>>>>>>> width and
>>>>>>>>>>>>>>>>>>> height:
>>>>>>>>>>>>>>>>>>>      - Image getResolutionVariant(int width, int 
>>>>>>>>>>>>>>>>>>> height)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>     Usually the system provides the scale factor which
>>>>>>>>>>>>>>>>>>> represents
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> number of pixels corresponding to each linear unit 
>>>>>>>>>>>>>>>>>>> on the
>>>>>>>>>>>>>>>>>>> display.
>>>>>>>>>>>>>>>>>>>     However, it has sense to combine the scale 
>>>>>>>>>>>>>>>>>>> factor and
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>>> transformations to get the actual image size to be
>>>>>>>>>>>>>>>>>>> displayed.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>   2. Get all provided resolution variants:
>>>>>>>>>>>>>>>>>>>     - List<Image> getResolutionVariants()
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>    There are several uses cases:
>>>>>>>>>>>>>>>>>>>     - Create a new multi-resolution image based on the
>>>>>>>>>>>>>>>>>>> given
>>>>>>>>>>>>>>>>>>> multi-resolution image.
>>>>>>>>>>>>>>>>>>>     - Pass to the native system the multi-resolution
>>>>>>>>>>>>>>>>>>> image. For
>>>>>>>>>>>>>>>>>>> example,
>>>>>>>>>>>>>>>>>>> a use can set to the system the custom multi-resolution
>>>>>>>>>>>>>>>>>>> cursor.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> II. There are some possible ways where the new API 
>>>>>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>>>>> added
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>   1. java.awt.Image.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>    The 2 new methods can be added to the Image class. A
>>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>> override
>>>>>>>>>>>>>>>>>>>    the getResolutionVariant() and 
>>>>>>>>>>>>>>>>>>> getResolutionVariants()
>>>>>>>>>>>>>>>>>>> methods to
>>>>>>>>>>>>>>>>>>> provide the resolution variants
>>>>>>>>>>>>>>>>>>>    or there can be default implementations of these
>>>>>>>>>>>>>>>>>>> methods
>>>>>>>>>>>>>>>>>>> if a
>>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>> puts resolution variants
>>>>>>>>>>>>>>>>>>>    to the list in the sorted order.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>    To check that the image has resolution variants the
>>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>> statement can be used:
>>>>>>>>>>>>>>>>>>> image.getResolutionVariants().size()
>>>>>>>>>>>>>>>>>>> != 1
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>    The disadvantage is that there is an overhead 
>>>>>>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>>>>>>> Image
>>>>>>>>>>>>>>>>>>> class
>>>>>>>>>>>>>>>>>>> should contain the List object and not all
>>>>>>>>>>>>>>>>>>>    images can have resolution variants.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>   2. Introduce new MultiResolutionImage interface.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>    A user should extend Image class and implement the
>>>>>>>>>>>>>>>>>>> MultiResolutionImage interface.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>    For example:
>>>>>>>>>>>>>>>>>>>    ---------------------
>>>>>>>>>>>>>>>>>>>      public class CustomMultiResolutionImage extends
>>>>>>>>>>>>>>>>>>> BufferedImage
>>>>>>>>>>>>>>>>>>>              implements MultiResolutionImage {
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>          Image highResolutionImage;
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>          public 
>>>>>>>>>>>>>>>>>>> CustomMultiResolutionImage(BufferedImage
>>>>>>>>>>>>>>>>>>> baseImage,
>>>>>>>>>>>>>>>>>>>                  BufferedImage highResolutionImage) {
>>>>>>>>>>>>>>>>>>> super(baseImage.getWidth(),
>>>>>>>>>>>>>>>>>>> baseImage.getHeight(),
>>>>>>>>>>>>>>>>>>> baseImage.getType());
>>>>>>>>>>>>>>>>>>> this.highResolutionImage = highResolutionImage;
>>>>>>>>>>>>>>>>>>>              Graphics g = getGraphics();
>>>>>>>>>>>>>>>>>>> g.drawImage(baseImage, 0, 0, null);
>>>>>>>>>>>>>>>>>>>              g.dispose();
>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>          @Override
>>>>>>>>>>>>>>>>>>>          public Image getResolutionVariant(int 
>>>>>>>>>>>>>>>>>>> width, int
>>>>>>>>>>>>>>>>>>> height) {
>>>>>>>>>>>>>>>>>>>              return ((width <= getWidth() && height <=
>>>>>>>>>>>>>>>>>>> getHeight()))
>>>>>>>>>>>>>>>>>>>                      ? this : highResolutionImage;
>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>          @Override
>>>>>>>>>>>>>>>>>>>          public List<Image> getResolutionVariants() {
>>>>>>>>>>>>>>>>>>>              return Arrays.asList(this,
>>>>>>>>>>>>>>>>>>> highResolutionImage);
>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>    ---------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>   The current fix adds the MultiResolutionImage 
>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> public
>>>>>>>>>>>>>>>>>>> resolution variant rendering hints.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>



From anthony.petrov at oracle.com  Mon May 12 16:16:38 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 12 May 2014 20:16:38 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> Review request for 8034218: AIX:
 Provide a better fontconfig.properties file
In-Reply-To: <CA+3eh12cJpJBWPd1BXnSVTg0vziD66dP=y-RpXR5w5gsaO__Pw@mail.gmail.com>
References: <CAC-GWLfk5f0b=ufCcowDEvDyVuYFYkd2SUp9-0srLBh2r7gPDA@mail.gmail.com>
	<CA+3eh12cJpJBWPd1BXnSVTg0vziD66dP=y-RpXR5w5gsaO__Pw@mail.gmail.com>
Message-ID: <5370F3E6.1060209@oracle.com>

(adding in 2d-dev@ since fonts belong there)

--
best regards,
Anthony

On 5/12/2014 8:06 PM, Volker Simonis wrote:
> Hi Jonathan,
>
> thanks for submitting this patch.
>
> Overall it looks good, but I don't think we should reference the fonts
> under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties
> (at least not until IBM will not also contribute the corresponding
> fonts :)
>
> I would also find it helpful to keep a reworked version of the comment:
>
>    27 # Minimal version for AIX using the standard Latin Type1 Fonts from the
>    28 # package X11.fnt.iso_T1. These fonts are installed by default into
>    29 # "/usr/lpp/X11/lib/X11/fonts/Type1" and sym-linked to
> "/usr/lib/X11/fonts/Type1"
>
> which mentions which AIX packages provide the other referenced font files.
>
> Thank you and best regards,
> Volker
>
>
>
> On Mon, May 12, 2014 at 12:37 PM, Jonathan Lu <luchsh at linux.vnet.ibm.com> wrote:
>> Hi awt-dev,
>>
>> Please review the fix for issue:
>> https://bugs.openjdk.java.net/browse/JDK-8034218
>>
>> The changes are placed at
>> http://cr.openjdk.java.net/~luchsh/JDK-8034218/
>>
>> This patch is trying to provide a better fonctconfig.properties file for AIX
>> platform,
>> which contains support for more languages, like CJK.
>>
>>
>> Thanks
>> Jonathan
>>
>>


From philip.race at oracle.com  Mon May 12 16:42:15 2014
From: philip.race at oracle.com (Phil Race)
Date: Mon, 12 May 2014 09:42:15 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> Review request for 8034218: AIX:
 Provide a better fontconfig.properties file
In-Reply-To: <CA+3eh12cJpJBWPd1BXnSVTg0vziD66dP=y-RpXR5w5gsaO__Pw@mail.gmail.com>
References: <CAC-GWLfk5f0b=ufCcowDEvDyVuYFYkd2SUp9-0srLBh2r7gPDA@mail.gmail.com>
	<CA+3eh12cJpJBWPd1BXnSVTg0vziD66dP=y-RpXR5w5gsaO__Pw@mail.gmail.com>
Message-ID: <5370F9E7.8050109@oracle.com>

All,

If you want to continue this discussion i should be restarted on 2d-dev
and awt-dev removed. AWT has nothing to do with the fonts ..
I've fixed the bug sub-cat.

-phil.

On 05/12/2014 09:06 AM, Volker Simonis wrote:
> Hi Jonathan,
>
> thanks for submitting this patch.
>
> Overall it looks good, but I don't think we should reference the fonts
> under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties
> (at least not until IBM will not also contribute the corresponding
> fonts :)
>
> I would also find it helpful to keep a reworked version of the comment:
>
>    27 # Minimal version for AIX using the standard Latin Type1 Fonts from the
>    28 # package X11.fnt.iso_T1. These fonts are installed by default into
>    29 # "/usr/lpp/X11/lib/X11/fonts/Type1" and sym-linked to
> "/usr/lib/X11/fonts/Type1"
>
> which mentions which AIX packages provide the other referenced font files.
>
> Thank you and best regards,
> Volker
>
>
>
> On Mon, May 12, 2014 at 12:37 PM, Jonathan Lu <luchsh at linux.vnet.ibm.com> wrote:
>> Hi awt-dev,
>>
>> Please review the fix for issue:
>> https://bugs.openjdk.java.net/browse/JDK-8034218
>>
>> The changes are placed at
>> http://cr.openjdk.java.net/~luchsh/JDK-8034218/
>>
>> This patch is trying to provide a better fonctconfig.properties file for AIX
>> platform,
>> which contains support for more languages, like CJK.
>>
>>
>> Thanks
>> Jonathan
>>
>>



From philip.race at oracle.com  Mon May 12 16:47:27 2014
From: philip.race at oracle.com (Phil Race)
Date: Mon, 12 May 2014 09:47:27 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> Review request for 8034218: AIX:
 Provide a better fontconfig.properties file
In-Reply-To: <5370F9E7.8050109@oracle.com>
References: <CAC-GWLfk5f0b=ufCcowDEvDyVuYFYkd2SUp9-0srLBh2r7gPDA@mail.gmail.com>
	<CA+3eh12cJpJBWPd1BXnSVTg0vziD66dP=y-RpXR5w5gsaO__Pw@mail.gmail.com>
	<5370F9E7.8050109@oracle.com>
Message-ID: <5370FB1F.1070904@oracle.com>

removed awt-dev ...

 > I don't think we should reference the fonts
 > under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties

Volker is correct on this point.

Since OpenJDK can't ship those fonts we made sure they were never used
in any openjdk fontconfig file.

-phil.


On 05/12/2014 09:42 AM, Phil Race wrote:
> All,
>
> If you want to continue this discussion i should be restarted on 2d-dev
> and awt-dev removed. AWT has nothing to do with the fonts ..
> I've fixed the bug sub-cat.
>
> -phil.
>
> On 05/12/2014 09:06 AM, Volker Simonis wrote:
>> Hi Jonathan,
>>
>> thanks for submitting this patch.
>>
>> Overall it looks good, but I don't think we should reference the fonts
>> under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties
>> (at least not until IBM will not also contribute the corresponding
>> fonts :)
>>
>> I would also find it helpful to keep a reworked version of the comment:
>>
>>    27 # Minimal version for AIX using the standard Latin Type1 Fonts 
>> from the
>>    28 # package X11.fnt.iso_T1. These fonts are installed by default 
>> into
>>    29 # "/usr/lpp/X11/lib/X11/fonts/Type1" and sym-linked to
>> "/usr/lib/X11/fonts/Type1"
>>
>> which mentions which AIX packages provide the other referenced font 
>> files.
>>
>> Thank you and best regards,
>> Volker
>>
>>
>>
>> On Mon, May 12, 2014 at 12:37 PM, Jonathan Lu 
>> <luchsh at linux.vnet.ibm.com> wrote:
>>> Hi awt-dev,
>>>
>>> Please review the fix for issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8034218
>>>
>>> The changes are placed at
>>> http://cr.openjdk.java.net/~luchsh/JDK-8034218/
>>>
>>> This patch is trying to provide a better fonctconfig.properties file 
>>> for AIX
>>> platform,
>>> which contains support for more languages, like CJK.
>>>
>>>
>>> Thanks
>>> Jonathan
>>>
>>>
>



From linuxhippy at gmail.com  Mon May 12 19:17:21 2014
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Mon, 12 May 2014 21:17:21 +0200
Subject: [OpenJDK 2D-Dev] [PATCH] JDK-4627340 : RFE: A way to improve
 text printing performance for postscript devices (Improved proposal)
In-Reply-To: <53707554.1000301@4js.com>
References: <52F0CB37.4000902@4js.com>
	<53707554.1000301@4js.com>
Message-ID: <CAFvQSYQF=1r1LsE2dMAWD8+YpdPSNp5uEjeyt+7gkZhe_VPidQ@mail.gmail.com>

Hi Alex,

> now that my OCA has been processed I would like to bring to attention a proposal that
> I posted earlier this year to this group.
> And below a repost of the most recent version of the patch.

Glad to hear the OCA process did work out for you :)

> I don't know if anyone remembers but the idea of the patch is to use embedded Type 3 fonts in favor of glyph vectors in calls to Graphics2D.drawString().
> If required I can summarize the whole topic once more.

When I first read about your work I immediatly thought "what a cool
enhancement" :)
I don't have anything to add from the technical side, I just wanted
express my appreciation.
Thanks for working on this feature, I hope it will make it into the JDK.

Regards, Clemens


From Sergey.Bylokhov at oracle.com  Tue May 13 01:00:27 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 13 May 2014 05:00:27 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8041129 and 8017626
Message-ID: <53716EAB.90508@oracle.com>

Hello.
Please review the fix for jdk 9. This a second  iteration of the fix for 
8041129, because it was changed to cover 8017626 as well.

Description of the problem:
8041129: [OGL] surface->sw blit is extremely slow
  - The problem is in the glReadPixels(), which is really slow and we 
call it very often for each image to make a flip.
Solution:
  - We call glReadPixels() only once and then flip is done using memcpy 
after the whole image was moved from gpu to the memory.
  - glPixelStorei were added/removed when necessary.
  - Note: actually on my mac the slow path and the fast path(memcpy) 
works in the same time. I left it as is, because on other system it can 
be faster.

8017626: [OGL] Translucent VolatileImages don't paint correctly
  - The problem is in OGLSurfaceToSwBlit. It was implemented with 
assumption that the source(ogl) surface contain argb color format, this 
is wrong because it use premultiplied alpha.
Solution:
  - The new ogl blit was added to cover the old behavior 
OGLSurfaceToSwBlit(SurfaceType.IntArgbPre,OGLSurfaceData.PF_INT_ARGB_PRE),
  - The blit was changed to properly restore the color components if the 
source is transparent and destination does not use premultiplied alpha.

Bugs:
         https://bugs.openjdk.java.net/browse/JDK-8041129
         https://bugs.openjdk.java.net/browse/JDK-8017626
Webrev can be found at: http://cr.openjdk.java.net/~serb/8041129/webrev.10

Benchmarks:
Note that each benchmark was executed 3 times(25 seconds each) to be 
protected from such spread:
D3D-base-nvidia-windows: 61796.32109 (var=308.77%) (5857.64%)
|*************
|*********************************************************
|**************************************************
So check the full report for additional information, since the spread 
for most of the test is small.

==========================================================
Windows 7 x64, lenovo T410, nvidia NVS 3100M
http://cr.openjdk.java.net/~serb/8041129/webrev.10/benchmarks/results_win.txt
Summary:
   OGL-base-nvidia-windows:
     Number of tests:  40
     Overall average:  1538.6158105111376
     Best spread:      0.26% variance
     Worst spread:     51.66% variance
     (Basis for results comparison)

   D3D-base-nvidia-windows:
     Number of tests:  40
     Overall average:  25477.2292224911
     Best spread:      0.03% variance
     Worst spread:     308.77% variance
     Comparison to basis:
       Best result:      11192.65% of basis
       Worst result:     9.13% of basis
       Number of wins:   28
       Number of ties:   0
       Number of losses: 12

   OGL-fix-nvidia-windows:
     Number of tests:  40
     Overall average:  125053.84134106003
     Best spread:      0.08% variance
     Worst spread:     11.96% variance
     Comparison to basis:
       Best result:      12631.78% of basis
       Worst result:     84.45% of basis
       Number of wins:   33
       Number of ties:   6
       Number of losses: 1
==========================================================
OSX 10.8.5, macbook pro retina, nvidia GeForce GT 650M 1024 MB
http://cr.openjdk.java.net/~serb/8041129/webrev.10/benchmarks/results_osx_nvidia.txt
Summary:
   OGL-base-nvidia-osx:
     Number of tests:  20
     Overall average:  714.8688065382015
     Best spread:      0.16% variance
     Worst spread:     2.12% variance
     (Basis for results comparison)

   OGL-fix-nvidia-osx:
     Number of tests:  20
     Overall average:  10497.046970040716
     Best spread:      0.11% variance
     Worst spread:     5.55% variance
     Comparison to basis:
       Best result:      4479.08% of basis
       Worst result:     172.49% of basis
       Number of wins:   20
       Number of ties:   0
       Number of losses: 0
==========================================================
OSX 10.8.5, macbook pro retina, Intel HD Graphics 4000
http://cr.openjdk.java.net/~serb/8041129/webrev.10/benchmarks/results_osx_intel.txt
Summary:
   OGL-base-intel-osx:
     Number of tests:  20
     Overall average:  3912.1181498636274
     Best spread:      0.25% variance
     Worst spread:     22.52% variance
     (Basis for results comparison)

   OGL-fix-intel-osx:
     Number of tests:  20
     Overall average:  9647.033915964947
     Best spread:      0.2% variance
     Worst spread:     23.32% variance
     Comparison to basis:
       Best result:      457.06% of basis
       Worst result:     104.3% of basis
       Number of wins:   20
       Number of ties:   0
       Number of losses: 0

-- 
Best regards, Sergey.



From luchsh at linux.vnet.ibm.com  Tue May 13 02:06:15 2014
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Tue, 13 May 2014 10:06:15 +0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> Review request for 8034218: AIX:
 Provide a better fontconfig.properties file
In-Reply-To: <5370FB1F.1070904@oracle.com>
References: <CAC-GWLfk5f0b=ufCcowDEvDyVuYFYkd2SUp9-0srLBh2r7gPDA@mail.gmail.com>
	<CA+3eh12cJpJBWPd1BXnSVTg0vziD66dP=y-RpXR5w5gsaO__Pw@mail.gmail.com>
	<5370F9E7.8050109@oracle.com> <5370FB1F.1070904@oracle.com>
Message-ID: <CAC-GWLc79VLvEspuACAc_LeyJOYYLB368ECSLeEJ_t8T_-v+Lw@mail.gmail.com>

Hi Phil, Volker,

Thanks for your comments, but I noticed that JRE_LIB_FONTS has been
referred by the solaris fontconfig file,

jdk/make/data/fontconfig/solaris.fontconfig.properties

So I'm wondering if we can do this in the same way as Solaris platform.


Thanks
Jonathan



On Tue, May 13, 2014 at 12:47 AM, Phil Race <philip.race at oracle.com> wrote:

> removed awt-dev ...
>
>
> > I don't think we should reference the fonts
> > under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties
>
> Volker is correct on this point.
>
> Since OpenJDK can't ship those fonts we made sure they were never used
> in any openjdk fontconfig file.
>
> -phil.
>
>
>
> On 05/12/2014 09:42 AM, Phil Race wrote:
>
>> All,
>>
>> If you want to continue this discussion i should be restarted on 2d-dev
>> and awt-dev removed. AWT has nothing to do with the fonts ..
>> I've fixed the bug sub-cat.
>>
>> -phil.
>>
>> On 05/12/2014 09:06 AM, Volker Simonis wrote:
>>
>>> Hi Jonathan,
>>>
>>> thanks for submitting this patch.
>>>
>>> Overall it looks good, but I don't think we should reference the fonts
>>> under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties
>>> (at least not until IBM will not also contribute the corresponding
>>> fonts :)
>>>
>>> I would also find it helpful to keep a reworked version of the comment:
>>>
>>>    27 # Minimal version for AIX using the standard Latin Type1 Fonts
>>> from the
>>>    28 # package X11.fnt.iso_T1. These fonts are installed by default into
>>>    29 # "/usr/lpp/X11/lib/X11/fonts/Type1" and sym-linked to
>>> "/usr/lib/X11/fonts/Type1"
>>>
>>> which mentions which AIX packages provide the other referenced font
>>> files.
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>>
>>>
>>> On Mon, May 12, 2014 at 12:37 PM, Jonathan Lu <luchsh at linux.vnet.ibm.com>
>>> wrote:
>>>
>>>> Hi awt-dev,
>>>>
>>>> Please review the fix for issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8034218
>>>>
>>>> The changes are placed at
>>>> http://cr.openjdk.java.net/~luchsh/JDK-8034218/
>>>>
>>>> This patch is trying to provide a better fonctconfig.properties file
>>>> for AIX
>>>> platform,
>>>> which contains support for more languages, like CJK.
>>>>
>>>>
>>>> Thanks
>>>> Jonathan
>>>>
>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140513/34e42243/attachment.html>

From volker.simonis at gmail.com  Tue May 13 09:25:20 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 13 May 2014 11:25:20 +0200
Subject: [OpenJDK 2D-Dev] <AWT Dev> Review request for 8034218: AIX:
 Provide a better fontconfig.properties file
In-Reply-To: <CAC-GWLc79VLvEspuACAc_LeyJOYYLB368ECSLeEJ_t8T_-v+Lw@mail.gmail.com>
References: <CAC-GWLfk5f0b=ufCcowDEvDyVuYFYkd2SUp9-0srLBh2r7gPDA@mail.gmail.com>
	<CA+3eh12cJpJBWPd1BXnSVTg0vziD66dP=y-RpXR5w5gsaO__Pw@mail.gmail.com>
	<5370F9E7.8050109@oracle.com> <5370FB1F.1070904@oracle.com>
	<CAC-GWLc79VLvEspuACAc_LeyJOYYLB368ECSLeEJ_t8T_-v+Lw@mail.gmail.com>
Message-ID: <CA+3eh13kDJ+Yh90j7bXv1e2+1dXkBxqwiqmqG0cLkCw-rJLVvg@mail.gmail.com>

Hi Jonathan,

from all fontconfig files in make/data/fontconfig,
solaris.fontconfig.properties is the only file which contains a single
line referring to $JRE_LIB_FONTS. This is obviously a first-day bug
which should be fixed.

It simply makes no sense to define font files and default fonts with
references to files which won't be in a JDK for sure. Again, if you
could convince IBM to donate the corresponding fonts to the OpenJDK
that would be great. Otherwise these entries should be dropped from
the fontconfig files.

Thank you and best regards,
Volker


On Tue, May 13, 2014 at 4:06 AM, Jonathan Lu <luchsh at linux.vnet.ibm.com> wrote:
> Hi Phil, Volker,
>
> Thanks for your comments, but I noticed that JRE_LIB_FONTS has been referred
> by the solaris fontconfig file,
>
> jdk/make/data/fontconfig/solaris.fontconfig.properties
>
> So I'm wondering if we can do this in the same way as Solaris platform.
>
>
> Thanks
> Jonathan
>
>
>
> On Tue, May 13, 2014 at 12:47 AM, Phil Race <philip.race at oracle.com> wrote:
>>
>> removed awt-dev ...
>>
>>
>> > I don't think we should reference the fonts
>> > under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties
>>
>> Volker is correct on this point.
>>
>> Since OpenJDK can't ship those fonts we made sure they were never used
>> in any openjdk fontconfig file.
>>
>> -phil.
>>
>>
>>
>> On 05/12/2014 09:42 AM, Phil Race wrote:
>>>
>>> All,
>>>
>>> If you want to continue this discussion i should be restarted on 2d-dev
>>> and awt-dev removed. AWT has nothing to do with the fonts ..
>>> I've fixed the bug sub-cat.
>>>
>>> -phil.
>>>
>>> On 05/12/2014 09:06 AM, Volker Simonis wrote:
>>>>
>>>> Hi Jonathan,
>>>>
>>>> thanks for submitting this patch.
>>>>
>>>> Overall it looks good, but I don't think we should reference the fonts
>>>> under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties
>>>> (at least not until IBM will not also contribute the corresponding
>>>> fonts :)
>>>>
>>>> I would also find it helpful to keep a reworked version of the comment:
>>>>
>>>>    27 # Minimal version for AIX using the standard Latin Type1 Fonts
>>>> from the
>>>>    28 # package X11.fnt.iso_T1. These fonts are installed by default
>>>> into
>>>>    29 # "/usr/lpp/X11/lib/X11/fonts/Type1" and sym-linked to
>>>> "/usr/lib/X11/fonts/Type1"
>>>>
>>>> which mentions which AIX packages provide the other referenced font
>>>> files.
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>>
>>>>
>>>>
>>>> On Mon, May 12, 2014 at 12:37 PM, Jonathan Lu
>>>> <luchsh at linux.vnet.ibm.com> wrote:
>>>>>
>>>>> Hi awt-dev,
>>>>>
>>>>> Please review the fix for issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8034218
>>>>>
>>>>> The changes are placed at
>>>>> http://cr.openjdk.java.net/~luchsh/JDK-8034218/
>>>>>
>>>>> This patch is trying to provide a better fonctconfig.properties file
>>>>> for AIX
>>>>> platform,
>>>>> which contains support for more languages, like CJK.
>>>>>
>>>>>
>>>>> Thanks
>>>>> Jonathan
>>>>>
>>>>>
>>>
>>
>


From Sergey.Bylokhov at oracle.com  Tue May 13 11:10:53 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 13 May 2014 15:10:53 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> JDK-8041679 Replace uses of
 StringBuffer with StringBuilder within the JDK
In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com>
References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com>
Message-ID: <5371FDBD.9020002@oracle.com>

Hi, Paul.
adding 2d-dev@

media: sound/awt/swing part looks fine.
Note that this part of the fix should be pushed to client forest.

On 5/12/14 2:03 PM, Paul Sandoz wrote:
> Hi,
>
> This is a request for review of Otavio's patch replacing StringBuffer 
> with StringBuilder within OpenJDK. (I also need to review it.)
>
> It covers many areas and i have grouped the patches into such areas to 
> aid reviewing. When commenting please including core-libs.
>
> Jtreg tests showed no regressions, but when reviewing we need to be 
> mindful of the context e.g. if the buffer escapes and can cross thread 
> boundaries.
>
> This is also an experiment to see if we can review the whole thing 
> under one bug :-) if things prove problematic and slow we can split it 
> out. Many files are touched but there are not many changes to each 
> file and changes are very formulaic.
>
> I have also included ASM related changes, but i suspect we may have to 
> leave those alone since such changes will make it more difficult to 
> pull in ASM from upstream.
> -
>
> Otavio, for the record can you reply to this thread posting your 
> single ("uber") patch as textual attachment? (IIUC such attachments 
> should now be supported by the email server).
>
> Paul.
>
> - core
> http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ 
> <http://cr.openjdk.java.net/%7Epsandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/>
>
> - io
> http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ 
> <http://cr.openjdk.java.net/%7Epsandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/>
>
> - management
> http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ 
> <http://cr.openjdk.java.net/%7Epsandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/>
>
> - rmi
> http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ 
> <http://cr.openjdk.java.net/%7Epsandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/>
>
> - security
> http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ 
> <http://cr.openjdk.java.net/%7Epsandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/>
>
>
> - tools
> http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ 
> <http://cr.openjdk.java.net/%7Epsandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/>
>
>
> - graphics/media
> http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ 
> <http://cr.openjdk.java.net/%7Epsandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/>
>
>
> - asm
> http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ 
> <http://cr.openjdk.java.net/%7Epsandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140513/d01948d4/attachment.html>

From ag at 4js.com  Tue May 13 15:10:18 2014
From: ag at 4js.com (Alex Geller)
Date: Tue, 13 May 2014 17:10:18 +0200
Subject: [OpenJDK 2D-Dev] [PATCH] JDK-4627340 : RFE: A way to improve
 text printing performance for postscript devices (Improved proposal)
In-Reply-To: <CAFvQSYQF=1r1LsE2dMAWD8+YpdPSNp5uEjeyt+7gkZhe_VPidQ@mail.gmail.com>
References: <52F0CB37.4000902@4js.com>	<53707554.1000301@4js.com>
	<CAFvQSYQF=1r1LsE2dMAWD8+YpdPSNp5uEjeyt+7gkZhe_VPidQ@mail.gmail.com>
Message-ID: <537235DA.9030708@4js.com>

Thank you Clemens, I really appreciate your interest.
Regards,
Alex
On 5/12/2014 9:17 PM, Clemens Eisserer wrote:
> Hi Alex,
>
>> now that my OCA has been processed I would like to bring to attention a proposal that
>> I posted earlier this year to this group.
>> And below a repost of the most recent version of the patch.
> Glad to hear the OCA process did work out for you :)
>
>> I don't know if anyone remembers but the idea of the patch is to use embedded Type 3 fonts in favor of glyph vectors in calls to Graphics2D.drawString().
>> If required I can summarize the whole topic once more.
> When I first read about your work I immediatly thought "what a cool
> enhancement" :)
> I don't have anything to add from the technical side, I just wanted
> express my appreciation.
> Thanks for working on this feature, I hope it will make it into the JDK.
>
> Regards, Clemens



From anthony.petrov at oracle.com  Tue May 13 17:29:57 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 13 May 2014 21:29:57 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <53068600.80501@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com>
	<52B0F447.2020207@oracle.com> <52DE761E.2000201@oracle.com>
	<52E192F0.7010107@oracle.com> <52E27CDA.40703@oracle.com>
	<52E31866.3010508@oracle.com> <52E7CE5B.4070101@oracle.com>
	<52EAD304.2090809@oracle.com> <52EBB516.70906@oracle.com>
	<52EC4F5E.7060906@oracle.com> <52EFA980.6000404@oracle.com>
	<52F580C1.3020906@oracle.com> <52F8DE2A.4080304@oracle.com>
	<52F962CD.2050301@oracle.com> <52F96AE2.10106@oracle.com>
	<52FA67A8.1010600@oracle.com> <52FA7DCD.80405@oracle.com>
	<52FCC28D.5010007@oracle.com> <52FD4CB6.2090805@oracle.com>
	<52FDC1D1.8050907@oracle.com> <52FEBC4E.9010202@oracle.com>
	<5302182D.3070600@oracle.com> <53068600.80501@oracle.com>
Message-ID: <53725695.40209@oracle.com>

Hi Jim, Sergey, and Anton,

I'd like to revive this old thread and finally push this fix, which has 
been reviewed and approved on this mailing list back in February. The 
only additional change that I want to introduce, is the addition of 
default implementations for the LightweightContent.imageBufferReset() 
methods. This allows clients of the API (namely, JavaFX) to run with 
both the old and the new JDK w/o any changes or side-effects. Here's the 
updated webrev:

http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/

It literally only adds the default methods and doesn't make any other 
changes to the rest of the already reviewed code. I've tested this on 
both hiDPI and loDPI displays, with both old and hiDPI-aware JavaFX 
builds, and it works fine in all the cases.

The current plan is to push this fix to JDK 9, and then back-port the 
changes to 8u20.

--
best regards,
Anthony

On 2/21/2014 2:47 AM, Jim Graham wrote:
> Yes, approved.
>
>          ...jim
>
> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>> Jim, so this is ready for a push then.
>>
>> Thanks!
>> Anton.
>>
>> On 15.02.2014 5:01, Jim Graham wrote:
>>> I don't need to see an update for that.  I didn't read the entire
>>> webrev, but I looked at this one piece of code and if that was the
>>> only thing changed then I think that dealt with the outstanding
>>> issues...
>>>
>>>         ...jim
>>>
>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>
>>>>>
>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>> Hi Jim,
>>>>>>
>>>>>> Please, look at the update:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
>>>>>>
>>>>>> Here I'm correcting the rect after the transform in SG2D:
>>>>>>
>>>>>> 2123         // In case of negative scale transform, reflect the rect
>>>>>> coords.
>>>>>> 2124         if (w < 0) {
>>>>>> 2125             w *= -1;
>>>>>> 2126             x -= w;
>>>>>> 2127         }
>>>>>> 2128         if (h < 0) {
>>>>>> 2129             h *= -1;
>>>>>> 2130             y -= h;
>>>>>> 2131         }
>>>>>>
>>>>>>
>>>>>> The blit direction (dx, dy) remains transformed. Is this the right
>>>>>> behavior from your perspective?
>>>>>
>>>>> Yes, that looks good.  I wonder if the "w *= -1" results in a multiply
>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>
>>>>>             ...jim
>>>>
>>>> Jim,
>>>>
>>>> Yes, this indeed results in different byte code instructions (imult &
>>>> ineg). Just for curiosity I did some measuring which showed
>>>> negatioation
>>>> worked 10% faster :)
>>>> Well, I'll fix it but let me please not send an update...
>>>>
>>>> Thanks!
>>>> Anton.
>>>>
>>


From paul.sandoz at oracle.com  Tue May 13 13:51:21 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 13 May 2014 15:51:21 +0200
Subject: [OpenJDK 2D-Dev] <AWT Dev> JDK-8041679 Replace uses of
	StringBuffer with StringBuilder within the JDK
In-Reply-To: <5371FDBD.9020002@oracle.com>
References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com>
	<5371FDBD.9020002@oracle.com>
Message-ID: <0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com>


On May 13, 2014, at 1:10 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hi, Paul.
> adding 2d-dev@
> 
> media: sound/awt/swing part looks fine.

Thanks.


> Note that this part of the fix should be pushed to client forest.
> 

Which classes exactly from here:

  http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/

?

I am not familiar with the client integration process but from my perspective it does seem a little odd to have to do that.

Paul.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140513/58a1c151/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140513/58a1c151/signature.asc>

From gnu.andrew at redhat.com  Tue May 13 18:44:11 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 13 May 2014 14:44:11 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] Name clash when using the system libjpeg
In-Reply-To: <20140430200123.GA2584@redhat.com>
References: <20140429204133.GK2297@redhat.com>
	<832337748.12707274.1398867439773.JavaMail.zimbra@redhat.com>
	<536141EE.5090305@oracle.com> <20140430185253.GJ2047@redhat.com>
	<53614D63.3010407@oracle.com> <20140430200123.GA2584@redhat.com>
Message-ID: <18347826.4776932.1400006651782.JavaMail.zimbra@redhat.com>



----- Original Message -----
> * Phil Race <philip.race at oracle.com> [2014-04-30 15:22]:
> > On 4/30/2014 11:52 AM, Omair Majid wrote:
> > >
> > >In another thread, it was pointed out that j2 stands for "Java to". As
> > >in "Java to lcms".
> > Really ? That is not something that was obvious to me ..
> 
> I don't think it's obvious to anyone :)
> 
> I found out about it on this thread:
> http://mail.openjdk.java.net/pipermail/build-dev/2013-December/011325.html
> 

It was certainly a mystery to me until I saw that thread too. That's why
I went with javajpeg for IcedTea.

> > So we can try this .. but you'll need to
> > make sure you
> > catch all the APIs (inc splashscreen) that load this library.
> 
> Okay. Splashscreen is compiled/linked at build time, so that's easier to
> check. The Java side (since it uses JNI and is loaded dynamically) is
> easier to miss.
> 

Every version of OpenJDK 7 we've shipped (Red Hat) has done this so it should
be fine.  It's just a matter of porting it over to the new build.

> Thanks,
> Omair
> 
> --
> PGP Key: 66484681 (http://pgp.mit.edu/)
> Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From Sergey.Bylokhov at oracle.com  Tue May 13 18:57:27 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 13 May 2014 22:57:27 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <53725695.40209@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com>
	<52B0F447.2020207@oracle.com> <52DE761E.2000201@oracle.com>
	<52E192F0.7010107@oracle.com> <52E27CDA.40703@oracle.com>
	<52E31866.3010508@oracle.com> <52E7CE5B.4070101@oracle.com>
	<52EAD304.2090809@oracle.com> <52EBB516.70906@oracle.com>
	<52EC4F5E.7060906@oracle.com> <52EFA980.6000404@oracle.com>
	<52F580C1.3020906@oracle.com> <52F8DE2A.4080304@oracle.com>
	<52F962CD.2050301@oracle.com> <52F96AE2.10106@oracle.com>
	<52FA67A8.1010600@oracle.com> <52FA7DCD.80405@oracle.com>
	<52FCC28D.5010007@oracle.com> <52FD4CB6.2090805@oracle.com>
	<52FDC1D1.8050907@oracle.com> <52FEBC4E.9010202@oracle.com>
	<5302182D.3070600@oracle.com> <53068600.80501@oracle.com>
	<53725695.40209@oracle.com>
Message-ID: <53726B17.7030605@oracle.com>

On 5/13/14 9:29 PM, Anthony Petrov wrote:
> Hi Jim, Sergey, and Anton,
>
> I'd like to revive this old thread and finally push this fix, which 
> has been reviewed and approved on this mailing list back in February. 
> The only additional change that I want to introduce, is the addition 
> of default implementations for the 
> LightweightContent.imageBufferReset() methods. This allows clients of 
> the API (namely, JavaFX) to run with both the old and the new JDK w/o 
> any changes or side-effects. Here's the updated webrev:
Please do not push it, i'll try to decrease the changes. Will send an 
update tomorrow.
>
> http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/
>
> It literally only adds the default methods and doesn't make any other 
> changes to the rest of the already reviewed code. I've tested this on 
> both hiDPI and loDPI displays, with both old and hiDPI-aware JavaFX 
> builds, and it works fine in all the cases.
>
> The current plan is to push this fix to JDK 9, and then back-port the 
> changes to 8u20.
>
> -- 
> best regards,
> Anthony
>
> On 2/21/2014 2:47 AM, Jim Graham wrote:
>> Yes, approved.
>>
>>          ...jim
>>
>> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>>> Jim, so this is ready for a push then.
>>>
>>> Thanks!
>>> Anton.
>>>
>>> On 15.02.2014 5:01, Jim Graham wrote:
>>>> I don't need to see an update for that.  I didn't read the entire
>>>> webrev, but I looked at this one piece of code and if that was the
>>>> only thing changed then I think that dealt with the outstanding
>>>> issues...
>>>>
>>>>         ...jim
>>>>
>>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>>
>>>>>>
>>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>>> Hi Jim,
>>>>>>>
>>>>>>> Please, look at the update:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
>>>>>>>
>>>>>>> Here I'm correcting the rect after the transform in SG2D:
>>>>>>>
>>>>>>> 2123         // In case of negative scale transform, reflect the 
>>>>>>> rect
>>>>>>> coords.
>>>>>>> 2124         if (w < 0) {
>>>>>>> 2125             w *= -1;
>>>>>>> 2126             x -= w;
>>>>>>> 2127         }
>>>>>>> 2128         if (h < 0) {
>>>>>>> 2129             h *= -1;
>>>>>>> 2130             y -= h;
>>>>>>> 2131         }
>>>>>>>
>>>>>>>
>>>>>>> The blit direction (dx, dy) remains transformed. Is this the right
>>>>>>> behavior from your perspective?
>>>>>>
>>>>>> Yes, that looks good.  I wonder if the "w *= -1" results in a 
>>>>>> multiply
>>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>>
>>>>>>             ...jim
>>>>>
>>>>> Jim,
>>>>>
>>>>> Yes, this indeed results in different byte code instructions (imult &
>>>>> ineg). Just for curiosity I did some measuring which showed
>>>>> negatioation
>>>>> worked 10% faster :)
>>>>> Well, I'll fix it but let me please not send an update...
>>>>>
>>>>> Thanks!
>>>>> Anton.
>>>>>
>>>


-- 
Best regards, Sergey.



From philip.race at oracle.com  Tue May 13 19:59:07 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 13 May 2014 12:59:07 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> Request for review: 8026385:
 [macosx] (awt) setjmp/longjmp changes the process signal mask on OS X
In-Reply-To: <C6AFC617-0DEE-4892-BDA1-AC7B3809FE49@oracle.com>
References: <C6AFC617-0DEE-4892-BDA1-AC7B3809FE49@oracle.com>
Message-ID: <5372798B.1050103@oracle.com>



The JPEG code is 2d not awt ..

Apparently the root of this problem is
 > - longjmp will restore the signal mask using sigprocmask() which sets 
the signal mask for the _process_.

Hmm .. so anyone using a JNI lib that uses setjmp/longjmp would have the 
same issue.
Any place in the OS X libraries that end up using it would do the same ...
So I don't see how we can do a guaranteed fix here without knowing 
that.The change here :-
http://cr.openjdk.java.net/~ddehaven/8026385/jdk.0/src/share/native/sun/awt/libpng/png.h.sdiff.html

is to an upstream libpng and will likely get lost when libpng is next 
updated.
At the very least you will need to put some JDk specific comments here 
so its
blindlingly obvious when some one updates it that they are removing our
customisation.

Alternatively, (and maybe better)  is there any place that libpng looks for
any customisations you need to do ?



is

  ifdef __APPLE__

something that we (JDK) define or the OS X compiler defines ?
ie if we asked to push this upstream would they want something different ?

Of course I have no idea if 'upstream' would want our behaviour anyway ..

-phil.

On 5/13/2014 12:39 PM, David DeHaven wrote:
> JBS Issue:
> https://bugs.openjdk.java.net/browse/JDK-8026385
>
> Webrev:
> http://cr.openjdk.java.net/~ddehaven/8026385/jdk.0/
>
> Basically extends the work Staffan performed for https://bugs.openjdk.java.net/browse/JDK-8023786
>
> Verified by running:
> find build/macosx-x86_64-normal-server-fastdebug/jdk/objs -name '*.o' -exec nm -u {} \; | egrep '(setjmp|longjmp)'
>
> With this change, all references in jdk were __setjmp or __longjmp (two underscores), there are no remaining references to _setjmp/_longjmp in jdk with this change.
>
> -DrD-
>



From david.dehaven at oracle.com  Tue May 13 20:13:35 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 13 May 2014 13:13:35 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> Request for review: 8026385:
	[macosx] (awt) setjmp/longjmp changes the process signal mask
	on OS X
In-Reply-To: <5372798B.1050103@oracle.com>
References: <C6AFC617-0DEE-4892-BDA1-AC7B3809FE49@oracle.com>
	<5372798B.1050103@oracle.com>
Message-ID: <5A6B42D6-FCDC-4968-8D4C-F1CC777866F7@oracle.com>


> The JPEG code is 2d not awt ..

I was curious about that.


> Apparently the root of this problem is
> > - longjmp will restore the signal mask using sigprocmask() which sets the signal mask for the _process_.
> 
> Hmm .. so anyone using a JNI lib that uses setjmp/longjmp would have the same issue.
> Any place in the OS X libraries that end up using it would do the same ...
> So I don't see how we can do a guaranteed fix here without knowing that.

I don't see how we can guarantee anything when it comes to third party JNI code.


> The change here :-
> http://cr.openjdk.java.net/~ddehaven/8026385/jdk.0/src/share/native/sun/awt/libpng/png.h.sdiff.html
> 
> is to an upstream libpng and will likely get lost when libpng is next updated.
> At the very least you will need to put some JDk specific comments here so its
> blindlingly obvious when some one updates it that they are removing our
> customisation.
> 
> Alternatively, (and maybe better)  is there any place that libpng looks for
> any customisations you need to do ?

I tried not modifying libpng but still ended up with lingering references to longjmp in pngread.o, despite libpng having png_ptr->longjmp_fn (bug in libpng?). pngread.c calls setjmp to set a default location to jump to in case the caller doesn't call setjmp, so if we continue down this path something in libpng must be modified. The only other option is to create our own setjmp.h and order it before /usr/include/setjmp.h, which seems dubious at best.

I'm curious if the libpng changes are even needed since it's only used for splashscreen, which happens very early in the launch process. Also note that we didn't originally even call png_set_longjmp_fn, so any error should have resulted in an abort() instead of a call to longjmp... it appears we could retain the functionality we have today and #undef PNG_SETJMP_SUPPORTED (pngconf.h?). That would put the onus on developers to make sure their pngs don't have errors in them, or libsplashscreen will abort()...


> is
> 
> ifdef __APPLE__
> 
> something that we (JDK) define or the OS X compiler defines ?
> ie if we asked to push this upstream would they want something different ?

__APPLE__ is defined by all compilers provided by Apple (gcc, clang, I think it even pre-dates Mac OS X).


> Of course I have no idea if 'upstream' would want our behaviour anyway ..

I have my doubts.

-DrD-



From philip.race at oracle.com  Tue May 13 20:32:19 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 13 May 2014 13:32:19 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> Request for review: 8026385:
 [macosx] (awt) setjmp/longjmp changes the process signal mask on OS X
In-Reply-To: <5A6B42D6-FCDC-4968-8D4C-F1CC777866F7@oracle.com>
References: <C6AFC617-0DEE-4892-BDA1-AC7B3809FE49@oracle.com>
	<5372798B.1050103@oracle.com>
	<5A6B42D6-FCDC-4968-8D4C-F1CC777866F7@oracle.com>
Message-ID: <53728153.3070002@oracle.com>

On 5/13/2014 1:13 PM, David DeHaven wrote:
>
> I tried not modifying libpng but still ended up with lingering references to longjmp in pngread.o, despite libpng having png_ptr->longjmp_fn (bug in libpng?). pngread.c calls setjmp to set a default location to jump to in case the caller doesn't call setjmp, so if we continue down this path something in libpng must be modified. The only other option is to create our own setjmp.h and order it before /usr/include/setjmp.h, which seems dubious at best.
>
> I'm curious if the libpng changes are even needed since it's only used for splashscreen, which happens very early in the launch process. Also note that we didn't originally even call png_set_longjmp_fn, so any error should have resulted in an abort() instead of a call to longjmp... it appears we could retain the functionality we have today and #undef PNG_SETJMP_SUPPORTED (pngconf.h?). That would put the onus on developers to make sure their pngs don't have errors in them, or libsplashscreen will abort()...
>
>

That's an interesting question and the answer might extend to the 
splashscreen changes too.
Its platform specific code and on MAC, the thread is created using 
pthreads directly and that
thread goes away once splashscreen is done. But its running at the same 
time as the VM
is booting up and creating threads and setting their signal masks. So I 
don't think you can
guarantee that it won't mess up the masks on the JRE threads if the PNG 
is bad. And I'm
also not sure you want to remove error handling from the library either.
So a HIGHLY VISIBLE DO NOT REMOVE comment might be the best you can do here.

-phil.


From philip.race at oracle.com  Tue May 13 21:15:47 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 13 May 2014 14:15:47 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> JDK-8041679 Replace uses of
 StringBuffer with StringBuilder within the JDK
In-Reply-To: <0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com>
References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com>	<5371FDBD.9020002@oracle.com>
	<0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com>
Message-ID: <53728B83.1060307@oracle.com>

Paul,

I don't see why you changed the variable names in some cases.
See here where one change is only one line since you left it alone and 
the other is 6 lines since you changed it
http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/src/share/classes/javax/print/attribute/Size2DSyntax.java.sdiff.html
As it is, its just inconsistent and makes it less obvious to the eye 
that nothing unexpected changed.
And here what could have been a 2 line change is 25 ..
http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/src/share/classes/sun/font/StandardTextSource.java.sdiff.html
So I would say leave the variable names alone unless there's a 
compelling reason - and I don't see one.
Also pushing the 2D, AWT and Swing changes to client is requested as 
although your changes are
small its what is appropriate. I would not push hotspot changes to 
client either. Also lots of files
are being updated in client and doing it this way will minimise merges ...

-phil.



On 5/13/2014 6:51 AM, Paul Sandoz wrote:
>
> On May 13, 2014, at 1:10 PM, Sergey Bylokhov 
> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>
>> Hi, Paul.
>> adding 2d-dev@
>>
>> media: sound/awt/swing part looks fine.
>
> Thanks.
>
>
>> Note that this part of the fix should be pushed to client forest.
>>
>
> Which classes exactly from here:
>
> http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ 
> <http://cr.openjdk.java.net/%7Epsandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/>
>
> ?
>
> I am not familiar with the client integration process but from my 
> perspective it does seem a little odd to have to do that.
>
> Paul.
>



From david.dehaven at oracle.com  Tue May 13 21:56:23 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 13 May 2014 14:56:23 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> Request for review: 8026385:
	[macosx] (awt) setjmp/longjmp changes the process signal mask
	on OS X
In-Reply-To: <53728153.3070002@oracle.com>
References: <C6AFC617-0DEE-4892-BDA1-AC7B3809FE49@oracle.com>
	<5372798B.1050103@oracle.com>
	<5A6B42D6-FCDC-4968-8D4C-F1CC777866F7@oracle.com>
	<53728153.3070002@oracle.com>
Message-ID: <3E22C8BF-3F49-46F1-9565-45240DE28902@oracle.com>


>> I tried not modifying libpng but still ended up with lingering references to longjmp in pngread.o, despite libpng having png_ptr->longjmp_fn (bug in libpng?). pngread.c calls setjmp to set a default location to jump to in case the caller doesn't call setjmp, so if we continue down this path something in libpng must be modified. The only other option is to create our own setjmp.h and order it before /usr/include/setjmp.h, which seems dubious at best.
>> 
>> I'm curious if the libpng changes are even needed since it's only used for splashscreen, which happens very early in the launch process. Also note that we didn't originally even call png_set_longjmp_fn, so any error should have resulted in an abort() instead of a call to longjmp... it appears we could retain the functionality we have today and #undef PNG_SETJMP_SUPPORTED (pngconf.h?). That would put the onus on developers to make sure their pngs don't have errors in them, or libsplashscreen will abort()...
>> 
>> 
> 
> That's an interesting question and the answer might extend to the splashscreen changes too.
> Its platform specific code and on MAC, the thread is created using pthreads directly and that
> thread goes away once splashscreen is done. But its running at the same time as the VM
> is booting up and creating threads and setting their signal masks. So I don't think you can
> guarantee that it won't mess up the masks on the JRE threads if the PNG is bad. And I'm
> also not sure you want to remove error handling from the library either.
> So a HIGHLY VISIBLE DO NOT REMOVE comment might be the best you can do here.

I have a better idea:

png_default_error is the only place where png_longjmp is called. We could call png_set_error_fn to set up our own error handler (for Mac only), compile with PNG_SETJMP_SUPPORTED unset so it doesn't pull in setjmp/longjmp and our own implementation of the error handler would call _longjmp, which would jump back to where we call setjmp currently.

I still think a bad png will cause it to abort() with the code as written today... I could be wrong though. I need to track down a bad png to test with.

-DrD-



From david.dehaven at oracle.com  Wed May 14 06:30:06 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 13 May 2014 23:30:06 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> Request for review: 8026385:
	[macosx] (awt) setjmp/longjmp changes the process signal mask
	on OS X
In-Reply-To: <3E22C8BF-3F49-46F1-9565-45240DE28902@oracle.com>
References: <C6AFC617-0DEE-4892-BDA1-AC7B3809FE49@oracle.com>
	<5372798B.1050103@oracle.com>
	<5A6B42D6-FCDC-4968-8D4C-F1CC777866F7@oracle.com>
	<53728153.3070002@oracle.com>
	<3E22C8BF-3F49-46F1-9565-45240DE28902@oracle.com>
Message-ID: <EE677AB2-7CDE-4800-9AAB-C14A29CC4B3B@oracle.com>


>>> I tried not modifying libpng but still ended up with lingering references to longjmp in pngread.o, despite libpng having png_ptr->longjmp_fn (bug in libpng?). pngread.c calls setjmp to set a default location to jump to in case the caller doesn't call setjmp, so if we continue down this path something in libpng must be modified. The only other option is to create our own setjmp.h and order it before /usr/include/setjmp.h, which seems dubious at best.
>>> 
>>> I'm curious if the libpng changes are even needed since it's only used for splashscreen, which happens very early in the launch process. Also note that we didn't originally even call png_set_longjmp_fn, so any error should have resulted in an abort() instead of a call to longjmp... it appears we could retain the functionality we have today and #undef PNG_SETJMP_SUPPORTED (pngconf.h?). That would put the onus on developers to make sure their pngs don't have errors in them, or libsplashscreen will abort()...
>>> 
>>> 
>> 
>> That's an interesting question and the answer might extend to the splashscreen changes too.
>> Its platform specific code and on MAC, the thread is created using pthreads directly and that
>> thread goes away once splashscreen is done. But its running at the same time as the VM
>> is booting up and creating threads and setting their signal masks. So I don't think you can
>> guarantee that it won't mess up the masks on the JRE threads if the PNG is bad. And I'm
>> also not sure you want to remove error handling from the library either.
>> So a HIGHLY VISIBLE DO NOT REMOVE comment might be the best you can do here.
> 
> I have a better idea:
> 
> png_default_error is the only place where png_longjmp is called. We could call png_set_error_fn to set up our own error handler (for Mac only), compile with PNG_SETJMP_SUPPORTED unset so it doesn't pull in setjmp/longjmp and our own implementation of the error handler would call _longjmp, which would jump back to where we call setjmp currently.

Ok, I figured out what's going on. It's not quite intuitive...

png_jmpbuf is a macro defined in png.h, this calls png_set_longjmp_fn with longjmp, which is why I was seeing references to longjmp in the object file. That's what was throwing me off as it seems like it should only be getting the jmp_buf ptr stored in the png_ptr. I guess the intention was that setjmp/longjmp was optional, if you don't call setjmp then it just abort()s.


I changed splashscreen_png.c to:
#ifdef __APPLE__
    if (_setjmp(png_set_longjmp_fn(png_ptr, _longjmp, sizeof(jmp_buf)))) {
#else
    if (setjmp(png_jmpbuf(png_ptr))) {
#endif

and it calls _longjmp instead. I verified this works by changing the macro to set png_longjmp to exit() and without the above change it does indeed exit prematurely with a bad png, with the change it reports the error but continues to load the application as would be expected.

pngread.o still has a symbol table entry for _longjmp instead of __longjmp, but it's benign since we're ultimately forcing it to use the correct function. So I've left libpng completely unchanged.


With the change and using a bad png for splashscreen, I was able to get a stack trace once the application was running. Without the change to splashscreen_png.c, jstack was unable to connect to the process. So splashscreen absolutely can interfere with the signal handling.


Updated webrev:
http://cr.openjdk.java.net/~ddehaven/8026385/jdk.1/

I can look into writing a regression test for this. It might not be trivial though since we're dealing with signal handlers, and if timing is a factor the test may not be reliable.

-DrD-



From paul.sandoz at oracle.com  Wed May 14 08:15:55 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 14 May 2014 10:15:55 +0200
Subject: [OpenJDK 2D-Dev] <AWT Dev> JDK-8041679 Replace uses of
	StringBuffer with StringBuilder within the JDK
In-Reply-To: <53728B83.1060307@oracle.com>
References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com>	<5371FDBD.9020002@oracle.com>
	<0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com>
	<53728B83.1060307@oracle.com>
Message-ID: <8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com>

HI Phil,

Thanks for looking at this.

On May 13, 2014, at 11:15 PM, Phil Race <philip.race at oracle.com> wrote:

> Paul,
> 
> I don't see why you changed the variable names in some cases.

Note it's not me :-) I am, mostly, the proxy.


> See here where one change is only one line since you left it alone and the other is 6 lines since you changed it
> http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/src/share/classes/javax/print/attribute/Size2DSyntax.java.sdiff.html
> As it is, its just inconsistent and makes it less obvious to the eye that nothing unexpected changed.

That's a fair point.


> And here what could have been a 2 line change is 25 ..
> http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/src/share/classes/sun/font/StandardTextSource.java.sdiff.html
> So I would say leave the variable names alone unless there's a compelling reason - and I don't see one.

"buf" no longer corresponds to a buffer but to a builder, so i think it is reasonable in this case to use the canonical "sb" name.


> Also pushing the 2D, AWT and Swing changes to client is requested as although your changes are
> small its what is appropriate. I would not push hotspot changes to client either. Also lots of files
> are being updated in client and doing it this way will minimise merges ...

Although hotspot is a *separate* repository, there is a much clearer dividing line. 

This code is under src/share/classes, so it's not clear to me what classes i can modify and push in the jdk9-dev/jdk repo or not. It's confusing! Is there a list online somewhere?

Out of all the classes here:

  http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/

exactly which ones should be pushed to the client forest and which ones to the jdk9-dev forest? all of them, or just a sub-set?

How long would it take for the changes to the client jdk repo to make it's way into the jdk9-dev jdk repo?

Really what i am getting at here is i think we need to change our process of how we manage such forests; we need to consolidate.

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140514/98b04ff4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140514/98b04ff4/signature.asc>

From Alan.Bateman at oracle.com  Wed May 14 09:05:41 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 14 May 2014 10:05:41 +0100
Subject: [OpenJDK 2D-Dev] <AWT Dev> JDK-8041679 Replace uses of
 StringBuffer with StringBuilder within the JDK
In-Reply-To: <8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com>
References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com>	<5371FDBD.9020002@oracle.com>	<0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com>	<53728B83.1060307@oracle.com>
	<8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com>
Message-ID: <537331E5.4070108@oracle.com>

On 14/05/2014 09:15, Paul Sandoz wrote:
> :
>> And here what could have been a 2 line change is 25 ..
>> http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/src/share/classes/sun/font/StandardTextSource.java.sdiff.html
>> So I would say leave the variable names alone unless there's a compelling reason - and I don't see one.
> "buf" no longer corresponds to a buffer but to a builder, so i think it is reasonable in this case to use the canonical "sb" name.
I agree, "buf" or "buffer" looks odd when the type is changed to 
StringBuilder.


> :
>
> This code is under src/share/classes, so it's not clear to me what classes i can modify and push in the jdk9-dev/jdk repo or not. It's confusing! Is there a list online somewhere?
>
> Out of all the classes here:
>
>    http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/
>
> exactly which ones should be pushed to the client forest and which ones to the jdk9-dev forest? all of them, or just a sub-set?
>
> How long would it take for the changes to the client jdk repo to make it's way into the jdk9-dev jdk repo?
>
> Really what i am getting at here is i think we need to change our process of how we manage such forests; we need to consolidate.
>
I think Sergey and Phil are asking for the bean classes from -core patch 
and all of -media to be pushed to jdk9/client.

 From an approachability perspective then it's total baloney for library 
changes to take different routes. On the other hand there may be 
exceptions needed for areas or changes that involve manual or other 
special testing before integration. There was a lengthy thread on 
jdk9-dev about the integration forests and processes [1] where this was 
discussed. I don't recall seeing a boolean result to the questions that 
asked whether the client libraries require any manual testing before 
integration. As things stand then what we loosely call "client 
libraries" are pushed to jdk9/client, everything else is pushed to 
jdk9/dev. I really hope this can be re-visited soon.

-Alan

[1] 
http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-November/000000.html


From Sergey.Bylokhov at oracle.com  Wed May 14 14:11:01 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 14 May 2014 18:11:01 +0400
Subject: [OpenJDK 2D-Dev] [9] request for review: 6945174:
 IndexOutOfBoundsException calling ImageIO.read() on malformed PNG
In-Reply-To: <536C04ED.2090308@oracle.com>
References: <536BD03D.6040401@oracle.com> <536BFF8B.4030209@oracle.com>
	<536C04ED.2090308@oracle.com>
Message-ID: <53737975.5070109@oracle.com>

Hi, Andrew.
The fix looks good.

On 5/9/14 2:27 AM, Andrew Brygin wrote:
> Hello Phil,
>
>  I have corrected both occurrences of the typo:
>
> http://cr.openjdk.java.net/~bae/6945174/9/webrev.01/
>
> Thanks,
> Andrew
>
> On 5/9/2014 2:04 AM, Phil Race wrote:
>> Looks OK but please fix the typo in the exception string  .. lenght 
>> -> length
>>
>> -phil.
>>
>> On 5/8/14 11:43 AM, Andrew Brygin wrote:
>>> Hello,
>>>
>>> could you please review a fix for CR 6945174?
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6945174
>>> Webrev: http://cr.openjdk.java.net/~bae/6945174/9/webrev.00/
>>>
>>> PNG image reader validates the length of chunk's data
>>> when reads image metadata. However, if metadata is ignored,
>>> the length  is used to skip data in the stream without
>>> any validation.
>>>
>>> Suggested fix just introduces a validation of the chunk
>>> data length for the case of ignored metadata in a similar
>>> way as it is done for the case of metadata processing.
>>>
>>> Supplied regression test demonstrates the problem.
>>>
>>> Please take a look.
>>>
>>> Thanks,
>>> Andrew.
>>
>


-- 
Best regards, Sergey.



From philip.race at oracle.com  Wed May 14 17:09:59 2014
From: philip.race at oracle.com (Phil Race)
Date: Wed, 14 May 2014 10:09:59 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8042199 The build of
 J2DBench via makefile is broken after the JDK-8005402
In-Reply-To: <5360DAE7.8080204@oracle.com>
References: <5360DA85.5080202@oracle.com> <5360DAE7.8080204@oracle.com>
Message-ID: <5373A367.4040905@oracle.com>

Hmm .. the thing here is that I know that Jim was very keen that this 
benchmark always be runnable on JDK 1.2
Deleting the comment to that effect and setting source level to 1.5 goes 
against this.
What is the rationale, and why can't it be reverted to be able to build 
on 1.4 and run
on 1.2 ? If it uses JDK 1.5 language features, just back them out. If it 
uses JDK 1.5
APIs then maybe Jim had to handle something similar and has an idea ?

-phil.

On 4/30/2014 4:13 AM, Andrew Brygin wrote:
> Hello Sergey,
>
>  the change looks fine to me.
>
> Thanks,
> Andrew
>
> On 4/30/2014 3:12 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the small fix for jdk 9.
>> Makefile and README were fixed.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042199
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8042199/webrev.00
>>
>> -- 
>> Best regards, Sergey.
>



From david.dehaven at oracle.com  Thu May 15 16:31:06 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 15 May 2014 09:31:06 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> Request for review: 8026385:
	[macosx] (awt) setjmp/longjmp changes the process signal mask
	on OS X
In-Reply-To: <EE677AB2-7CDE-4800-9AAB-C14A29CC4B3B@oracle.com>
References: <C6AFC617-0DEE-4892-BDA1-AC7B3809FE49@oracle.com>
	<5372798B.1050103@oracle.com>
	<5A6B42D6-FCDC-4968-8D4C-F1CC777866F7@oracle.com>
	<53728153.3070002@oracle.com>
	<3E22C8BF-3F49-46F1-9565-45240DE28902@oracle.com>
	<EE677AB2-7CDE-4800-9AAB-C14A29CC4B3B@oracle.com>
Message-ID: <4B720DD6-DF4F-4F00-979E-E02DC0FD70E2@oracle.com>


Ping!

Does this look OK?

I've also filed an issue against JavaFX:
https://javafx-jira.kenai.com/browse/RT-37125

-DrD-

>>>> I tried not modifying libpng but still ended up with lingering references to longjmp in pngread.o, despite libpng having png_ptr->longjmp_fn (bug in libpng?). pngread.c calls setjmp to set a default location to jump to in case the caller doesn't call setjmp, so if we continue down this path something in libpng must be modified. The only other option is to create our own setjmp.h and order it before /usr/include/setjmp.h, which seems dubious at best.
>>>> 
>>>> I'm curious if the libpng changes are even needed since it's only used for splashscreen, which happens very early in the launch process. Also note that we didn't originally even call png_set_longjmp_fn, so any error should have resulted in an abort() instead of a call to longjmp... it appears we could retain the functionality we have today and #undef PNG_SETJMP_SUPPORTED (pngconf.h?). That would put the onus on developers to make sure their pngs don't have errors in them, or libsplashscreen will abort()...
>>>> 
>>>> 
>>> 
>>> That's an interesting question and the answer might extend to the splashscreen changes too.
>>> Its platform specific code and on MAC, the thread is created using pthreads directly and that
>>> thread goes away once splashscreen is done. But its running at the same time as the VM
>>> is booting up and creating threads and setting their signal masks. So I don't think you can
>>> guarantee that it won't mess up the masks on the JRE threads if the PNG is bad. And I'm
>>> also not sure you want to remove error handling from the library either.
>>> So a HIGHLY VISIBLE DO NOT REMOVE comment might be the best you can do here.
>> 
>> I have a better idea:
>> 
>> png_default_error is the only place where png_longjmp is called. We could call png_set_error_fn to set up our own error handler (for Mac only), compile with PNG_SETJMP_SUPPORTED unset so it doesn't pull in setjmp/longjmp and our own implementation of the error handler would call _longjmp, which would jump back to where we call setjmp currently.
> 
> Ok, I figured out what's going on. It's not quite intuitive...
> 
> png_jmpbuf is a macro defined in png.h, this calls png_set_longjmp_fn with longjmp, which is why I was seeing references to longjmp in the object file. That's what was throwing me off as it seems like it should only be getting the jmp_buf ptr stored in the png_ptr. I guess the intention was that setjmp/longjmp was optional, if you don't call setjmp then it just abort()s.
> 
> 
> I changed splashscreen_png.c to:
> #ifdef __APPLE__
>    if (_setjmp(png_set_longjmp_fn(png_ptr, _longjmp, sizeof(jmp_buf)))) {
> #else
>    if (setjmp(png_jmpbuf(png_ptr))) {
> #endif
> 
> and it calls _longjmp instead. I verified this works by changing the macro to set png_longjmp to exit() and without the above change it does indeed exit prematurely with a bad png, with the change it reports the error but continues to load the application as would be expected.
> 
> pngread.o still has a symbol table entry for _longjmp instead of __longjmp, but it's benign since we're ultimately forcing it to use the correct function. So I've left libpng completely unchanged.
> 
> 
> With the change and using a bad png for splashscreen, I was able to get a stack trace once the application was running. Without the change to splashscreen_png.c, jstack was unable to connect to the process. So splashscreen absolutely can interfere with the signal handling.
> 
> 
> Updated webrev:
> http://cr.openjdk.java.net/~ddehaven/8026385/jdk.1/
> 
> I can look into writing a regression test for this. It might not be trivial though since we're dealing with signal handlers, and if timing is a factor the test may not be reliable.
> 
> -DrD-
> 



From philip.race at oracle.com  Thu May 15 17:37:56 2014
From: philip.race at oracle.com (Phil Race)
Date: Thu, 15 May 2014 10:37:56 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> Request for review: 8026385:
 [macosx] (awt) setjmp/longjmp changes the process signal mask on OS X
In-Reply-To: <4B720DD6-DF4F-4F00-979E-E02DC0FD70E2@oracle.com>
References: <C6AFC617-0DEE-4892-BDA1-AC7B3809FE49@oracle.com>
	<5372798B.1050103@oracle.com>
	<5A6B42D6-FCDC-4968-8D4C-F1CC777866F7@oracle.com>
	<53728153.3070002@oracle.com>
	<3E22C8BF-3F49-46F1-9565-45240DE28902@oracle.com>
	<EE677AB2-7CDE-4800-9AAB-C14A29CC4B3B@oracle.com>
	<4B720DD6-DF4F-4F00-979E-E02DC0FD70E2@oracle.com>
Message-ID: <5374FB74.9040801@oracle.com>

Approved.

-phil.

On 5/15/2014 9:31 AM, David DeHaven wrote:
> Ping!
>
> Does this look OK?
>
> I've also filed an issue against JavaFX:
> https://javafx-jira.kenai.com/browse/RT-37125
>
> -DrD-
>
>>>>> I tried not modifying libpng but still ended up with lingering references to longjmp in pngread.o, despite libpng having png_ptr->longjmp_fn (bug in libpng?). pngread.c calls setjmp to set a default location to jump to in case the caller doesn't call setjmp, so if we continue down this path something in libpng must be modified. The only other option is to create our own setjmp.h and order it before /usr/include/setjmp.h, which seems dubious at best.
>>>>>
>>>>> I'm curious if the libpng changes are even needed since it's only used for splashscreen, which happens very early in the launch process. Also note that we didn't originally even call png_set_longjmp_fn, so any error should have resulted in an abort() instead of a call to longjmp... it appears we could retain the functionality we have today and #undef PNG_SETJMP_SUPPORTED (pngconf.h?). That would put the onus on developers to make sure their pngs don't have errors in them, or libsplashscreen will abort()...
>>>>>
>>>>>
>>>> That's an interesting question and the answer might extend to the splashscreen changes too.
>>>> Its platform specific code and on MAC, the thread is created using pthreads directly and that
>>>> thread goes away once splashscreen is done. But its running at the same time as the VM
>>>> is booting up and creating threads and setting their signal masks. So I don't think you can
>>>> guarantee that it won't mess up the masks on the JRE threads if the PNG is bad. And I'm
>>>> also not sure you want to remove error handling from the library either.
>>>> So a HIGHLY VISIBLE DO NOT REMOVE comment might be the best you can do here.
>>> I have a better idea:
>>>
>>> png_default_error is the only place where png_longjmp is called. We could call png_set_error_fn to set up our own error handler (for Mac only), compile with PNG_SETJMP_SUPPORTED unset so it doesn't pull in setjmp/longjmp and our own implementation of the error handler would call _longjmp, which would jump back to where we call setjmp currently.
>> Ok, I figured out what's going on. It's not quite intuitive...
>>
>> png_jmpbuf is a macro defined in png.h, this calls png_set_longjmp_fn with longjmp, which is why I was seeing references to longjmp in the object file. That's what was throwing me off as it seems like it should only be getting the jmp_buf ptr stored in the png_ptr. I guess the intention was that setjmp/longjmp was optional, if you don't call setjmp then it just abort()s.
>>
>>
>> I changed splashscreen_png.c to:
>> #ifdef __APPLE__
>>     if (_setjmp(png_set_longjmp_fn(png_ptr, _longjmp, sizeof(jmp_buf)))) {
>> #else
>>     if (setjmp(png_jmpbuf(png_ptr))) {
>> #endif
>>
>> and it calls _longjmp instead. I verified this works by changing the macro to set png_longjmp to exit() and without the above change it does indeed exit prematurely with a bad png, with the change it reports the error but continues to load the application as would be expected.
>>
>> pngread.o still has a symbol table entry for _longjmp instead of __longjmp, but it's benign since we're ultimately forcing it to use the correct function. So I've left libpng completely unchanged.
>>
>>
>> With the change and using a bad png for splashscreen, I was able to get a stack trace once the application was running. Without the change to splashscreen_png.c, jstack was unable to connect to the process. So splashscreen absolutely can interfere with the signal handling.
>>
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~ddehaven/8026385/jdk.1/
>>
>> I can look into writing a regression test for this. It might not be trivial though since we're dealing with signal handlers, and if timing is a factor the test may not be reliable.
>>
>> -DrD-
>>



From Sergey.Bylokhov at oracle.com  Thu May 15 17:57:55 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 15 May 2014 21:57:55 +0400
Subject: [OpenJDK 2D-Dev] [9] Review request for 8038000:
 java.awt.image.RasterFormatException: Incorrect scanline stride
In-Reply-To: <534E9470.3070901@oracle.com>
References: <53330FFF.7060009@oracle.com>	<5334B374.3090409@oracle.com>	<533ADD9F.50501@oracle.com>	<5346F064.9060600@oracle.com>
	<5347CCA4.4090907@oracle.com>	<534E93EA.9020509@oracle.com>
	<534E9470.3070901@oracle.com>
Message-ID: <53750023.4060000@oracle.com>

Hello, Anton.
The fix looks good.
Thanks.

On 16.04.2014 18:32, Andrew Brygin wrote:
> Hello Anton,
>
>  the fix looks fine to me.
>
> Thanks,
> Andrew
>
> On 4/16/2014 6:30 PM, anton nashatyrev wrote:
>> Hello Andrew,
>>
>>     you are right, the fix may be less relaxing but still conforming:
>>     if the height == 1, but the minY - sampleModelTranslateY > 0 the 
>> data buffer should still contain at least one scanline.
>>     Below is the updated fix. I've also added explicit check for 
>> implicit (minY - sampleModelTranslateY >= 0) constraint.
>>
>> http://cr.openjdk.java.net/%7Eanashaty/8038000/webrev.02/
>>
>> Thank you!
>> Anton.
>>
>> On 11.04.2014 15:06, Andrew Brygin wrote:
>>> Hello Anton,
>>>
>>>  we probably should use '(minY + height) > 1' as a condition for the
>>>  scanstride test, should not we?
>>>  Otherwise, we are not taking into account the case when minY is
>>>  greater than 0, and too big scanstride may be potentially dangerous.
>>>
>>> Thanks,
>>> Andrew
>>>
>>>
>>> On 4/10/2014 11:26 PM, anton nashatyrev wrote:
>>>> Hello,
>>>>
>>>>     could you please review a slightly update fix version (the 
>>>> regression test upgraded)
>>>> fix: http://cr.openjdk.java.net/%7Eanashaty/8038000/webrev.01/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8038000
>>>>
>>>> Jim, thanks for your in-depth analysis, the validation indeed 
>>>> doesn't look ideal. However my fix addresses the concrete 
>>>> regression which was introduced by these validations, so I'm 
>>>> leaving the fix as is.
>>>>
>>>> Thank you!
>>>> Anton.
>>>>
>>>> On 01.04.2014 19:39, anton nashatyrev wrote:
>>>>> Hello Jim,
>>>>>
>>>>> On 28.03.2014 3:25, Jim Graham wrote:
>>>>>> Hi Anton,
>>>>>>
>>>>>> A lot of those tests seem out of whack in that they test related 
>>>>>> conditions, but not the exact condition itself. What we really 
>>>>>> want is for every index of the form:
>>>>>>
>>>>>> offset + y * scanlineStride + x + {0 -> numcomponents-1} => [0, 
>>>>>> buf.length-1]
>>>>>>
>>>>>> to be in the array for all valid x,y.  There are a lot of tests 
>>>>>> there that are sufficient to prove this, but are overly 
>>>>>> restrictive in that they reject a bunch of cases.  The fix you 
>>>>>> propose only fixes this for a case where h=1, but what about:
>>>>>>
>>>>>>     w = 10
>>>>>>     h = 2
>>>>>>     numcomponents = 1
>>>>>>     scanlineStride = 1000
>>>>>>     buffer.length = 1010
>>>>>>
>>>>>> The buffer contains the data for all possible pixel fetches, but 
>>>>>> since it isn't 2000 in length, we reject it.
>>>>>
>>>>> My fix actually relaxes the condition, and the case above is not 
>>>>> rejected:
>>>>> (height > 1 && scanlineStride > data.length) is FALSE here and 
>>>>> hence the exception is not thrown
>>>>>
>>>>>>
>>>>>> Also, we restrict a bunch of parameters to "MAX_INT / some other 
>>>>>> factor" because we blindly multiply things out and don't want to 
>>>>>> deal with overflow, but a better "pixel array" test would use 
>>>>>> division (I think we do this in our native code):
>>>>>>
>>>>>>     buf.length / w <= h
>>>>>>
>>>>>> except that you need to deal with offset and scanlineStride for 
>>>>>> h-1 lines and then w for the last one, so this gets complicate, 
>>>>>> but you have:
>>>>>>
>>>>>>     ((buf.length - offset - w) / (h-1)) < scanlineStride
>>>>>>
>>>>>> but then you have to special case h=1 to avoid the divide by 0 so 
>>>>>> you get:
>>>>>>
>>>>>>     if (w <= 0 || h <= 0 || scanlineStride < 0 || offset < 0) 
>>>>>> exception;
>>>>>>     if (offset >= buf.length) exception;
>>>>>>     int len = buf.length - offset; // known positive
>>>>>>     if (len < w) exception;
>>>>>>     if (h > 1) {
>>>>>>          if (((len - w) / (h - 1)) < scanlineStride) exception;
>>>>>>     }
>>>>>>
>>>>>> Note that the test for (len < w) is done in all cases because it 
>>>>>> prevents the calculation in the "h>1" case from having a negative 
>>>>>> numerator, which would make the test invalid.  These tests are 
>>>>>> also valid for scan=0 for the rare case where someone wants every 
>>>>>> row of an image to contain the same data (we may use a case like 
>>>>>> that in the GIF loading code that needs to replicate incoming 
>>>>>> data for interlaced GIFs).  It doesn't go so far as to allow 
>>>>>> scan=-1 or similar cases where the user wants to play games with 
>>>>>> aliasing parts of rows in a backwards cascade.
>>>>>
>>>>> There are a lot of checks in the *Raster.verify() methods. I'm not 
>>>>> 100% confident but they look pretty equivalent to the algorithm 
>>>>> you have described (BTW the 0 scanline is also acceptable). 
>>>>> Anyways that was a security fix some time ago when some of those 
>>>>> validations have been added and I'm not sure we would like to 
>>>>> perform some major refactorings here unless any incompatibilities 
>>>>> are found.
>>>>>
>>>>> Thank you!
>>>>> Anton.
>>>>>
>>>>>>
>>>>>>             ...jim
>>>>>>
>>>>>> On 3/26/14 10:35 AM, anton nashatyrev wrote:
>>>>>>> Hello,
>>>>>>>      could you please review the following fix:
>>>>>>>
>>>>>>> fix: http://cr.openjdk.java.net/~anashaty/8038000/webrev.00/
>>>>>>> <http://cr.openjdk.java.net/%7Eanashaty/8038000/webrev.00/>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8038000
>>>>>>>
>>>>>>> The last row in the Raster shouldn't be necessary of the 
>>>>>>> scanlineStride
>>>>>>> length and thus the Raster with height 1 might have a buffer 
>>>>>>> smaller
>>>>>>> than a scanlineStride.
>>>>>>>
>>>>>>> Thanks!
>>>>>>> Anton.
>>>>>
>>>>
>>>
>>
>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140515/fc9f150c/attachment.html>

From joe.darcy at oracle.com  Thu May 15 19:07:15 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 15 May 2014 12:07:15 -0700
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8042864 : Fix raw and unchecked
	warnings in javax.print
Message-ID: <53751063.6070001@oracle.com>

Hello,

Please review these change to fix

     JDK-8042864 : Fix raw and unchecked warnings in javax.print
     http://cr.openjdk.java.net/~darcy/8042864.0/

Patch below.

Thanks,

-Joe

--- old/src/share/classes/javax/print/AttributeException.java 2014-05-15 
12:04:19.000000000 -0700
+++ new/src/share/classes/javax/print/AttributeException.java 2014-05-15 
12:04:19.000000000 -0700
@@ -52,7 +52,7 @@
       *
       * @return unsupported attribute classes
       */
-    public Class[] getUnsupportedAttributes();
+    public Class<?>[] getUnsupportedAttributes();

      /**
       * Returns the array of printing attributes for which the Print 
Service
--- old/src/share/classes/javax/print/DocFlavor.java    2014-05-15 
12:04:19.000000000 -0700
+++ new/src/share/classes/javax/print/DocFlavor.java    2014-05-15 
12:04:19.000000000 -0700
@@ -545,8 +545,7 @@
       * @exception NullPointerException if paramName is null.
       */
      public String getParameter(String paramName) {
-        return
- (String)myMimeType.getParameterMap().get(paramName.toLowerCase());
+        return myMimeType.getParameterMap().get(paramName.toLowerCase());
      }

      /**
--- old/src/share/classes/javax/print/MimeType.java    2014-05-15 
12:04:20.000000000 -0700
+++ new/src/share/classes/javax/print/MimeType.java    2014-05-15 
12:04:20.000000000 -0700
@@ -117,18 +117,18 @@
      /**
       * Parameter map entry.
       */
-    private class ParameterMapEntry implements Map.Entry {
+    private class ParameterMapEntry implements Map.Entry<String, String> {
          private int myIndex;
          public ParameterMapEntry(int theIndex) {
              myIndex = theIndex;
          }
-        public Object getKey(){
+        public String getKey(){
              return myPieces[myIndex];
          }
-        public Object getValue(){
+        public String getValue(){
              return myPieces[myIndex+1];
          }
-        public Object setValue (Object value) {
+        public String setValue (String value) {
              throw new UnsupportedOperationException();
          }
          public boolean equals(Object o) {
@@ -145,12 +145,12 @@
      /**
       * Parameter map entry set iterator.
       */
-    private class ParameterMapEntrySetIterator implements Iterator {
+    private class ParameterMapEntrySetIterator implements 
Iterator<Map.Entry<String, String>> {
          private int myIndex = 2;
          public boolean hasNext() {
              return myIndex < myPieces.length;
          }
-        public Object next() {
+        public Map.Entry<String, String> next() {
              if (hasNext()) {
                  ParameterMapEntry result = new ParameterMapEntry 
(myIndex);
                  myIndex += 2;
@@ -167,8 +167,8 @@
      /**
       * Parameter map entry set.
       */
-    private class ParameterMapEntrySet extends AbstractSet {
-        public Iterator iterator() {
+    private class ParameterMapEntrySet extends 
AbstractSet<Map.Entry<String, String>> {
+        public Iterator<Map.Entry<String, String>> iterator() {
              return new ParameterMapEntrySetIterator();
          }
          public int size() {
@@ -179,8 +179,8 @@
      /**
       * Parameter map.
       */
-    private class ParameterMap extends AbstractMap {
-        public Set entrySet() {
+    private class ParameterMap extends AbstractMap<String, String> {
+        public Set<Map.Entry<String, String>> entrySet() {
              if (myEntrySet == null) {
                  myEntrySet = new ParameterMapEntrySet();
              }
@@ -234,7 +234,7 @@
       *
       * @return  Parameter map for this MIME type object.
       */
-    public Map getParameterMap() {
+    public Map<String, String> getParameterMap() {
          if (myParameterMap == null) {
              myParameterMap = new ParameterMap();
          }
@@ -548,7 +548,7 @@
          }
          LexicalAnalyzer theLexer = new LexicalAnalyzer (s);
          int theLexemeType;
-        Vector thePieces = new Vector();
+        Vector<String> thePieces = new Vector<>();
          boolean mediaTypeIsText = false;
          boolean parameterNameIsCharset = false;

@@ -623,7 +623,7 @@

          // Save the pieces. Parameters are not in ascending order yet.
          int n = thePieces.size();
-        myPieces = (String[]) thePieces.toArray (new String [n]);
+        myPieces = thePieces.toArray (new String [n]);

          // Sort the parameters into ascending order using an insertion 
sort.
          int i, j;
--- old/src/share/classes/javax/print/PrintServiceLookup.java 2014-05-15 
12:04:20.000000000 -0700
+++ new/src/share/classes/javax/print/PrintServiceLookup.java 2014-05-15 
12:04:20.000000000 -0700
@@ -69,8 +69,8 @@
  public abstract class PrintServiceLookup {

      static class Services {
-        private ArrayList listOfLookupServices = null;
-        private ArrayList registeredServices = null;
+        private ArrayList<PrintServiceLookup> listOfLookupServices = null;
+        private ArrayList<PrintService> registeredServices = null;
      }

      private static Services getServicesForContext() {
@@ -83,23 +83,23 @@
          return services;
      }

-    private static ArrayList getListOfLookupServices() {
+    private static ArrayList<PrintServiceLookup> 
getListOfLookupServices() {
          return getServicesForContext().listOfLookupServices;
      }

-    private static ArrayList initListOfLookupServices() {
-        ArrayList listOfLookupServices = new ArrayList();
+    private static ArrayList<PrintServiceLookup> 
initListOfLookupServices() {
+        ArrayList<PrintServiceLookup> listOfLookupServices = new 
ArrayList<>();
          getServicesForContext().listOfLookupServices = 
listOfLookupServices;
          return listOfLookupServices;
      }


-    private static ArrayList getRegisteredServices() {
+    private static ArrayList<PrintService> getRegisteredServices() {
          return getServicesForContext().registeredServices;
      }

-    private static ArrayList initRegisteredServices() {
-        ArrayList registeredServices = new ArrayList();
+    private static ArrayList<PrintService> initRegisteredServices() {
+        ArrayList<PrintService> registeredServices = new ArrayList<>();
          getServicesForContext().registeredServices = registeredServices;
          return registeredServices;
      }
@@ -120,8 +120,8 @@
      public static final PrintService[]
          lookupPrintServices(DocFlavor flavor,
                              AttributeSet attributes) {
-        ArrayList list = getServices(flavor, attributes);
-        return (PrintService[])(list.toArray(new 
PrintService[list.size()]));
+        ArrayList<PrintService> list = getServices(flavor, attributes);
+        return list.toArray(new PrintService[list.size()]);
      }


@@ -148,9 +148,8 @@
      public static final MultiDocPrintService[]
          lookupMultiDocPrintServices(DocFlavor[] flavors,
                                      AttributeSet attributes) {
-        ArrayList list = getMultiDocServices(flavors, attributes);
-        return (MultiDocPrintService[])
-            list.toArray(new MultiDocPrintService[list.size()]);
+        ArrayList<MultiDocPrintService> list = 
getMultiDocServices(flavors, attributes);
+        return list.toArray(new MultiDocPrintService[list.size()]);
      }


@@ -177,10 +176,10 @@

      public static final PrintService lookupDefaultPrintService() {

-        Iterator psIterator = getAllLookupServices().iterator();
+        Iterator<PrintServiceLookup> psIterator = 
getAllLookupServices().iterator();
          while (psIterator.hasNext()) {
              try {
-                PrintServiceLookup lus = 
(PrintServiceLookup)psIterator.next();
+                PrintServiceLookup lus = psIterator.next();
                  PrintService service = lus.getDefaultPrintService();
                  if (service != null) {
                      return service;
@@ -208,7 +207,7 @@
       */
      public static boolean registerServiceProvider(PrintServiceLookup sp) {
          synchronized (PrintServiceLookup.class) {
-            Iterator psIterator = getAllLookupServices().iterator();
+            Iterator<?> psIterator = getAllLookupServices().iterator();
              while (psIterator.hasNext()) {
                  try {
                      Object lus = psIterator.next();
@@ -249,7 +248,7 @@
              if (service instanceof StreamPrintService) {
                  return false;
              }
-            ArrayList registeredServices = getRegisteredServices();
+            ArrayList<PrintService> registeredServices = 
getRegisteredServices();
              if (registeredServices == null) {
                  registeredServices = initRegisteredServices();
              }
@@ -326,9 +325,9 @@
       */
      public abstract PrintService getDefaultPrintService();

-    private static ArrayList getAllLookupServices() {
+    private static ArrayList<PrintServiceLookup> getAllLookupServices() {
          synchronized (PrintServiceLookup.class) {
-            ArrayList listOfLookupServices = getListOfLookupServices();
+            ArrayList<PrintServiceLookup> listOfLookupServices = 
getListOfLookupServices();
              if (listOfLookupServices != null) {
                  return listOfLookupServices;
              } else {
@@ -336,12 +335,12 @@
              }
              try {
                  java.security.AccessController.doPrivileged(
-                     new java.security.PrivilegedExceptionAction() {
+                     new 
java.security.PrivilegedExceptionAction<Object>() {
                          public Object run() {
                              Iterator<PrintServiceLookup> iterator =
ServiceLoader.load(PrintServiceLookup.class).
                                  iterator();
-                            ArrayList los = getListOfLookupServices();
+                            ArrayList<PrintServiceLookup> los = 
getListOfLookupServices();
                              while (iterator.hasNext()) {
                                  try {
                                      los.add(iterator.next());
@@ -364,14 +363,14 @@
          }
      }

-    private static ArrayList getServices(DocFlavor flavor,
-                                         AttributeSet attributes) {
+    private static ArrayList<PrintService> getServices(DocFlavor flavor,
+                                                       AttributeSet 
attributes) {

-        ArrayList listOfServices = new ArrayList();
-        Iterator psIterator = getAllLookupServices().iterator();
+        ArrayList<PrintService> listOfServices = new ArrayList<>();
+        Iterator<PrintServiceLookup> psIterator = 
getAllLookupServices().iterator();
          while (psIterator.hasNext()) {
              try {
-                PrintServiceLookup lus = 
(PrintServiceLookup)psIterator.next();
+                PrintServiceLookup lus = psIterator.next();
                  PrintService[] services=null;
                  if (flavor == null && attributes == null) {
                      try {
@@ -391,7 +390,7 @@
              }
          }
          /* add any directly registered services */
-        ArrayList registeredServices = null;
+        ArrayList<PrintService> registeredServices = null;
          try {
            SecurityManager security = System.getSecurityManager();
            if (security != null) {
@@ -401,8 +400,7 @@
          } catch (SecurityException se) {
          }
          if (registeredServices != null) {
-            PrintService[] services = (PrintService[])
-                registeredServices.toArray(
+            PrintService[] services = registeredServices.toArray(
                             new PrintService[registeredServices.size()]);
              for (int i=0; i<services.length; i++) {
                  if (!listOfServices.contains(services[i])) {
@@ -421,15 +419,15 @@
          return listOfServices;
      }

-    private static ArrayList getMultiDocServices(DocFlavor[] flavors,
-                                                 AttributeSet attributes) {
+    private static ArrayList<MultiDocPrintService> 
getMultiDocServices(DocFlavor[] flavors,
+ AttributeSet attributes) {


-        ArrayList listOfServices = new ArrayList();
-        Iterator psIterator = getAllLookupServices().iterator();
+        ArrayList<MultiDocPrintService> listOfServices = new ArrayList<>();
+        Iterator<PrintServiceLookup> psIterator = 
getAllLookupServices().iterator();
          while (psIterator.hasNext()) {
              try {
-                PrintServiceLookup lus = 
(PrintServiceLookup)psIterator.next();
+                PrintServiceLookup lus = psIterator.next();
                  MultiDocPrintService[] services  =
                      lus.getMultiDocPrintServices(flavors, attributes);
                  if (services == null) {
@@ -442,7 +440,7 @@
              }
          }
          /* add any directly registered services */
-        ArrayList registeredServices = null;
+        ArrayList<PrintService> registeredServices = null;
          try {
            SecurityManager security = System.getSecurityManager();
            if (security != null) {
@@ -452,14 +450,13 @@
          } catch (Exception e) {
          }
          if (registeredServices != null) {
-            PrintService[] services = (PrintService[])
-                registeredServices.toArray(
-                           new PrintService[registeredServices.size()]);
+            PrintService[] services =
+                registeredServices.toArray(new 
PrintService[registeredServices.size()]);
              for (int i=0; i<services.length; i++) {
                  if (services[i] instanceof MultiDocPrintService &&
                      !listOfServices.contains(services[i])) {
                      if (flavors == null || flavors.length == 0) {
-                        listOfServices.add(services[i]);
+ listOfServices.add((MultiDocPrintService)services[i]);
                      } else {
                          boolean supported = true;
                          for (int f=0; f<flavors.length; f++) {
@@ -476,7 +473,7 @@
                              }
                          }
                          if (supported) {
-                            listOfServices.add(services[i]);
+ listOfServices.add((MultiDocPrintService)services[i]);
                          }
                      }
                  }
--- old/src/share/classes/javax/print/ServiceUI.java    2014-05-15 
12:04:21.000000000 -0700
+++ new/src/share/classes/javax/print/ServiceUI.java    2014-05-15 
12:04:21.000000000 -0700
@@ -228,9 +228,9 @@

          if (dialog.getStatus() == ServiceDialog.APPROVE) {
              PrintRequestAttributeSet newas = dialog.getAttributes();
-            Class dstCategory = Destination.class;
-            Class amCategory = SunAlternateMedia.class;
-            Class fdCategory = Fidelity.class;
+            Class<?> dstCategory = Destination.class;
+            Class<?> amCategory = SunAlternateMedia.class;
+            Class<?> fdCategory = Fidelity.class;

              if (attributes.containsKey(dstCategory) &&
                  !newas.containsKey(dstCategory))
@@ -315,7 +315,7 @@
              Attribute[] usAttrs = asUnsupported.toArray();

              for (int i=0; i<usAttrs.length; i++) {
-                Class category = usAttrs[i].getCategory();
+                Class<? extends Attribute> category = 
usAttrs[i].getCategory();

                  if (ps.isAttributeCategorySupported(category)) {
                      Attribute attr =
--- old/src/share/classes/javax/print/SimpleDoc.java    2014-05-15 
12:04:21.000000000 -0700
+++ new/src/share/classes/javax/print/SimpleDoc.java    2014-05-15 
12:04:21.000000000 -0700
@@ -89,7 +89,7 @@
             throw new IllegalArgumentException("null argument(s)");
         }

-       Class repClass = null;
+       Class<?> repClass = null;
         try {
              String className = flavor.getRepresentationClassName();
sun.reflect.misc.ReflectUtil.checkPackageAccess(className);
--- old/src/share/classes/javax/print/StreamPrintServiceFactory.java 
2014-05-15 12:04:22.000000000 -0700
+++ new/src/share/classes/javax/print/StreamPrintServiceFactory.java 
2014-05-15 12:04:22.000000000 -0700
@@ -59,7 +59,7 @@
  public abstract class StreamPrintServiceFactory {

      static class Services {
-        private ArrayList listOfFactories = null;
+        private ArrayList<StreamPrintServiceFactory> listOfFactories = 
null;
      }

      private static Services getServices() {
@@ -72,12 +72,12 @@
          return services;
      }

-    private static ArrayList getListOfFactories() {
+    private static ArrayList<StreamPrintServiceFactory> 
getListOfFactories() {
          return getServices().listOfFactories;
      }

-    private static ArrayList initListOfFactories() {
-        ArrayList listOfFactories = new ArrayList();
+    private static ArrayList<StreamPrintServiceFactory> 
initListOfFactories() {
+        ArrayList<StreamPrintServiceFactory> listOfFactories = new 
ArrayList<>();
          getServices().listOfFactories = listOfFactories;
          return listOfFactories;
      }
@@ -108,9 +108,8 @@
           lookupStreamPrintServiceFactories(DocFlavor flavor,
                                             String outputMimeType) {

-         ArrayList list = getFactories(flavor, outputMimeType);
-         return (StreamPrintServiceFactory[])
-               (list.toArray(new StreamPrintServiceFactory[list.size()]));
+         ArrayList<StreamPrintServiceFactory> list = 
getFactories(flavor, outputMimeType);
+         return list.toArray(new StreamPrintServiceFactory[list.size()]);
       }

      /** Queries the factory for the document format that is emitted
@@ -162,10 +161,10 @@
      public abstract StreamPrintService getPrintService(OutputStream out);


-    private static ArrayList getAllFactories() {
+    private static ArrayList<StreamPrintServiceFactory> getAllFactories() {
          synchronized (StreamPrintServiceFactory.class) {

-          ArrayList listOfFactories = getListOfFactories();
+          ArrayList<StreamPrintServiceFactory> listOfFactories = 
getListOfFactories();
              if (listOfFactories != null) {
                  return listOfFactories;
              } else {
@@ -174,12 +173,12 @@

              try {
                  java.security.AccessController.doPrivileged(
-                     new java.security.PrivilegedExceptionAction() {
+                     new 
java.security.PrivilegedExceptionAction<Object>() {
                          public Object run() {
Iterator<StreamPrintServiceFactory> iterator =
                                  ServiceLoader.load
(StreamPrintServiceFactory.class).iterator();
-                            ArrayList lof = getListOfFactories();
+ ArrayList<StreamPrintServiceFactory> lof = getListOfFactories();
                              while (iterator.hasNext()) {
                                  try {
                                      lof.add(iterator.next());
@@ -210,17 +209,16 @@
          return false;
      }

-    private static ArrayList getFactories(DocFlavor flavor, String 
outType) {
+    private static ArrayList<StreamPrintServiceFactory> 
getFactories(DocFlavor flavor, String outType) {

          if (flavor == null && outType == null) {
              return getAllFactories();
          }

-        ArrayList list = new ArrayList();
-        Iterator iterator = getAllFactories().iterator();
+        ArrayList<StreamPrintServiceFactory> list = new ArrayList<>();
+        Iterator<StreamPrintServiceFactory> iterator = 
getAllFactories().iterator();
          while (iterator.hasNext()) {
-            StreamPrintServiceFactory factory =
-                (StreamPrintServiceFactory)iterator.next();
+            StreamPrintServiceFactory factory = iterator.next();
              if ((outType == null ||
outType.equalsIgnoreCase(factory.getOutputFormat())) &&
                  (flavor == null ||
--- 
old/src/share/classes/javax/print/attribute/AttributeSetUtilities.java 
2014-05-15 12:04:22.000000000 -0700
+++ 
new/src/share/classes/javax/print/attribute/AttributeSetUtilities.java 
2014-05-15 12:04:22.000000000 -0700
@@ -523,7 +523,7 @@
      public static Class<?>
          verifyAttributeCategory(Object object, Class<?> interfaceName) {

-        Class result = (Class) object;
+        Class<?> result = (Class) object;
          if (interfaceName.isAssignableFrom (result)) {
              return result;
          }
--- old/src/share/classes/javax/print/attribute/HashAttributeSet.java 
2014-05-15 12:04:23.000000000 -0700
+++ new/src/share/classes/javax/print/attribute/HashAttributeSet.java 
2014-05-15 12:04:23.000000000 -0700
@@ -48,13 +48,13 @@
       * or a subinterface thereof.
       * @serial
       */
-    private Class myInterface;
+    private Class<?> myInterface;

      /*
       * A HashMap used by the implementation.
       * The serialised form doesn't include this instance variable.
       */
-    private transient HashMap attrMap = new HashMap();
+    private transient HashMap<Class<?>, Attribute> attrMap = new 
HashMap<>();

      /**
       * Write the instance to a stream (ie serialize the object)
@@ -82,7 +82,7 @@
          throws ClassNotFoundException, IOException {

          s.defaultReadObject();
-        attrMap = new HashMap();
+        attrMap = new HashMap<>();
          int count = s.readInt();
          Attribute attr;
          for (int i = 0; i < count; i++) {
@@ -274,10 +274,9 @@
       *     Attribute Attribute}.
       */
      public Attribute get(Class<?> category) {
-        return (Attribute)
-            attrMap.get(AttributeSetUtilities.
-                        verifyAttributeCategory(category,
-                                                Attribute.class));
+        return attrMap.get(AttributeSetUtilities.
+                           verifyAttributeCategory(category,
+ Attribute.class));
      }

      /**
--- old/src/share/classes/javax/print/attribute/SetOfIntegerSyntax.java 
2014-05-15 12:04:23.000000000 -0700
+++ new/src/share/classes/javax/print/attribute/SetOfIntegerSyntax.java 
2014-05-15 12:04:23.000000000 -0700
@@ -112,7 +112,7 @@
      private static int[][] parse(String members) {
          // Create vector to hold int[] elements, each element being 
one range
          // parsed out of members.
-        Vector theRanges = new Vector();
+        Vector<int[]> theRanges = new Vector<>();

          // Run state machine over members.
          int n = (members == null ? 0 : members.length());
@@ -243,7 +243,7 @@
       * Accumulate the given range (lb .. ub) into the canonical array form
       * into the given vector of int[] objects.
       */
-    private static void accumulate(Vector ranges, int lb,int ub) {
+    private static void accumulate(Vector<int[]> ranges, int lb,int ub) {
          // Make sure range is non-null.
          if (lb <= ub) {
              // Stick range at the back of the vector.
@@ -253,10 +253,10 @@
              // with the existing ranges.
              for (int j = ranges.size()-2; j >= 0; -- j) {
              // Get lower and upper bounds of the two ranges being 
compared.
-                int[] rangea = (int[]) ranges.elementAt (j);
+                int[] rangea = ranges.elementAt (j);
                  int lba = rangea[0];
                  int uba = rangea[1];
-                int[] rangeb = (int[]) ranges.elementAt (j+1);
+                int[] rangeb = ranges.elementAt (j+1);
                  int lbb = rangeb[0];
                  int ubb = rangeb[1];

@@ -293,8 +293,8 @@
      /**
       * Convert the given vector of int[] objects to canonical array form.
       */
-    private static int[][] canonicalArrayForm(Vector ranges) {
-        return (int[][]) ranges.toArray (new int[ranges.size()][]);
+    private static int[][] canonicalArrayForm(Vector<int[]> ranges) {
+        return ranges.toArray (new int[ranges.size()][]);
      }

      /**
@@ -323,7 +323,7 @@
      private static int[][] parse(int[][] members) {
          // Create vector to hold int[] elements, each element being 
one range
          // parsed out of members.
-        Vector ranges = new Vector();
+        Vector<int[]> ranges = new Vector<>();

          // Process all integer groups in members.
          int n = (members == null ? 0 : members.length);
--- 
old/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java 
2014-05-15 12:04:24.000000000 -0700
+++ 
new/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java 
2014-05-15 12:04:23.000000000 -0700
@@ -110,7 +110,7 @@
       * @return  Printing attribute class (category), an instance of class
       *          {@link java.lang.Class java.lang.Class}.
       */
-    public final Class getCategory() {
+    public final Class<DialogTypeSelection> getCategory() {
          return DialogTypeSelection.class;
      }

--- old/src/share/classes/javax/print/attribute/standard/MediaSize.java 
2014-05-15 12:04:24.000000000 -0700
+++ new/src/share/classes/javax/print/attribute/standard/MediaSize.java 
2014-05-15 12:04:24.000000000 -0700
@@ -56,9 +56,9 @@

      private MediaSizeName mediaName;

-    private static HashMap mediaMap = new HashMap(100, 10);
+    private static HashMap<MediaSizeName, MediaSize> mediaMap = new 
HashMap<>(100, 10);

-    private static Vector sizeVector = new Vector(100, 10);
+    private static Vector<MediaSize> sizeVector = new Vector<>(100, 10);

      /**
       * Construct a new media size attribute from the given floating-point
@@ -174,7 +174,7 @@
       * with any size.
       */
      public static MediaSize getMediaSizeForName(MediaSizeName media) {
-        return (MediaSize)mediaMap.get(media);
+        return mediaMap.get(media);
      }

      /**
@@ -213,7 +213,7 @@
          float diffy = y;

          for (int i=0; i < sizeVector.size() ; i++) {
-            MediaSize mediaSize = (MediaSize)sizeVector.elementAt(i);
+            MediaSize mediaSize = sizeVector.elementAt(i);
              dim = mediaSize.getSize(units);
              if (x == dim[0] && y == dim[1]) {
                  match = mediaSize;
--- 
old/src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java 
2014-05-15 12:04:25.000000000 -0700
+++ 
new/src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java 
2014-05-15 12:04:24.000000000 -0700
@@ -242,16 +242,18 @@
          extends AbstractSet<PrinterStateReason>
      {
          private Severity mySeverity;
-        private Set myEntrySet;
+        //
+        private Set<Map.Entry<PrinterStateReason, Severity>> myEntrySet;

-        public PrinterStateReasonSet(Severity severity, Set entrySet) {
+        public PrinterStateReasonSet(Severity severity,
+ Set<Map.Entry<PrinterStateReason, Severity>> entrySet) {
              mySeverity = severity;
              myEntrySet = entrySet;
          }

          public int size() {
              int result = 0;
-            Iterator iter = iterator();
+            Iterator<?> iter = iterator();
              while (iter.hasNext()) {
                  iter.next();
                  ++ result;
@@ -259,19 +261,19 @@
              return result;
          }

-        public Iterator iterator() {
+        public Iterator<PrinterStateReason> iterator() {
              return new PrinterStateReasonSetIterator(mySeverity,
myEntrySet.iterator());
          }
      }

-    private class PrinterStateReasonSetIterator implements Iterator {
+    private class PrinterStateReasonSetIterator implements 
Iterator<PrinterStateReason> {
          private Severity mySeverity;
-        private Iterator myIterator;
-        private Map.Entry myEntry;
+        private Iterator<Map.Entry<PrinterStateReason, Severity>> 
myIterator;
+        private Map.Entry<PrinterStateReason, Severity> myEntry;

          public PrinterStateReasonSetIterator(Severity severity,
-                                             Iterator iterator) {
+ Iterator<Map.Entry<PrinterStateReason, Severity>> iterator) {
              mySeverity = severity;
              myIterator = iterator;
              goToNext();
@@ -280,8 +282,8 @@
          private void goToNext() {
              myEntry = null;
              while (myEntry == null && myIterator.hasNext()) {
-                myEntry = (Map.Entry) myIterator.next();
-                if ((Severity) myEntry.getValue() != mySeverity) {
+                myEntry = myIterator.next();
+                if (myEntry.getValue() != mySeverity) {
                      myEntry = null;
                  }
              }
@@ -291,11 +293,11 @@
              return myEntry != null;
          }

-        public Object next() {
+        public PrinterStateReason next() {
              if (myEntry == null) {
                  throw new NoSuchElementException();
              }
-            Object result = myEntry.getKey();
+            PrinterStateReason result = myEntry.getKey();
              goToNext();
              return result;
          }



From henry.jen at oracle.com  Thu May 15 22:46:40 2014
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 15 May 2014 15:46:40 -0700
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8042864 : Fix raw and
 unchecked warnings in javax.print
In-Reply-To: <53751063.6070001@oracle.com>
References: <53751063.6070001@oracle.com>
Message-ID: <537543D0.9010900@oracle.com>

On 05/15/2014 12:07 PM, Joe Darcy wrote:
> Hello,
>
> Please review these change to fix
>
>      JDK-8042864 : Fix raw and unchecked warnings in javax.print
>      http://cr.openjdk.java.net/~darcy/8042864.0/
>
> Patch below.

Looks good to me, just nit-picking.

>
> --- old/src/share/classes/javax/print/PrintServiceLookup.java 2014-05-15
> 12:04:20.000000000 -0700
> +++ new/src/share/classes/javax/print/PrintServiceLookup.java 2014-05-15
> 12:04:20.000000000 -0700
> @@ -208,7 +207,7 @@
>        */
>       public static boolean registerServiceProvider(PrintServiceLookup
> sp) {
>           synchronized (PrintServiceLookup.class) {
> -            Iterator psIterator = getAllLookupServices().iterator();
> +            Iterator<?> psIterator = getAllLookupServices().iterator();
>               while (psIterator.hasNext()) {
>                   try {
>                       Object lus = psIterator.next();

We know this is Iterator<PrinterServiceLookup>, but this works.

> ---
> old/src/share/classes/javax/print/attribute/AttributeSetUtilities.java
> 2014-05-15 12:04:22.000000000 -0700
> +++
> new/src/share/classes/javax/print/attribute/AttributeSetUtilities.java
> 2014-05-15 12:04:22.000000000 -0700
> @@ -523,7 +523,7 @@
>       public static Class<?>
>           verifyAttributeCategory(Object object, Class<?> interfaceName) {
>
> -        Class result = (Class) object;
> +        Class<?> result = (Class) object;
>           if (interfaceName.isAssignableFrom (result)) {
>               return result;
>           }

Should the cast be (Class<?>) instead of (Class)?

> ---
> old/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java
> 2014-05-15 12:04:24.000000000 -0700
> +++
> new/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java
> 2014-05-15 12:04:23.000000000 -0700
> @@ -110,7 +110,7 @@
>        * @return  Printing attribute class (category), an instance of class
>        *          {@link java.lang.Class java.lang.Class}.
>        */
> -    public final Class getCategory() {
> +    public final Class<DialogTypeSelection> getCategory() {
>           return DialogTypeSelection.class;
>       }
>

Would this be too specific for this public API? <? extends Attribute> is 
defined in interface Attribute.


> ---
> old/src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java
> 2014-05-15 12:04:25.000000000 -0700
> +++
> new/src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java
> 2014-05-15 12:04:24.000000000 -0700
> @@ -242,16 +242,18 @@
>           extends AbstractSet<PrinterStateReason>
>       {
>           private Severity mySeverity;
> -        private Set myEntrySet;
> +        //
> +        private Set<Map.Entry<PrinterStateReason, Severity>> myEntrySet;
>
> -        public PrinterStateReasonSet(Severity severity, Set entrySet) {
> +        public PrinterStateReasonSet(Severity severity,
> + Set<Map.Entry<PrinterStateReason, Severity>> entrySet) {
>               mySeverity = severity;
>               myEntrySet = entrySet;
>           }
>
>           public int size() {
>               int result = 0;
> -            Iterator iter = iterator();
> +            Iterator<?> iter = iterator();

We know it is Iterator<PrinterStateReason>.

>               while (iter.hasNext()) {
>                   iter.next();
>                   ++ result;

Cheers,
Henry


From joe.darcy at oracle.com  Fri May 16 01:06:32 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 15 May 2014 18:06:32 -0700
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8042864 : Fix raw and
 unchecked warnings in javax.print
In-Reply-To: <537543D0.9010900@oracle.com>
References: <53751063.6070001@oracle.com> <537543D0.9010900@oracle.com>
Message-ID: <53756498.2040805@oracle.com>

Hi Henry,

On 05/15/2014 03:46 PM, Henry Jen wrote:
> On 05/15/2014 12:07 PM, Joe Darcy wrote:
>> Hello,
>>
>> Please review these change to fix
>>
>>      JDK-8042864 : Fix raw and unchecked warnings in javax.print
>>      http://cr.openjdk.java.net/~darcy/8042864.0/
>>
>> Patch below.
>
> Looks good to me, just nit-picking.
>
>>
>> --- old/src/share/classes/javax/print/PrintServiceLookup.java 2014-05-15
>> 12:04:20.000000000 -0700
>> +++ new/src/share/classes/javax/print/PrintServiceLookup.java 2014-05-15
>> 12:04:20.000000000 -0700
>> @@ -208,7 +207,7 @@
>>        */
>>       public static boolean registerServiceProvider(PrintServiceLookup
>> sp) {
>>           synchronized (PrintServiceLookup.class) {
>> -            Iterator psIterator = getAllLookupServices().iterator();
>> +            Iterator<?> psIterator = getAllLookupServices().iterator();
>>               while (psIterator.hasNext()) {
>>                   try {
>>                       Object lus = psIterator.next();
>
> We know this is Iterator<PrinterServiceLookup>, but this works.

I can put the more precise type information in.

>
>> ---
>> old/src/share/classes/javax/print/attribute/AttributeSetUtilities.java
>> 2014-05-15 12:04:22.000000000 -0700
>> +++
>> new/src/share/classes/javax/print/attribute/AttributeSetUtilities.java
>> 2014-05-15 12:04:22.000000000 -0700
>> @@ -523,7 +523,7 @@
>>       public static Class<?>
>>           verifyAttributeCategory(Object object, Class<?> 
>> interfaceName) {
>>
>> -        Class result = (Class) object;
>> +        Class<?> result = (Class) object;
>>           if (interfaceName.isAssignableFrom (result)) {
>>               return result;
>>           }
>
> Should the cast be (Class<?>) instead of (Class)?

I think either is okay, but I'm fine to change this to Class<?>.

>
>> ---
>> old/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java 
>>
>> 2014-05-15 12:04:24.000000000 -0700
>> +++
>> new/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java 
>>
>> 2014-05-15 12:04:23.000000000 -0700
>> @@ -110,7 +110,7 @@
>>        * @return  Printing attribute class (category), an instance of 
>> class
>>        *          {@link java.lang.Class java.lang.Class}.
>>        */
>> -    public final Class getCategory() {
>> +    public final Class<DialogTypeSelection> getCategory() {
>>           return DialogTypeSelection.class;
>>       }
>>
>
> Would this be too specific for this public API? <? extends Attribute> 
> is defined in interface Attribute.

Well, the javadoc does say that DialogTypeSelection.class is returned. 
The DialogTypeSelection class does implement the Attribute interface so 
all the typing works out fine as-is.

>
>
>> ---
>> old/src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java 
>>
>> 2014-05-15 12:04:25.000000000 -0700
>> +++
>> new/src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java 
>>
>> 2014-05-15 12:04:24.000000000 -0700
>> @@ -242,16 +242,18 @@
>>           extends AbstractSet<PrinterStateReason>
>>       {
>>           private Severity mySeverity;
>> -        private Set myEntrySet;
>> +        //
>> +        private Set<Map.Entry<PrinterStateReason, Severity>> 
>> myEntrySet;
>>
>> -        public PrinterStateReasonSet(Severity severity, Set entrySet) {
>> +        public PrinterStateReasonSet(Severity severity,
>> + Set<Map.Entry<PrinterStateReason, Severity>> entrySet) {
>>               mySeverity = severity;
>>               myEntrySet = entrySet;
>>           }
>>
>>           public int size() {
>>               int result = 0;
>> -            Iterator iter = iterator();
>> +            Iterator<?> iter = iterator();
>
> We know it is Iterator<PrinterStateReason>.
>
>

That was less clear when I addressed the warning on that line, but the 
exact time works better.

Updated webrev uploaded to:

     http://cr.openjdk.java.net/~darcy/8042864.1

Thanks for the review,

-Joe



From paul.sandoz at oracle.com  Fri May 16 12:13:10 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 16 May 2014 14:13:10 +0200
Subject: [OpenJDK 2D-Dev] <AWT Dev> JDK-8041679 Replace uses of
	StringBuffer with StringBuilder within the JDK
In-Reply-To: <537331E5.4070108@oracle.com>
References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com>	<5371FDBD.9020002@oracle.com>	<0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com>	<53728B83.1060307@oracle.com>
	<8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com>
	<537331E5.4070108@oracle.com>
Message-ID: <007101BF-30BC-4761-A13A-0AE1EAD36DF5@oracle.com>

On May 14, 2014, at 11:05 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
>> :
>> 
>> This code is under src/share/classes, so it's not clear to me what classes i can modify and push in the jdk9-dev/jdk repo or not. It's confusing! Is there a list online somewhere?
>> 
>> Out of all the classes here:
>> 
>>   http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/
>> 
>> exactly which ones should be pushed to the client forest and which ones to the jdk9-dev forest? all of them, or just a sub-set?
>> 
>> How long would it take for the changes to the client jdk repo to make it's way into the jdk9-dev jdk repo?
>> 
>> Really what i am getting at here is i think we need to change our process of how we manage such forests; we need to consolidate.
>> 
> I think Sergey and Phil are asking for the bean classes from -core patch and all of -media to be pushed to jdk9/client.
> 

Thanks. Sergey/Phil can you confirm? 

Is there a white-list of packages available to determine which classes should be pushed to the client jdk repo rather than the dev jdk repo?

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140516/a4980261/signature.asc>

From david.dehaven at oracle.com  Fri May 16 15:18:36 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 16 May 2014 08:18:36 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> Request for review: 8026385:
	[macosx] (awt) setjmp/longjmp changes the process signal mask
	on OS X
In-Reply-To: <5374FB74.9040801@oracle.com>
References: <C6AFC617-0DEE-4892-BDA1-AC7B3809FE49@oracle.com>
	<5372798B.1050103@oracle.com>
	<5A6B42D6-FCDC-4968-8D4C-F1CC777866F7@oracle.com>
	<53728153.3070002@oracle.com>
	<3E22C8BF-3F49-46F1-9565-45240DE28902@oracle.com>
	<EE677AB2-7CDE-4800-9AAB-C14A29CC4B3B@oracle.com>
	<4B720DD6-DF4F-4F00-979E-E02DC0FD70E2@oracle.com>
	<5374FB74.9040801@oracle.com>
Message-ID: <504FD4A5-0921-4C49-87BA-64DF4D905F5D@oracle.com>


Could someone on AWT team approve the splashscreen changes?

-DrD-

> Approved.
> 
> -phil.
> 
> On 5/15/2014 9:31 AM, David DeHaven wrote:
>> Ping!
>> 
>> Does this look OK?
>> 
>> I've also filed an issue against JavaFX:
>> https://javafx-jira.kenai.com/browse/RT-37125
>> 
>> -DrD-
>> 
>>>>>> I tried not modifying libpng but still ended up with lingering references to longjmp in pngread.o, despite libpng having png_ptr->longjmp_fn (bug in libpng?). pngread.c calls setjmp to set a default location to jump to in case the caller doesn't call setjmp, so if we continue down this path something in libpng must be modified. The only other option is to create our own setjmp.h and order it before /usr/include/setjmp.h, which seems dubious at best.
>>>>>> 
>>>>>> I'm curious if the libpng changes are even needed since it's only used for splashscreen, which happens very early in the launch process. Also note that we didn't originally even call png_set_longjmp_fn, so any error should have resulted in an abort() instead of a call to longjmp... it appears we could retain the functionality we have today and #undef PNG_SETJMP_SUPPORTED (pngconf.h?). That would put the onus on developers to make sure their pngs don't have errors in them, or libsplashscreen will abort()...
>>>>>> 
>>>>>> 
>>>>> That's an interesting question and the answer might extend to the splashscreen changes too.
>>>>> Its platform specific code and on MAC, the thread is created using pthreads directly and that
>>>>> thread goes away once splashscreen is done. But its running at the same time as the VM
>>>>> is booting up and creating threads and setting their signal masks. So I don't think you can
>>>>> guarantee that it won't mess up the masks on the JRE threads if the PNG is bad. And I'm
>>>>> also not sure you want to remove error handling from the library either.
>>>>> So a HIGHLY VISIBLE DO NOT REMOVE comment might be the best you can do here.
>>>> I have a better idea:
>>>> 
>>>> png_default_error is the only place where png_longjmp is called. We could call png_set_error_fn to set up our own error handler (for Mac only), compile with PNG_SETJMP_SUPPORTED unset so it doesn't pull in setjmp/longjmp and our own implementation of the error handler would call _longjmp, which would jump back to where we call setjmp currently.
>>> Ok, I figured out what's going on. It's not quite intuitive...
>>> 
>>> png_jmpbuf is a macro defined in png.h, this calls png_set_longjmp_fn with longjmp, which is why I was seeing references to longjmp in the object file. That's what was throwing me off as it seems like it should only be getting the jmp_buf ptr stored in the png_ptr. I guess the intention was that setjmp/longjmp was optional, if you don't call setjmp then it just abort()s.
>>> 
>>> 
>>> I changed splashscreen_png.c to:
>>> #ifdef __APPLE__
>>>    if (_setjmp(png_set_longjmp_fn(png_ptr, _longjmp, sizeof(jmp_buf)))) {
>>> #else
>>>    if (setjmp(png_jmpbuf(png_ptr))) {
>>> #endif
>>> 
>>> and it calls _longjmp instead. I verified this works by changing the macro to set png_longjmp to exit() and without the above change it does indeed exit prematurely with a bad png, with the change it reports the error but continues to load the application as would be expected.
>>> 
>>> pngread.o still has a symbol table entry for _longjmp instead of __longjmp, but it's benign since we're ultimately forcing it to use the correct function. So I've left libpng completely unchanged.
>>> 
>>> 
>>> With the change and using a bad png for splashscreen, I was able to get a stack trace once the application was running. Without the change to splashscreen_png.c, jstack was unable to connect to the process. So splashscreen absolutely can interfere with the signal handling.
>>> 
>>> 
>>> Updated webrev:
>>> http://cr.openjdk.java.net/~ddehaven/8026385/jdk.1/
>>> 
>>> I can look into writing a regression test for this. It might not be trivial though since we're dealing with signal handlers, and if timing is a factor the test may not be reliable.
>>> 
>>> -DrD-
>>> 
> 



From anthony.petrov at oracle.com  Fri May 16 15:30:34 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 16 May 2014 19:30:34 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> Request for review: 8026385:
 [macosx] (awt) setjmp/longjmp changes the process signal mask on OS X
In-Reply-To: <504FD4A5-0921-4C49-87BA-64DF4D905F5D@oracle.com>
References: <C6AFC617-0DEE-4892-BDA1-AC7B3809FE49@oracle.com>	<5372798B.1050103@oracle.com>	<5A6B42D6-FCDC-4968-8D4C-F1CC777866F7@oracle.com>	<53728153.3070002@oracle.com>	<3E22C8BF-3F49-46F1-9565-45240DE28902@oracle.com>	<EE677AB2-7CDE-4800-9AAB-C14A29CC4B3B@oracle.com>	<4B720DD6-DF4F-4F00-979E-E02DC0FD70E2@oracle.com>	<5374FB74.9040801@oracle.com>
	<504FD4A5-0921-4C49-87BA-64DF4D905F5D@oracle.com>
Message-ID: <53762F1A.5030604@oracle.com>

The splashscreen changes look fine to me. Approved.

--
best regards,
Anthony

On 5/16/2014 7:18 PM, David DeHaven wrote:
>
> Could someone on AWT team approve the splashscreen changes?
>
> -DrD-
>
>> Approved.
>>
>> -phil.
>>
>> On 5/15/2014 9:31 AM, David DeHaven wrote:
>>> Ping!
>>>
>>> Does this look OK?
>>>
>>> I've also filed an issue against JavaFX:
>>> https://javafx-jira.kenai.com/browse/RT-37125
>>>
>>> -DrD-
>>>
>>>>>>> I tried not modifying libpng but still ended up with lingering references to longjmp in pngread.o, despite libpng having png_ptr->longjmp_fn (bug in libpng?). pngread.c calls setjmp to set a default location to jump to in case the caller doesn't call setjmp, so if we continue down this path something in libpng must be modified. The only other option is to create our own setjmp.h and order it before /usr/include/setjmp.h, which seems dubious at best.
>>>>>>>
>>>>>>> I'm curious if the libpng changes are even needed since it's only used for splashscreen, which happens very early in the launch process. Also note that we didn't originally even call png_set_longjmp_fn, so any error should have resulted in an abort() instead of a call to longjmp... it appears we could retain the functionality we have today and #undef PNG_SETJMP_SUPPORTED (pngconf.h?). That would put the onus on developers to make sure their pngs don't have errors in them, or libsplashscreen will abort()...
>>>>>>>
>>>>>>>
>>>>>> That's an interesting question and the answer might extend to the splashscreen changes too.
>>>>>> Its platform specific code and on MAC, the thread is created using pthreads directly and that
>>>>>> thread goes away once splashscreen is done. But its running at the same time as the VM
>>>>>> is booting up and creating threads and setting their signal masks. So I don't think you can
>>>>>> guarantee that it won't mess up the masks on the JRE threads if the PNG is bad. And I'm
>>>>>> also not sure you want to remove error handling from the library either.
>>>>>> So a HIGHLY VISIBLE DO NOT REMOVE comment might be the best you can do here.
>>>>> I have a better idea:
>>>>>
>>>>> png_default_error is the only place where png_longjmp is called. We could call png_set_error_fn to set up our own error handler (for Mac only), compile with PNG_SETJMP_SUPPORTED unset so it doesn't pull in setjmp/longjmp and our own implementation of the error handler would call _longjmp, which would jump back to where we call setjmp currently.
>>>> Ok, I figured out what's going on. It's not quite intuitive...
>>>>
>>>> png_jmpbuf is a macro defined in png.h, this calls png_set_longjmp_fn with longjmp, which is why I was seeing references to longjmp in the object file. That's what was throwing me off as it seems like it should only be getting the jmp_buf ptr stored in the png_ptr. I guess the intention was that setjmp/longjmp was optional, if you don't call setjmp then it just abort()s.
>>>>
>>>>
>>>> I changed splashscreen_png.c to:
>>>> #ifdef __APPLE__
>>>>     if (_setjmp(png_set_longjmp_fn(png_ptr, _longjmp, sizeof(jmp_buf)))) {
>>>> #else
>>>>     if (setjmp(png_jmpbuf(png_ptr))) {
>>>> #endif
>>>>
>>>> and it calls _longjmp instead. I verified this works by changing the macro to set png_longjmp to exit() and without the above change it does indeed exit prematurely with a bad png, with the change it reports the error but continues to load the application as would be expected.
>>>>
>>>> pngread.o still has a symbol table entry for _longjmp instead of __longjmp, but it's benign since we're ultimately forcing it to use the correct function. So I've left libpng completely unchanged.
>>>>
>>>>
>>>> With the change and using a bad png for splashscreen, I was able to get a stack trace once the application was running. Without the change to splashscreen_png.c, jstack was unable to connect to the process. So splashscreen absolutely can interfere with the signal handling.
>>>>
>>>>
>>>> Updated webrev:
>>>> http://cr.openjdk.java.net/~ddehaven/8026385/jdk.1/
>>>>
>>>> I can look into writing a regression test for this. It might not be trivial though since we're dealing with signal handlers, and if timing is a factor the test may not be reliable.
>>>>
>>>> -DrD-
>>>>
>>
>


From Sergey.Bylokhov at oracle.com  Fri May 16 15:33:36 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 16 May 2014 19:33:36 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8041129 and 8017626
In-Reply-To: <53716EAB.90508@oracle.com>
References: <53716EAB.90508@oracle.com>
Message-ID: <53762FD0.9040407@oracle.com>

Hello.
Any volunteers? This change is targeted to 8u20, so I would like to push 
it to jdk9/8 as soon as possible and to catch a possible regressions.

On 5/13/14 5:00 AM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 9. This a second  iteration of the fix 
> for 8041129, because it was changed to cover 8017626 as well.
>
> Description of the problem:
> 8041129: [OGL] surface->sw blit is extremely slow
>  - The problem is in the glReadPixels(), which is really slow and we 
> call it very often for each image to make a flip.
> Solution:
>  - We call glReadPixels() only once and then flip is done using memcpy 
> after the whole image was moved from gpu to the memory.
>  - glPixelStorei were added/removed when necessary.
>  - Note: actually on my mac the slow path and the fast path(memcpy) 
> works in the same time. I left it as is, because on other system it 
> can be faster.
>
> 8017626: [OGL] Translucent VolatileImages don't paint correctly
>  - The problem is in OGLSurfaceToSwBlit. It was implemented with 
> assumption that the source(ogl) surface contain argb color format, 
> this is wrong because it use premultiplied alpha.
> Solution:
>  - The new ogl blit was added to cover the old behavior 
> OGLSurfaceToSwBlit(SurfaceType.IntArgbPre,OGLSurfaceData.PF_INT_ARGB_PRE),
>  - The blit was changed to properly restore the color components if 
> the source is transparent and destination does not use premultiplied 
> alpha.
>
> Bugs:
>         https://bugs.openjdk.java.net/browse/JDK-8041129
>         https://bugs.openjdk.java.net/browse/JDK-8017626
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8041129/webrev.10
>
> Benchmarks:
> Note that each benchmark was executed 3 times(25 seconds each) to be 
> protected from such spread:
> D3D-base-nvidia-windows: 61796.32109 (var=308.77%) (5857.64%)
> |*************
> |*********************************************************
> |**************************************************
> So check the full report for additional information, since the spread 
> for most of the test is small.
>
> ==========================================================
> Windows 7 x64, lenovo T410, nvidia NVS 3100M
> http://cr.openjdk.java.net/~serb/8041129/webrev.10/benchmarks/results_win.txt 
>
> Summary:
>   OGL-base-nvidia-windows:
>     Number of tests:  40
>     Overall average:  1538.6158105111376
>     Best spread:      0.26% variance
>     Worst spread:     51.66% variance
>     (Basis for results comparison)
>
>   D3D-base-nvidia-windows:
>     Number of tests:  40
>     Overall average:  25477.2292224911
>     Best spread:      0.03% variance
>     Worst spread:     308.77% variance
>     Comparison to basis:
>       Best result:      11192.65% of basis
>       Worst result:     9.13% of basis
>       Number of wins:   28
>       Number of ties:   0
>       Number of losses: 12
>
>   OGL-fix-nvidia-windows:
>     Number of tests:  40
>     Overall average:  125053.84134106003
>     Best spread:      0.08% variance
>     Worst spread:     11.96% variance
>     Comparison to basis:
>       Best result:      12631.78% of basis
>       Worst result:     84.45% of basis
>       Number of wins:   33
>       Number of ties:   6
>       Number of losses: 1
> ==========================================================
> OSX 10.8.5, macbook pro retina, nvidia GeForce GT 650M 1024 MB
> http://cr.openjdk.java.net/~serb/8041129/webrev.10/benchmarks/results_osx_nvidia.txt 
>
> Summary:
>   OGL-base-nvidia-osx:
>     Number of tests:  20
>     Overall average:  714.8688065382015
>     Best spread:      0.16% variance
>     Worst spread:     2.12% variance
>     (Basis for results comparison)
>
>   OGL-fix-nvidia-osx:
>     Number of tests:  20
>     Overall average:  10497.046970040716
>     Best spread:      0.11% variance
>     Worst spread:     5.55% variance
>     Comparison to basis:
>       Best result:      4479.08% of basis
>       Worst result:     172.49% of basis
>       Number of wins:   20
>       Number of ties:   0
>       Number of losses: 0
> ==========================================================
> OSX 10.8.5, macbook pro retina, Intel HD Graphics 4000
> http://cr.openjdk.java.net/~serb/8041129/webrev.10/benchmarks/results_osx_intel.txt 
>
> Summary:
>   OGL-base-intel-osx:
>     Number of tests:  20
>     Overall average:  3912.1181498636274
>     Best spread:      0.25% variance
>     Worst spread:     22.52% variance
>     (Basis for results comparison)
>
>   OGL-fix-intel-osx:
>     Number of tests:  20
>     Overall average:  9647.033915964947
>     Best spread:      0.2% variance
>     Worst spread:     23.32% variance
>     Comparison to basis:
>       Best result:      457.06% of basis
>       Worst result:     104.3% of basis
>       Number of wins:   20
>       Number of ties:   0
>       Number of losses: 0
>


-- 
Best regards, Sergey.



From david.dehaven at oracle.com  Fri May 16 15:38:34 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 16 May 2014 08:38:34 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> Request for review: 8026385:
	[macosx] (awt) setjmp/longjmp changes the process signal mask
	on OS X
In-Reply-To: <53762F1A.5030604@oracle.com>
References: <C6AFC617-0DEE-4892-BDA1-AC7B3809FE49@oracle.com>	<5372798B.1050103@oracle.com>	<5A6B42D6-FCDC-4968-8D4C-F1CC777866F7@oracle.com>	<53728153.3070002@oracle.com>	<3E22C8BF-3F49-46F1-9565-45240DE28902@oracle.com>	<EE677AB2-7CDE-4800-9AAB-C14A29CC4B3B@oracle.com>	<4B720DD6-DF4F-4F00-979E-E02DC0FD70E2@oracle.com>	<5374FB74.9040801@oracle.com>
	<504FD4A5-0921-4C49-87BA-64DF4D905F5D@oracle.com>
	<53762F1A.5030604@oracle.com>
Message-ID: <877C69C9-8643-4BA5-87B0-6A0259BD9FBB@oracle.com>


Thanks!

-DrD-

> The splashscreen changes look fine to me. Approved.
> 
> --
> best regards,
> Anthony
> 
> On 5/16/2014 7:18 PM, David DeHaven wrote:
>> 
>> Could someone on AWT team approve the splashscreen changes?
>> 
>> -DrD-
>> 
>>> Approved.
>>> 
>>> -phil.
>>> 
>>> On 5/15/2014 9:31 AM, David DeHaven wrote:
>>>> Ping!
>>>> 
>>>> Does this look OK?
>>>> 
>>>> I've also filed an issue against JavaFX:
>>>> https://javafx-jira.kenai.com/browse/RT-37125
>>>> 
>>>> -DrD-
>>>> 
>>>>>>>> I tried not modifying libpng but still ended up with lingering references to longjmp in pngread.o, despite libpng having png_ptr->longjmp_fn (bug in libpng?). pngread.c calls setjmp to set a default location to jump to in case the caller doesn't call setjmp, so if we continue down this path something in libpng must be modified. The only other option is to create our own setjmp.h and order it before /usr/include/setjmp.h, which seems dubious at best.
>>>>>>>> 
>>>>>>>> I'm curious if the libpng changes are even needed since it's only used for splashscreen, which happens very early in the launch process. Also note that we didn't originally even call png_set_longjmp_fn, so any error should have resulted in an abort() instead of a call to longjmp... it appears we could retain the functionality we have today and #undef PNG_SETJMP_SUPPORTED (pngconf.h?). That would put the onus on developers to make sure their pngs don't have errors in them, or libsplashscreen will abort()...
>>>>>>>> 
>>>>>>>> 
>>>>>>> That's an interesting question and the answer might extend to the splashscreen changes too.
>>>>>>> Its platform specific code and on MAC, the thread is created using pthreads directly and that
>>>>>>> thread goes away once splashscreen is done. But its running at the same time as the VM
>>>>>>> is booting up and creating threads and setting their signal masks. So I don't think you can
>>>>>>> guarantee that it won't mess up the masks on the JRE threads if the PNG is bad. And I'm
>>>>>>> also not sure you want to remove error handling from the library either.
>>>>>>> So a HIGHLY VISIBLE DO NOT REMOVE comment might be the best you can do here.
>>>>>> I have a better idea:
>>>>>> 
>>>>>> png_default_error is the only place where png_longjmp is called. We could call png_set_error_fn to set up our own error handler (for Mac only), compile with PNG_SETJMP_SUPPORTED unset so it doesn't pull in setjmp/longjmp and our own implementation of the error handler would call _longjmp, which would jump back to where we call setjmp currently.
>>>>> Ok, I figured out what's going on. It's not quite intuitive...
>>>>> 
>>>>> png_jmpbuf is a macro defined in png.h, this calls png_set_longjmp_fn with longjmp, which is why I was seeing references to longjmp in the object file. That's what was throwing me off as it seems like it should only be getting the jmp_buf ptr stored in the png_ptr. I guess the intention was that setjmp/longjmp was optional, if you don't call setjmp then it just abort()s.
>>>>> 
>>>>> 
>>>>> I changed splashscreen_png.c to:
>>>>> #ifdef __APPLE__
>>>>>    if (_setjmp(png_set_longjmp_fn(png_ptr, _longjmp, sizeof(jmp_buf)))) {
>>>>> #else
>>>>>    if (setjmp(png_jmpbuf(png_ptr))) {
>>>>> #endif
>>>>> 
>>>>> and it calls _longjmp instead. I verified this works by changing the macro to set png_longjmp to exit() and without the above change it does indeed exit prematurely with a bad png, with the change it reports the error but continues to load the application as would be expected.
>>>>> 
>>>>> pngread.o still has a symbol table entry for _longjmp instead of __longjmp, but it's benign since we're ultimately forcing it to use the correct function. So I've left libpng completely unchanged.
>>>>> 
>>>>> 
>>>>> With the change and using a bad png for splashscreen, I was able to get a stack trace once the application was running. Without the change to splashscreen_png.c, jstack was unable to connect to the process. So splashscreen absolutely can interfere with the signal handling.
>>>>> 
>>>>> 
>>>>> Updated webrev:
>>>>> http://cr.openjdk.java.net/~ddehaven/8026385/jdk.1/
>>>>> 
>>>>> I can look into writing a regression test for this. It might not be trivial though since we're dealing with signal handlers, and if timing is a factor the test may not be reliable.
>>>>> 
>>>>> -DrD-
>>>>> 
>>> 
>> 



From volker.simonis at gmail.com  Fri May 16 15:57:39 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 16 May 2014 17:57:39 +0200
Subject: [OpenJDK 2D-Dev] <AWT Dev> Request for review: 8026385:
 [macosx] (awt) setjmp/longjmp changes the process signal mask on OS X
In-Reply-To: <877C69C9-8643-4BA5-87B0-6A0259BD9FBB@oracle.com>
References: <C6AFC617-0DEE-4892-BDA1-AC7B3809FE49@oracle.com>
	<5372798B.1050103@oracle.com>
	<5A6B42D6-FCDC-4968-8D4C-F1CC777866F7@oracle.com>
	<53728153.3070002@oracle.com>
	<3E22C8BF-3F49-46F1-9565-45240DE28902@oracle.com>
	<EE677AB2-7CDE-4800-9AAB-C14A29CC4B3B@oracle.com>
	<4B720DD6-DF4F-4F00-979E-E02DC0FD70E2@oracle.com>
	<5374FB74.9040801@oracle.com>
	<504FD4A5-0921-4C49-87BA-64DF4D905F5D@oracle.com>
	<53762F1A.5030604@oracle.com>
	<877C69C9-8643-4BA5-87B0-6A0259BD9FBB@oracle.com>
Message-ID: <CA+3eh10UNDG=+kieCZYrFapJU7d7rbQ7n+xxjJP_Tryi29gaFQ@mail.gmail.com>

Wow, sometimes it really makes sense to read apparently unrelated
email-threads on Friday afternoon:)

It seems that AIX/HPUX have exactly the same problem like MacOS X.
>From the AIX setjmp man-page:

"The setjmp and longjmp subroutines save and restore the signal mask
sigmask (2), while _setjmp and _longjmp manipulate only the stack
context."

>From the HPUXM setjmp man-page:

"setjmp(), longjmp()         These always save and restore the signal mask.
_setjmp(), _longjmp()        These never manipulate the signal mask."

I think it doesn't make sense for you to wait pushing this until I
provide the corresponding AIX patches because anyway I'll have to
provide a fix not only for this issue but also for the other bugs you
mentioned (i.e. 8023786 and 8023720). So I'll better create a new bug
for AIX.

Thank you and best regards,
Volker

On Fri, May 16, 2014 at 5:38 PM, David DeHaven <david.dehaven at oracle.com> wrote:
>
> Thanks!
>
> -DrD-
>
>> The splashscreen changes look fine to me. Approved.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 5/16/2014 7:18 PM, David DeHaven wrote:
>>>
>>> Could someone on AWT team approve the splashscreen changes?
>>>
>>> -DrD-
>>>
>>>> Approved.
>>>>
>>>> -phil.
>>>>
>>>> On 5/15/2014 9:31 AM, David DeHaven wrote:
>>>>> Ping!
>>>>>
>>>>> Does this look OK?
>>>>>
>>>>> I've also filed an issue against JavaFX:
>>>>> https://javafx-jira.kenai.com/browse/RT-37125
>>>>>
>>>>> -DrD-
>>>>>
>>>>>>>>> I tried not modifying libpng but still ended up with lingering references to longjmp in pngread.o, despite libpng having png_ptr->longjmp_fn (bug in libpng?). pngread.c calls setjmp to set a default location to jump to in case the caller doesn't call setjmp, so if we continue down this path something in libpng must be modified. The only other option is to create our own setjmp.h and order it before /usr/include/setjmp.h, which seems dubious at best.
>>>>>>>>>
>>>>>>>>> I'm curious if the libpng changes are even needed since it's only used for splashscreen, which happens very early in the launch process. Also note that we didn't originally even call png_set_longjmp_fn, so any error should have resulted in an abort() instead of a call to longjmp... it appears we could retain the functionality we have today and #undef PNG_SETJMP_SUPPORTED (pngconf.h?). That would put the onus on developers to make sure their pngs don't have errors in them, or libsplashscreen will abort()...
>>>>>>>>>
>>>>>>>>>
>>>>>>>> That's an interesting question and the answer might extend to the splashscreen changes too.
>>>>>>>> Its platform specific code and on MAC, the thread is created using pthreads directly and that
>>>>>>>> thread goes away once splashscreen is done. But its running at the same time as the VM
>>>>>>>> is booting up and creating threads and setting their signal masks. So I don't think you can
>>>>>>>> guarantee that it won't mess up the masks on the JRE threads if the PNG is bad. And I'm
>>>>>>>> also not sure you want to remove error handling from the library either.
>>>>>>>> So a HIGHLY VISIBLE DO NOT REMOVE comment might be the best you can do here.
>>>>>>> I have a better idea:
>>>>>>>
>>>>>>> png_default_error is the only place where png_longjmp is called. We could call png_set_error_fn to set up our own error handler (for Mac only), compile with PNG_SETJMP_SUPPORTED unset so it doesn't pull in setjmp/longjmp and our own implementation of the error handler would call _longjmp, which would jump back to where we call setjmp currently.
>>>>>> Ok, I figured out what's going on. It's not quite intuitive...
>>>>>>
>>>>>> png_jmpbuf is a macro defined in png.h, this calls png_set_longjmp_fn with longjmp, which is why I was seeing references to longjmp in the object file. That's what was throwing me off as it seems like it should only be getting the jmp_buf ptr stored in the png_ptr. I guess the intention was that setjmp/longjmp was optional, if you don't call setjmp then it just abort()s.
>>>>>>
>>>>>>
>>>>>> I changed splashscreen_png.c to:
>>>>>> #ifdef __APPLE__
>>>>>>    if (_setjmp(png_set_longjmp_fn(png_ptr, _longjmp, sizeof(jmp_buf)))) {
>>>>>> #else
>>>>>>    if (setjmp(png_jmpbuf(png_ptr))) {
>>>>>> #endif
>>>>>>
>>>>>> and it calls _longjmp instead. I verified this works by changing the macro to set png_longjmp to exit() and without the above change it does indeed exit prematurely with a bad png, with the change it reports the error but continues to load the application as would be expected.
>>>>>>
>>>>>> pngread.o still has a symbol table entry for _longjmp instead of __longjmp, but it's benign since we're ultimately forcing it to use the correct function. So I've left libpng completely unchanged.
>>>>>>
>>>>>>
>>>>>> With the change and using a bad png for splashscreen, I was able to get a stack trace once the application was running. Without the change to splashscreen_png.c, jstack was unable to connect to the process. So splashscreen absolutely can interfere with the signal handling.
>>>>>>
>>>>>>
>>>>>> Updated webrev:
>>>>>> http://cr.openjdk.java.net/~ddehaven/8026385/jdk.1/
>>>>>>
>>>>>> I can look into writing a regression test for this. It might not be trivial though since we're dealing with signal handlers, and if timing is a factor the test may not be reliable.
>>>>>>
>>>>>> -DrD-
>>>>>>
>>>>
>>>
>


From david.dehaven at oracle.com  Fri May 16 16:04:05 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 16 May 2014 09:04:05 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> Request for review: 8026385:
	[macosx] (awt) setjmp/longjmp changes the process signal mask
	on OS X
In-Reply-To: <CA+3eh10UNDG=+kieCZYrFapJU7d7rbQ7n+xxjJP_Tryi29gaFQ@mail.gmail.com>
References: <C6AFC617-0DEE-4892-BDA1-AC7B3809FE49@oracle.com>
	<5372798B.1050103@oracle.com>
	<5A6B42D6-FCDC-4968-8D4C-F1CC777866F7@oracle.com>
	<53728153.3070002@oracle.com>
	<3E22C8BF-3F49-46F1-9565-45240DE28902@oracle.com>
	<EE677AB2-7CDE-4800-9AAB-C14A29CC4B3B@oracle.com>
	<4B720DD6-DF4F-4F00-979E-E02DC0FD70E2@oracle.com>
	<5374FB74.9040801@oracle.com>
	<504FD4A5-0921-4C49-87BA-64DF4D905F5D@oracle.com>
	<53762F1A.5030604@oracle.com>
	<877C69C9-8643-4BA5-87B0-6A0259BD9FBB@oracle.com>
	<CA+3eh10UNDG=+kieCZYrFapJU7d7rbQ7n+xxjJP_Tryi29gaFQ@mail.gmail.com>
Message-ID: <A34B6713-5C40-42C2-9DF4-0CB695AF8D8F@oracle.com>


I'd thought about that, since Apple borrowed most of it's underpinnings from BSD, but had no evidence to suggest it was necessary.

Anyways, at least you've identified and can rectify the issue :)

-DrD-

> Wow, sometimes it really makes sense to read apparently unrelated
> email-threads on Friday afternoon:)
> 
> It seems that AIX/HPUX have exactly the same problem like MacOS X.
> From the AIX setjmp man-page:
> 
> "The setjmp and longjmp subroutines save and restore the signal mask
> sigmask (2), while _setjmp and _longjmp manipulate only the stack
> context."
> 
> From the HPUXM setjmp man-page:
> 
> "setjmp(), longjmp()         These always save and restore the signal mask.
> _setjmp(), _longjmp()        These never manipulate the signal mask."
> 
> I think it doesn't make sense for you to wait pushing this until I
> provide the corresponding AIX patches because anyway I'll have to
> provide a fix not only for this issue but also for the other bugs you
> mentioned (i.e. 8023786 and 8023720). So I'll better create a new bug
> for AIX.
> 
> Thank you and best regards,
> Volker
> 
> On Fri, May 16, 2014 at 5:38 PM, David DeHaven <david.dehaven at oracle.com> wrote:
>> 
>> Thanks!
>> 
>> -DrD-
>> 
>>> The splashscreen changes look fine to me. Approved.
>>> 
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 5/16/2014 7:18 PM, David DeHaven wrote:
>>>> 
>>>> Could someone on AWT team approve the splashscreen changes?
>>>> 
>>>> -DrD-
>>>> 
>>>>> Approved.
>>>>> 
>>>>> -phil.
>>>>> 
>>>>> On 5/15/2014 9:31 AM, David DeHaven wrote:
>>>>>> Ping!
>>>>>> 
>>>>>> Does this look OK?
>>>>>> 
>>>>>> I've also filed an issue against JavaFX:
>>>>>> https://javafx-jira.kenai.com/browse/RT-37125
>>>>>> 
>>>>>> -DrD-
>>>>>> 
>>>>>>>>>> I tried not modifying libpng but still ended up with lingering references to longjmp in pngread.o, despite libpng having png_ptr->longjmp_fn (bug in libpng?). pngread.c calls setjmp to set a default location to jump to in case the caller doesn't call setjmp, so if we continue down this path something in libpng must be modified. The only other option is to create our own setjmp.h and order it before /usr/include/setjmp.h, which seems dubious at best.
>>>>>>>>>> 
>>>>>>>>>> I'm curious if the libpng changes are even needed since it's only used for splashscreen, which happens very early in the launch process. Also note that we didn't originally even call png_set_longjmp_fn, so any error should have resulted in an abort() instead of a call to longjmp... it appears we could retain the functionality we have today and #undef PNG_SETJMP_SUPPORTED (pngconf.h?). That would put the onus on developers to make sure their pngs don't have errors in them, or libsplashscreen will abort()...
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> That's an interesting question and the answer might extend to the splashscreen changes too.
>>>>>>>>> Its platform specific code and on MAC, the thread is created using pthreads directly and that
>>>>>>>>> thread goes away once splashscreen is done. But its running at the same time as the VM
>>>>>>>>> is booting up and creating threads and setting their signal masks. So I don't think you can
>>>>>>>>> guarantee that it won't mess up the masks on the JRE threads if the PNG is bad. And I'm
>>>>>>>>> also not sure you want to remove error handling from the library either.
>>>>>>>>> So a HIGHLY VISIBLE DO NOT REMOVE comment might be the best you can do here.
>>>>>>>> I have a better idea:
>>>>>>>> 
>>>>>>>> png_default_error is the only place where png_longjmp is called. We could call png_set_error_fn to set up our own error handler (for Mac only), compile with PNG_SETJMP_SUPPORTED unset so it doesn't pull in setjmp/longjmp and our own implementation of the error handler would call _longjmp, which would jump back to where we call setjmp currently.
>>>>>>> Ok, I figured out what's going on. It's not quite intuitive...
>>>>>>> 
>>>>>>> png_jmpbuf is a macro defined in png.h, this calls png_set_longjmp_fn with longjmp, which is why I was seeing references to longjmp in the object file. That's what was throwing me off as it seems like it should only be getting the jmp_buf ptr stored in the png_ptr. I guess the intention was that setjmp/longjmp was optional, if you don't call setjmp then it just abort()s.
>>>>>>> 
>>>>>>> 
>>>>>>> I changed splashscreen_png.c to:
>>>>>>> #ifdef __APPLE__
>>>>>>>   if (_setjmp(png_set_longjmp_fn(png_ptr, _longjmp, sizeof(jmp_buf)))) {
>>>>>>> #else
>>>>>>>   if (setjmp(png_jmpbuf(png_ptr))) {
>>>>>>> #endif
>>>>>>> 
>>>>>>> and it calls _longjmp instead. I verified this works by changing the macro to set png_longjmp to exit() and without the above change it does indeed exit prematurely with a bad png, with the change it reports the error but continues to load the application as would be expected.
>>>>>>> 
>>>>>>> pngread.o still has a symbol table entry for _longjmp instead of __longjmp, but it's benign since we're ultimately forcing it to use the correct function. So I've left libpng completely unchanged.
>>>>>>> 
>>>>>>> 
>>>>>>> With the change and using a bad png for splashscreen, I was able to get a stack trace once the application was running. Without the change to splashscreen_png.c, jstack was unable to connect to the process. So splashscreen absolutely can interfere with the signal handling.
>>>>>>> 
>>>>>>> 
>>>>>>> Updated webrev:
>>>>>>> http://cr.openjdk.java.net/~ddehaven/8026385/jdk.1/
>>>>>>> 
>>>>>>> I can look into writing a regression test for this. It might not be trivial though since we're dealing with signal handlers, and if timing is a factor the test may not be reliable.
>>>>>>> 
>>>>>>> -DrD-
>>>>>>> 
>>>>> 
>>>> 
>> 



From alexandr.scherbatiy at oracle.com  Fri May 16 16:16:21 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 16 May 2014 20:16:21 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review request for 8029339
 Custom MultiResolution image support on HiDPI displays
In-Reply-To: <5370DC41.5080608@oracle.com>
References: <52D51764.8020103@oracle.com> <52DF2F98.3030503@oracle.com>
	<52F4BCEB.9040702@oracle.com> <52F5782A.9060300@oracle.com>
	<52FB7E3E.6050000@oracle.com> <52FC14EC.9080503@oracle.com>
	<53037D3D.80709@oracle.com> <5307E71E.50607@oracle.com>
	<530F3592.40600@oracle.com> <532B00AD.1000704@oracle.com>
	<532B7EC5.9000206@oracle.com> <532C4DD7.1080804@oracle.com>
	<532CD202.5070508@oracle.com> <53302A8E.6090107@oracle.com>
	<53343914.6090004@oracle.com> <533C8DDB.5000406@oracle.com>
	<533E9D42.10409@oracle.com> <53598D86.5020607@oracle.com>
	<535A7509.6050802@oracle.com> <5370DC41.5080608@oracle.com>
Message-ID: <537639D5.9000206@oracle.com>


   Hi Phil,

   I need a reviewer from the 2d group for the fix. Could you take a 
look at the fix and review it?

   Thanks,
   Alexandr.


On 5/12/2014 6:35 PM, Alexander Scherbatiy wrote:
>
>   There was a long thread about the image with sub-pixel resolution 
> drawing  on Mac OS X:
> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005559.html 
>
>
>  It was pointed out that Icon images that can be programmatically 
> generated also need to have HiDPI support:
> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005566.html 
>
> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005569.html 
>
>
>  All requests about Mac OS X HiDPI support were included to the 
> umbrella issue:
>    7124410 [macosx] Lion HiDPI support
>    https://bugs.openjdk.java.net/browse/JDK-7124410
>
>  Thanks,
>  Alexandr.
>
> On 4/25/2014 6:45 PM, Alexander Scherbatiy wrote:
>> On 4/25/2014 2:17 AM, Jim Graham wrote:
>>> Hi Alexandr,
>>>
>>> I asked for who was requesting these facilities and you responded 
>>> with the solution you are planning to provide.
>>>
>>> I don't care what the solution looks like if we have nobody asking 
>>> for the feature - I am asking who is asking for these capabilities?
>>
>>    This is the request from the AWT team for the HiDPI support.
>>
>>    Thanks,
>>    Alexandr.
>>>
>>>             ...jim
>>>
>>> On 4/4/14 4:53 AM, Alexander Scherbatiy wrote:
>>>> On 4/3/2014 2:23 AM, Jim Graham wrote:
>>>>> Hi Alexandr,
>>>>>
>>>>> The back and forth is getting confusing here, so I thought I'd try to
>>>>> summarize and start fresh(ish):
>>>>>
>>>>> 1. We need to support @2x internally for MacOS compatibility (done).
>>>>>
>>>>> 2. We will need to support _DPI images for Win-DPI compatibility 
>>>>> (TBD).
>>>>>
>>>>> 3. Customers may have their own collection of images to bundle
>>>>> together into an MR image (working on that here).  What is the push
>>>>> for this?  Is this simply parity with Mac interfaces?
>>>>
>>>>          ----------
>>>>          Image[] resolutionVariants = // get sorted by sizes array of
>>>> resolution variants;
>>>>          Image mrImage =
>>>> Toolkit.getDefaultToolkit().createMRImage(baseImageIndex,
>>>> resolutionVariants);
>>>>          ----------
>>>>
>>>>       Here is the proposed patch:
>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.04/
>>>>
>>>>> 4. Customers may want to synthetically generate images at arbitrary
>>>>> resolutions (a variation that is impacting this solution). What is
>>>>> the push for this?
>>>>          ----------
>>>>          Image mrImage =
>>>> Toolkit.getDefaultToolkit().createMRImage(baseImageWidth, 
>>>> baseImageHeight,
>>>>                  new float[][]{{100, 100}, {150, 150}, {200, 200}}, //
>>>> resolution variants sizes
>>>>                  (rvWidth, rvHeight) -> {  /* generate a resolution
>>>> variant */  });
>>>>         ----------
>>>>
>>>>>
>>>>> 5. I'm guessing that customers might want to override the logic to
>>>>> choose from among multiple resolutions.  That came from me based on
>>>>> seeing Mac and Win using different selection logic and our history of
>>>>> developers split between those wanting cross-platform consistency and
>>>>> those wanting consistency with native apps on each platform. Also,
>>>>> the needs of an animator may differ from the needs of a
>>>>> resolution-settable-document editor as to how dynamically the images
>>>>> shift between resolution variants.
>>>>         ----------
>>>>          Image[] resolutionVariants = // get sorted by sizes array of
>>>> resolution variants;
>>>>          Image mrImage = ImageResolutionHelper.createMRImage(
>>>>                  (rvWidth, rvHeight, resolutionVariants) -> { /*use a
>>>> custom logic to choose a resolution variant from an array of 
>>>> images*/},
>>>>                  (logicalDPI, baseImageSize, destImageSize) ->
>>>> destImageSize, // calculate the custom aware resolution variant size
>>>>                  baseImageIndex, resolutionVariants);
>>>>         ----------
>>>>
>>>>     or just extend the CustomMultiResolutionImage which has Image 
>>>> as the
>>>> parent class:
>>>>
>>>> --------------------
>>>>   public class CustomMultiResolutionImage extends
>>>> AbstractMultiResolutionImage {
>>>>
>>>>      @Override
>>>>      public Image getResolutionVariant(float logicalDPIX, float
>>>> logicalDPIY,
>>>>              float baseImageWidth, float baseImageHeight,
>>>>              float destImageWidth, float destImageHeight) {
>>>>          // return a resolution variant based on the given logical 
>>>> DPI,
>>>>          // base image size, or destination image size
>>>>      }
>>>>
>>>>      @Override
>>>>      public List<Image> getResolutionVariants() {
>>>>          // return a list of resolution variants
>>>>      }
>>>>
>>>>      @Override
>>>>      protected Image getBaseImage() {
>>>>          // return the base image
>>>>      }
>>>> }
>>>> --------------------
>>>>>
>>>>> Is that a fair summary of all of the considerations so far, or did I
>>>>> miss something?
>>>>     I think it should cover the main needs.
>>>>
>>>>      Thanks,
>>>>      Alexandr.
>>>>>
>>>>>             ...jim
>>>>>
>>>>> On 3/27/14 7:43 AM, Alexander Scherbatiy wrote:
>>>>>>
>>>>>>   Below are some thoughts about TK.createMRImage(...) method
>>>>>>
>>>>>> On 3/24/2014 4:52 PM, Alexander Scherbatiy wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>>   Could you review the updated fix:
>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.03/
>>>>>>>
>>>>>>>   - baseImageWidth/Height arguments are added to the
>>>>>>> getResolutionVariant(...) method
>>>>>>>   - dest image sizes are reverted to included DPI scale
>>>>>>>   - AbstractMultiResolutionImage is added. It needs only to 
>>>>>>> implement
>>>>>>> only 3 methods from the  AbstractMultiResolutionImage class
>>>>>>>     to create a custom multi-resolution image. For example:
>>>>>>>
>>>>>>> On 3/22/2014 3:57 AM, Jim Graham wrote:
>>>>>>>>
>>>>>>>> Your code example below can be expressed as an implementation 
>>>>>>>> of the
>>>>>>>> single-method, lambda-compatible interface that expresses just the
>>>>>>>> getRV() method. They could easily do:
>>>>>>>>
>>>>>>>> final Image baseImage = ...;
>>>>>>>> TK.createMRImage(new RVInterface() {
>>>>>>>>     public Image getRV(...) {
>>>>>>>>         // calculate rvWidth and rvHeight
>>>>>>>>         // look up rvWidth/rvHeight in a database of images
>>>>>>>>         // possibly contruct a new image
>>>>>>>>         return rvImage;
>>>>>>>>     }
>>>>>>>> }, baseImage);
>>>>>>>>
>>>>>>       The RVInterface mixes the logic that construct an image and
>>>>>> chooses the necessary resolution variant.
>>>>>>       It is ok if a developer always implements this interface. 
>>>>>> If it
>>>>>> needs to have DPI/Transform/Platform aware RVInterface the image
>>>>>> construction logic should be separated.
>>>>>>
>>>>>>      Does  TK.createMRImage() method implies that Platform aware 
>>>>>> logic
>>>>>> should be used for a resolution-variant choosing?
>>>>>>      If so, may be general createMRImage() can be placed in the
>>>>>> ImageResolutionHelper.
>>>>>>>> The main issue I see is if you might want the newly constructed
>>>>>>>> variants to appear in the List returned from the getVariants()
>>>>>>>> method.  I'm not sure what value that would have beyond simply
>>>>>>>> returning the base media that the object uses from which to 
>>>>>>>> construct
>>>>>>>> its variants...?
>>>>>>
>>>>>>    It can be solved by using something like array of image sizes or
>>>>>> other seeds and a mapper that can create an image from the given 
>>>>>> seed.
>>>>>>
>>>>>>   It can look like:
>>>>>> -------------------------
>>>>>> public class ImageResolutionHelper {
>>>>>>      public interface RVChooser {
>>>>>>
>>>>>>          public Image getRV(
>>>>>>                  float logicalDPIX, float logicalDPIY,
>>>>>>                  float baseImageWidth, float baseImageHeight,
>>>>>>                  float destImageWidth, float destImageHeight,
>>>>>>                  final Image... resolutionVariants);
>>>>>>      }
>>>>>>
>>>>>>      public static final RVChooser DPI_AWARE = ...;
>>>>>>      public static final RVChooser TRANSFORM_AWARE = ...;
>>>>>>
>>>>>>      // resolutionVariants is an array of  sorted by width/height 
>>>>>> images
>>>>>>      static Image createMRImage(final RVChooser rvChooser,
>>>>>>              final int baseImageIndex, final Image...
>>>>>> resolutionVariants) { ... }
>>>>>>
>>>>>>      // sorted by width/height images should be generated from seeds
>>>>>>      static <Type> Image createMRImage(final RVChooser rvChooser,
>>>>>>              final Type baseImageSeed, final Function<Type, Image>
>>>>>> mapper, final Type... rvSeeds) {...}
>>>>>> }
>>>>>>
>>>>>> public abstract class Toolkit {
>>>>>>      public abstract Image createMRImage(int baseImageIndex, 
>>>>>> Image...
>>>>>> resolutionVariants); // Platform aware rv chooser is used
>>>>>>      public abstract RVChooser getPlatformRVChooser() ;
>>>>>> }
>>>>>> --------------------------
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>>>>
>>>>>>>>>      I think it is better to provide both the 
>>>>>>>>> MultiResolutionImage
>>>>>>>>> and
>>>>>>>>> its implementation based on the given resolution variants array.
>>>>>>>>
>>>>>>>> It occurs to me that even if we don't go with a 
>>>>>>>> lambda-factory-based
>>>>>>>> approach like what I'm describing, it might make sense to 
>>>>>>>> provide a
>>>>>>>> baseMR implementation that they can subclass to keep them from 
>>>>>>>> trying
>>>>>>>> to subclass off of BufferedImage instead.  I really would like to
>>>>>>>> avoid "custom MR images are subclasses of BufImg" if we can as I
>>>>>>>> think the mix of concepts is a little jarring...
>>>>>>>>
>>>>>>>>             ...jim
>>>>>>>>
>>>>>>>>>     The implementation could look like:
>>>>>>>>> ---------------------------------
>>>>>>>>> public class CustomMultiResolutionImage extends Image implements
>>>>>>>>> MultiResolutionImage {
>>>>>>>>>
>>>>>>>>>      int baseImageIndex;
>>>>>>>>>      Image[] resolutionVariants;
>>>>>>>>>
>>>>>>>>>      public CustomMultiResolutionImage(int baseImageIndex,
>>>>>>>>>              Image... resolutionVariants) {
>>>>>>>>>          this.baseImageIndex = baseImageIndex;
>>>>>>>>>          this.resolutionVariants = resolutionVariants;
>>>>>>>>>      }
>>>>>>>>>
>>>>>>>>>      @Override
>>>>>>>>>      public int getWidth(ImageObserver observer) {
>>>>>>>>>          return getBaseImage().getWidth(null);
>>>>>>>>>      }
>>>>>>>>>
>>>>>>>>>      @Override
>>>>>>>>>      public int getHeight(ImageObserver observer) {
>>>>>>>>>          return getBaseImage().getHeight(null);
>>>>>>>>>      }
>>>>>>>>>
>>>>>>>>>      @Override
>>>>>>>>>      public ImageProducer getSource() {
>>>>>>>>>          return getBaseImage().getSource();
>>>>>>>>>      }
>>>>>>>>>
>>>>>>>>>      @Override
>>>>>>>>>      public Graphics getGraphics() {
>>>>>>>>>          return getBaseImage().getGraphics();
>>>>>>>>>      }
>>>>>>>>>
>>>>>>>>>      @Override
>>>>>>>>>      public Object getProperty(String name, ImageObserver 
>>>>>>>>> observer) {
>>>>>>>>>          return getBaseImage().getProperty(name, observer);
>>>>>>>>>      }
>>>>>>>>>
>>>>>>>>>      @Override
>>>>>>>>>      public Image getResolutionVariant(float logicalDPIX, float
>>>>>>>>> logicalDPIY,
>>>>>>>>>              float destinationImageWidth, float
>>>>>>>>> destinationImageHeight) {
>>>>>>>>>              // calculate resolution variant width/height
>>>>>>>>>          return getResolutionVariant(rvWidth, rvHeight);
>>>>>>>>>      }
>>>>>>>>>
>>>>>>>>>      @Override
>>>>>>>>>      public List<Image> getResolutionVariants() {
>>>>>>>>>          return Arrays.asList(resolutionVariants);
>>>>>>>>>      }
>>>>>>>>>
>>>>>>>>>      private Image getResolutionVariant(float rvWidth, float
>>>>>>>>> rvHeight) {
>>>>>>>>>          // return a resolution variant based on the given 
>>>>>>>>> width and
>>>>>>>>> height
>>>>>>>>>      }
>>>>>>>>>
>>>>>>>>>      private Image getBaseImage() {
>>>>>>>>>          return resolutionVariants[baseImageIndex];
>>>>>>>>>      }
>>>>>>>>> }
>>>>>>>>> ---------------------------------
>>>>>>>>>
>>>>>>>>>    Thanks,
>>>>>>>>>    Alexandr.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Then we provide one of these from TK.get/createImage() when the
>>>>>>>>>> platform detects @2x, or Win8-style variants.
>>>>>>>>>>
>>>>>>>>>> For custom images we provide TK.createMRImage(lambda getRV, 
>>>>>>>>>> Image
>>>>>>>>>> variants...) and TK.createMRImage(Image variants...);
>>>>>>>>>>
>>>>>>>>>> Since the get<List> method is just bookkeeping, I don't see them
>>>>>>>>>> needing to override it, so the getRV() method is really the only
>>>>>>>>>> thing
>>>>>>>>>> they might want to override, and we can tie into the new Lambda
>>>>>>>>>> capabilities by making a single-method interface for it that 
>>>>>>>>>> they
>>>>>>>>>> supply in a factory method.
>>>>>>>>>>
>>>>>>>>>> I realize that the interface you created is more fundamentally
>>>>>>>>>> OO, but
>>>>>>>>>> the Image class has always been special in this regard in the 
>>>>>>>>>> AWT
>>>>>>>>>> ecosystem (in so far as we do not support someone 
>>>>>>>>>> implementing their
>>>>>>>>>> own Image subclass even though it is technically possible).
>>>>>>>>>> Because of
>>>>>>>>>> this special nature of Image, we end up with the situation 
>>>>>>>>>> that if
>>>>>>>>>> someone were given a need to create a subclass of Image, then 
>>>>>>>>>> they
>>>>>>>>>> would turn to BufImg as their superclass even though BufImg is
>>>>>>>>>> essentially an implementation-specific leaf node on the Image 
>>>>>>>>>> class
>>>>>>>>>> hierarchy.  This approach with a factory method to create an
>>>>>>>>>> internal
>>>>>>>>>> subclass of the new MRI class mirrors the existing cases of 
>>>>>>>>>> Image
>>>>>>>>>> objects that come from factories as well.
>>>>>>>>>>
>>>>>>>>>> Thoughts?
>>>>>>>>>>
>>>>>>>>>>             ...jim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 3/20/14 7:52 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>
>>>>>>>>>>>    Hello,
>>>>>>>>>>>
>>>>>>>>>>>    Could you review the updated version of the fix:
>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.01/
>>>>>>>>>>>
>>>>>>>>>>>   - The "getResolutionVariant(int width, int height)" method 
>>>>>>>>>>> from
>>>>>>>>>>> MultiResolutionImage class is changed to
>>>>>>>>>>>     Image getResolutionVariant(float logicalDPIX, float
>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>> float width, float height, AffineTransform transform);
>>>>>>>>>>>
>>>>>>>>>>>   - sun.awt.image.ImageResolutionHelper class is added. The
>>>>>>>>>>> sun.awt.image.MultiResolutionToolkitImage and
>>>>>>>>>>> sun.awt.image.MultiResolutionBufferedImage classes are used
>>>>>>>>>>> PLATFORM  ImageResolutionHelper.
>>>>>>>>>>>
>>>>>>>>>>>   The  MultiResolutionImage interface implementation could look
>>>>>>>>>>> like:
>>>>>>>>>>> ------------------------------
>>>>>>>>>>> public class CustomMultiResolutionImage extends BufferedImage
>>>>>>>>>>> implements
>>>>>>>>>>> MultiResolutionImage {
>>>>>>>>>>>
>>>>>>>>>>>      private final Image[] resolutionVariants;
>>>>>>>>>>>
>>>>>>>>>>>      public CustomMultiResolutionImage(int baseIndex, Image...
>>>>>>>>>>> images) {
>>>>>>>>>>> super(images[baseIndex].getWidth(null),
>>>>>>>>>>> images[baseIndex].getHeight(null),
>>>>>>>>>>>                  BufferedImage.TYPE_INT_RGB);
>>>>>>>>>>>          this.resolutionVariants = images;
>>>>>>>>>>>          Graphics g = getGraphics();
>>>>>>>>>>>          g.drawImage(images[baseIndex], 0, 0, null);
>>>>>>>>>>>          g.dispose();
>>>>>>>>>>>      }
>>>>>>>>>>>
>>>>>>>>>>>      @Override
>>>>>>>>>>>      public Image getResolutionVariant(float logicalDPIX, float
>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>              float width, float height, AffineTransform
>>>>>>>>>>> transform) {
>>>>>>>>>>>          return getResolutionVariant(logicalDPIX * width,
>>>>>>>>>>> logicalDPIY *
>>>>>>>>>>> height);
>>>>>>>>>>>      }
>>>>>>>>>>>
>>>>>>>>>>>      @Override
>>>>>>>>>>>      public List<Image> getResolutionVariants() {
>>>>>>>>>>>          return Arrays.asList(resolutionVariants);
>>>>>>>>>>>      }
>>>>>>>>>>>
>>>>>>>>>>>      public Image getResolutionVariant(double width, double
>>>>>>>>>>> height) {
>>>>>>>>>>>          for (Image image : resolutionVariants) {
>>>>>>>>>>>              if (width <= image.getWidth(null) && height <=
>>>>>>>>>>> image.getHeight(null)) {
>>>>>>>>>>>                  return image;
>>>>>>>>>>>              }
>>>>>>>>>>>          }
>>>>>>>>>>>          return this;
>>>>>>>>>>>      }
>>>>>>>>>>> }
>>>>>>>>>>> ------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>    Thanks,
>>>>>>>>>>>    Alexandr.
>>>>>>>>>>>
>>>>>>>>>>> On 2/27/2014 4:54 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>> On 2/22/2014 3:54 AM, Jim Graham wrote:
>>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2/18/14 7:33 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>   Hi Jim,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Let's divide the discussion into two part.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   1. Where it is better to hold resolution variants?
>>>>>>>>>>>>>>      Putting resolution variants in Image class brings some
>>>>>>>>>>>>>> questions like:
>>>>>>>>>>>>>>    - Some type of images do not need to have resolution 
>>>>>>>>>>>>>> variants
>>>>>>>>>>>>>>    - Should resolution variants have the same type as the 
>>>>>>>>>>>>>> base
>>>>>>>>>>>>>> image?
>>>>>>>>>>>>>>    - getResolutionVariants() method can return copy of the
>>>>>>>>>>>>>> original
>>>>>>>>>>>>>> list
>>>>>>>>>>>>>> so add/removeRV methods should be also added.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    There are pros and cons for placing resolution 
>>>>>>>>>>>>>> variants to
>>>>>>>>>>>>>> Image
>>>>>>>>>>>>>> class or to a separate intreface.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I agree that this could be a separate interface. In my 
>>>>>>>>>>>>> examples
>>>>>>>>>>>>> below I was just sticking them inside an "Image{}" to show 
>>>>>>>>>>>>> where
>>>>>>>>>>>>> they
>>>>>>>>>>>>> lived in the set of involved objects, not a specific
>>>>>>>>>>>>> recommendation
>>>>>>>>>>>>> that they actually be new methods on the base class itself. I
>>>>>>>>>>>>> probably should have put a comment there about that.
>>>>>>>>>>>>>
>>>>>>>>>>>>> With respect to add/remove - that is assuming a need for 
>>>>>>>>>>>>> manual
>>>>>>>>>>>>> construction of an image set, right? Forgive me if I'm
>>>>>>>>>>>>> forgetting
>>>>>>>>>>>>> something, but I seem to recall that manual Multi-Res 
>>>>>>>>>>>>> images was
>>>>>>>>>>>>> proposed as a way for developers to introduce @2x support
>>>>>>>>>>>>> themselves,
>>>>>>>>>>>>> but if we are internally managing @2x and -DPI variants 
>>>>>>>>>>>>> for them,
>>>>>>>>>>>>> then I'm not sure if there is actual developer need to 
>>>>>>>>>>>>> manually
>>>>>>>>>>>>> construct their own.  Am I forgetting something?
>>>>>>>>>>>>    The NSImage has addRepresentation/removeRepresentation
>>>>>>>>>>>> methods to
>>>>>>>>>>>> work with image representations on Mac OS X.
>>>>>>>>>>>>    The java.awt.Image class should provide similar
>>>>>>>>>>>> functionality to
>>>>>>>>>>>> have the possibilities as Cocoa on HiDPI displays.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>   2. Using scale factor/image sizes/scaled image sizes to
>>>>>>>>>>>>>> retreive a
>>>>>>>>>>>>>> resolution variant.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    May be it is better to have a structure that provide all
>>>>>>>>>>>>>> necessary
>>>>>>>>>>>>>> information  to query the resolution variant: scale factor,
>>>>>>>>>>>>>> draw area
>>>>>>>>>>>>>> width/height, transformed area width/height?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    For example:
>>>>>>>>>>>>>>    ---------------------
>>>>>>>>>>>>>>      public interface MultiResolutionImage {
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>          interface DrawAreaInfo {
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>              float getScaleFactor();
>>>>>>>>>>>>>>              float getAreaWidth();
>>>>>>>>>>>>>>              float getAreaHeight();
>>>>>>>>>>>>>>              float getTransformedAreaWidth();
>>>>>>>>>>>>>>              float getTransformedAreaHeight();
>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>          public Image getResolutionVariant(DrawAreaInfo
>>>>>>>>>>>>>> drawAreaInfo) ;
>>>>>>>>>>>>>>          public List<Image> getResolutionVariants();
>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>    ---------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>> The problem with a constructor is that this is something 
>>>>>>>>>>>>> that is
>>>>>>>>>>>>> (potentially) done on every drawImage() call, which means 
>>>>>>>>>>>>> we are
>>>>>>>>>>>>> inviting GC into the equation.  If we can come up with a 
>>>>>>>>>>>>> simple
>>>>>>>>>>>>> "just
>>>>>>>>>>>>> a couple/3/4 numbers" way to embed that data into a method 
>>>>>>>>>>>>> call
>>>>>>>>>>>>> argument list then we can make this lighter weight.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What about simply having floating point (double) 
>>>>>>>>>>>>> dimensions on
>>>>>>>>>>>>> the
>>>>>>>>>>>>> rendered size
>>>>>>>>>>>>       There should be a way to choose a resolution variant
>>>>>>>>>>>> based on
>>>>>>>>>>>> requested drawing size or transformed drawing size.
>>>>>>>>>>>>       At least a current transformation should be included 
>>>>>>>>>>>> too.
>>>>>>>>>>>>> plus a single floating point "logical DPI" for the screen?
>>>>>>>>>>>>      There is the ID2D1Factory::GetDesktopDpi method which 
>>>>>>>>>>>> returns
>>>>>>>>>>>> dpiX and dpiY.
>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316
>>>>>>>>>>>>
>>>>>>>>>>>>     That means that logicalDPIX/Y can have different values.
>>>>>>>>>>>>      At least it is described in the
>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/ff684173
>>>>>>>>>>>>      "To get the DPI setting, call the 
>>>>>>>>>>>> ID2D1Factory::GetDesktopDpi
>>>>>>>>>>>> method. The DPI is returned as two floating-point values, 
>>>>>>>>>>>> one for
>>>>>>>>>>>> the
>>>>>>>>>>>> x-axis and one for the y-axis. In theory, these values can 
>>>>>>>>>>>> differ.
>>>>>>>>>>>> Calculate a separate scaling factor for each axis."
>>>>>>>>>>>>
>>>>>>>>>>>>   The getResolutionVariant method could look like:
>>>>>>>>>>>>    --------------------------------------
>>>>>>>>>>>>     public Image getResolutionVariant(float logicalDPIX, float
>>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>>             float widthX, float widthY, AffineTransform
>>>>>>>>>>>> transform);
>>>>>>>>>>>>    --------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>>>  If the image is known (either passed as an argument or the
>>>>>>>>>>>>> method is
>>>>>>>>>>>>> called on the image), then it can provide the original WH.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>    The MultiResolutionImage default implementation could 
>>>>>>>>>>>>>> allow
>>>>>>>>>>>>>> to use
>>>>>>>>>>>>>> different strategies like scale factor/transfom/OS based
>>>>>>>>>>>>>>    to query a resolution variant. The OS based strategy 
>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>> used by
>>>>>>>>>>>>>> default.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For Mac policy, all we need is the transformed dimensions, 
>>>>>>>>>>>>> which
>>>>>>>>>>>>> can
>>>>>>>>>>>>> be passed in as FP for generality.  For Windows policy, 
>>>>>>>>>>>>> all we
>>>>>>>>>>>>> need
>>>>>>>>>>>>> is logical DPI for the screen.   What other information 
>>>>>>>>>>>>> would we
>>>>>>>>>>>>> need, or would an algorithm like to use, that can't be 
>>>>>>>>>>>>> computed
>>>>>>>>>>>>> from
>>>>>>>>>>>>> those 2 pieces?
>>>>>>>>>>>>      The aim is to provide a base class that can be used to
>>>>>>>>>>>> create a
>>>>>>>>>>>> MultiResolutionImage like:
>>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/diff/ae53ebce5fa3/src/share/classes/sun/awt/image/MultiResolutionBufferedImage.java 
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>      A developer should be able to implement a custom 
>>>>>>>>>>>> algorithm to
>>>>>>>>>>>> query a resolution variant.
>>>>>>>>>>>>
>>>>>>>>>>>>     It can be done by overriding the getResolutionVariant 
>>>>>>>>>>>> image:
>>>>>>>>>>>>    -----------------------
>>>>>>>>>>>>         Image mrImage = new MultiResolutionBufferedImage(){
>>>>>>>>>>>>             @Override
>>>>>>>>>>>>             public Image getResolutionVariant(...) {
>>>>>>>>>>>>                 // Custom logic here
>>>>>>>>>>>>             }
>>>>>>>>>>>>         };
>>>>>>>>>>>>    -----------------------
>>>>>>>>>>>>
>>>>>>>>>>>>    Or it can be done by using resolution variant choosers so a
>>>>>>>>>>>> developer can implement custom resolution variant query:
>>>>>>>>>>>>    -----------------------
>>>>>>>>>>>> public class MultiResolutionBufferedImage implements
>>>>>>>>>>>> MultiResolutionImage{
>>>>>>>>>>>>
>>>>>>>>>>>>     interface ResolutionVariantChooser{
>>>>>>>>>>>>         Image getResolutionVariant(dpi, size,..., List<Image>
>>>>>>>>>>>> resolutionVariants);
>>>>>>>>>>>>     }
>>>>>>>>>>>>     ResolutionVariantChooser TRANSFORM_BASED = null;
>>>>>>>>>>>>     ResolutionVariantChooser DPI_BASED = null;
>>>>>>>>>>>>
>>>>>>>>>>>>     ResolutionVariantChooser rvChooser;
>>>>>>>>>>>>
>>>>>>>>>>>>     @Override
>>>>>>>>>>>>     public Image getResolutionVariant(dpi, size,...,) {
>>>>>>>>>>>>         return rvChooser.getResolutionVariant(dpi, size,...,
>>>>>>>>>>>> getResolutionVariants());
>>>>>>>>>>>>     }
>>>>>>>>>>>> }
>>>>>>>>>>>>    -----------------------
>>>>>>>>>>>>
>>>>>>>>>>>>   Thanks,
>>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2/13/2014 4:42 AM, Jim Graham wrote:
>>>>>>>>>>>>>>> On 2/12/14 5:59 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>> On 2/8/2014 4:19 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>> The primary thing that I was concerned about was the
>>>>>>>>>>>>>>>>> presence of
>>>>>>>>>>>>>>>>> integers in the API when Windows uses non-integer 
>>>>>>>>>>>>>>>>> multiples
>>>>>>>>>>>>>>>>       It would make sense to pass real numbers to the
>>>>>>>>>>>>>>>> getResolutionVariant() method  if the difference between
>>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>>> variants sizes is 1.
>>>>>>>>>>>>>>>>       It seems that it is not a common case.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I was thinking of other API that is related to this, 
>>>>>>>>>>>>>>> such as
>>>>>>>>>>>>>>> the API
>>>>>>>>>>>>>>> that queries the scaling factor from a SurfaceManager. I
>>>>>>>>>>>>>>> seem to
>>>>>>>>>>>>>>> remember some integer return values in that, but Windows 
>>>>>>>>>>>>>>> might
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>> the answer 1.4 or 1.8, depending on the screen scaling 
>>>>>>>>>>>>>>> factor
>>>>>>>>>>>>>>> that was
>>>>>>>>>>>>>>> determined from the UI.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In terms of the getResolutionVariant() method here, those
>>>>>>>>>>>>>>> non-integer
>>>>>>>>>>>>>>> screen scaling factors don't directly impact this API. 
>>>>>>>>>>>>>>> But, we
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>> some issues with the use of integers there from other 
>>>>>>>>>>>>>>> sources:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - That API assumes that the caller will determine the pixel
>>>>>>>>>>>>>>> size
>>>>>>>>>>>>>>> needed, but the actual media choice is determined with
>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>> techniques on Mac and Windows so this means that the caller
>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>> to worry about platform conventions. Is that the right
>>>>>>>>>>>>>>> tradeoff?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - The technique recommended for Mac involves computing the
>>>>>>>>>>>>>>> precise
>>>>>>>>>>>>>>> size desired using the current transform, which may be a
>>>>>>>>>>>>>>> floating
>>>>>>>>>>>>>>> point value, so the integer values used in this API are 
>>>>>>>>>>>>>>> already
>>>>>>>>>>>>>>> approximations and there is no documentation on how to
>>>>>>>>>>>>>>> generate the
>>>>>>>>>>>>>>> proper integer.  In particular, the current code in SG2D
>>>>>>>>>>>>>>> naively
>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>> a cast to integer to determine the values to supply which
>>>>>>>>>>>>>>> means a
>>>>>>>>>>>>>>> transformed size of W+0.5 will be truncated to W and the 
>>>>>>>>>>>>>>> lower
>>>>>>>>>>>>>>> resolution image will be used. Does that conform to Mac
>>>>>>>>>>>>>>> guidelines? Do
>>>>>>>>>>>>>>> they require the truncated size to reach W+1 before the 
>>>>>>>>>>>>>>> next
>>>>>>>>>>>>>>> size is
>>>>>>>>>>>>>>> used?  Passing in float or double values would sidestep 
>>>>>>>>>>>>>>> all of
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> since then the comparisons would be done with full 
>>>>>>>>>>>>>>> precision,
>>>>>>>>>>>>>>> but as
>>>>>>>>>>>>>>> long as we can determine a "best practices compatible 
>>>>>>>>>>>>>>> with all
>>>>>>>>>>>>>>> platforms" rule on how to round to integers, then integers
>>>>>>>>>>>>>>> are OK
>>>>>>>>>>>>>>> there.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - The Windows document you cite below suggests that the
>>>>>>>>>>>>>>> determination
>>>>>>>>>>>>>>> should be made by looking at the Screen DPI and choosing 
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> next
>>>>>>>>>>>>>>> higher media variant based on that screen DPI. They do not
>>>>>>>>>>>>>>> specify
>>>>>>>>>>>>>>> choosing media based on the current transform as is done 
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> Mac.  If
>>>>>>>>>>>>>>> we stick with supplying values that are used to 
>>>>>>>>>>>>>>> determine which
>>>>>>>>>>>>>>> media
>>>>>>>>>>>>>>> to use, then on Windows we should not take the transform 
>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>> account,
>>>>>>>>>>>>>>> but instead query the SurfaceManager for the scale 
>>>>>>>>>>>>>>> factor and
>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>> transform by those values (even if the current transform 
>>>>>>>>>>>>>>> was
>>>>>>>>>>>>>>> manually
>>>>>>>>>>>>>>> overridden to identity).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There are pros and cons to both approaches.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Mac ensures that you are always using the best media for 
>>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>> given
>>>>>>>>>>>>>>> render operation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But, Windows ensure more consistency in the face of other
>>>>>>>>>>>>>>> scaling.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The thing to consider is that if you have a 500x500 image
>>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>>> 1000x1000 variant and you rendering it at 500x500 and then
>>>>>>>>>>>>>>> 501x501,
>>>>>>>>>>>>>>> that first jump will be fairly jarring as the scaled 
>>>>>>>>>>>>>>> version
>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>> 1000x1000 will not look precisely like the original 500x500
>>>>>>>>>>>>>>> did.
>>>>>>>>>>>>>>> With
>>>>>>>>>>>>>>> @2x images only, this effect is minimized so the 
>>>>>>>>>>>>>>> advantage of
>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>> using "the best media for a given render operation" may
>>>>>>>>>>>>>>> outweigh the
>>>>>>>>>>>>>>> inconsistency issue.  But, on Windows where the media are
>>>>>>>>>>>>>>> 1.4x or
>>>>>>>>>>>>>>> 1.8x
>>>>>>>>>>>>>>> in size, a downscaled image will start to show more
>>>>>>>>>>>>>>> interpolation
>>>>>>>>>>>>>>> noise and so the balance of the two choices may shift more
>>>>>>>>>>>>>>> towards not
>>>>>>>>>>>>>>> wanting a jarring shift.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We might want one or more of the following:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Developer chooses policy (TX_AWARE, DPI_AWARE,
>>>>>>>>>>>>>>> ALWAYS_LARGEST,
>>>>>>>>>>>>>>> NONE,
>>>>>>>>>>>>>>> PLATFORM) where the last policy would use TX_AWARE on 
>>>>>>>>>>>>>>> Mac and
>>>>>>>>>>>>>>> DPI_AWARE on Windows
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - We create our own policy and always use it (TX_AWARE? or
>>>>>>>>>>>>>>> DPI_AWARE?)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - We create our own policy that dynamically chooses one 
>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>> above
>>>>>>>>>>>>>>> strategies depending on platform or available media or ???
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - We could create an optional interface for them to install
>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>> own
>>>>>>>>>>>>>>> algorithm as well.  I think it would work best as a 
>>>>>>>>>>>>>>> delegate
>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>> that one installs into Image so that it can be used with 
>>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>> image
>>>>>>>>>>>>>>> without having to subclass (it wouldn't really have much 
>>>>>>>>>>>>>>> to do
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> BufferedImages or VolatileImages, though):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> class Image {
>>>>>>>>>>>>>>>     void setResolutionHelper(ImageResolutionHelper foo);
>>>>>>>>>>>>>>>     List<Image> getResolutionVariants();
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> or:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> class Graphics {
>>>>>>>>>>>>>>>      void setResolutionHelper(ImageResolutionHelper foo);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> or - anywhere else it could be installed more centrally 
>>>>>>>>>>>>>>> (per
>>>>>>>>>>>>>>> App
>>>>>>>>>>>>>>> context)?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> and the interface would be something like one of these
>>>>>>>>>>>>>>> variants:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> interface ImageResolutionHelper {
>>>>>>>>>>>>>>>     // This version would prevent substituting a random 
>>>>>>>>>>>>>>> image:
>>>>>>>>>>>>>>>     // They have to return an index into the List<Image> 
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> image...
>>>>>>>>>>>>>>>     public int chooseVariant(Image img, double dpi, 
>>>>>>>>>>>>>>> number w,
>>>>>>>>>>>>>>> number h);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> or:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     // This version would allow substituting an arbitrary
>>>>>>>>>>>>>>> image:
>>>>>>>>>>>>>>>     public Image getVariant(Image img, double dpi, 
>>>>>>>>>>>>>>> number w,
>>>>>>>>>>>>>>> number
>>>>>>>>>>>>>>> h);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Since they would be in full control of the policy, 
>>>>>>>>>>>>>>> though, we
>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>> unfortunately always have to call this, there would be 
>>>>>>>>>>>>>>> no more
>>>>>>>>>>>>>>> testing
>>>>>>>>>>>>>>> in SG2D to see "if" we need to deal with DPI, though 
>>>>>>>>>>>>>>> perhaps we
>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>> document some internal conditions in which we do not 
>>>>>>>>>>>>>>> call it
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> common cases (but that would have to be well agreed not to
>>>>>>>>>>>>>>> get in
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> way of reasonable uses of the API and well documented)?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Note that we would have to do a security audit to make sure
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> random image substitution couldn't allow any sort of 
>>>>>>>>>>>>>>> "screen
>>>>>>>>>>>>>>> phishing"
>>>>>>>>>>>>>>> exploit.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> and also what policy they use for choosing scaled images.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I don't see a mention of taking the current transform 
>>>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>>>> account,
>>>>>>>>>>>>>>>>> just physical issues like screen DPI and form factor. 
>>>>>>>>>>>>>>>>> They
>>>>>>>>>>>>>>>>> talk
>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>> resolution plateaus and in their recommendations 
>>>>>>>>>>>>>>>>> section they
>>>>>>>>>>>>>>>>> tell the
>>>>>>>>>>>>>>>>> developer to use a particular property that tells them 
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> screen
>>>>>>>>>>>>>>>>> resolution to figure out which image to load if they are
>>>>>>>>>>>>>>>>> loading
>>>>>>>>>>>>>>>>> manually.  There is no discussion about dynamically 
>>>>>>>>>>>>>>>>> loading
>>>>>>>>>>>>>>>>> multiple
>>>>>>>>>>>>>>>>> versions of the image based on a dynamic program-applied
>>>>>>>>>>>>>>>>> transform
>>>>>>>>>>>>>>>>> factor as is done on MacOS.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Also, they tell developers to draw images to a 
>>>>>>>>>>>>>>>>> specific size
>>>>>>>>>>>>>>>>> rather
>>>>>>>>>>>>>>>>> than using auto-sizing.  That begs the question as to how
>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>> interpret a call to draw an image just using a 
>>>>>>>>>>>>>>>>> location in
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> presence of various DPI factors.
>>>>>>>>>>>>>>>>       There is an interesting doc that describes how to 
>>>>>>>>>>>>>>>> write
>>>>>>>>>>>>>>>> DPI-aware
>>>>>>>>>>>>>>>> Win32 applications:
>>>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/dd464646%28v=vs.85%29.aspx 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>       It is suggested to handle WM_DPICHANGED message, 
>>>>>>>>>>>>>>>> load
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> graphic
>>>>>>>>>>>>>>>> that has slightly greater resolution to the current DPI 
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>> StretchBlt
>>>>>>>>>>>>>>>>       to scale down the image.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>      Thanks,
>>>>>>>>>>>>>>>>      Alexandr.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 2/7/14 3:00 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>> On 1/22/2014 6:40 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>>>> Hi Alexander,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Before we get too far down the road on this API, I 
>>>>>>>>>>>>>>>>>>> think we
>>>>>>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>>>>>> the way in which MacOS processes multi-resolution 
>>>>>>>>>>>>>>>>>>> images
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> HiDPI
>>>>>>>>>>>>>>>>>>> screens, but have we investigated the processes that
>>>>>>>>>>>>>>>>>>> Windows
>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>> under Windows 8?  My impression is that Windows 8 has
>>>>>>>>>>>>>>>>>>> included a
>>>>>>>>>>>>>>>>>>> number of new techniques for dealing with the high
>>>>>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>>>>>> displays
>>>>>>>>>>>>>>>>>>> that it will run on in the Windows tablet and mobile
>>>>>>>>>>>>>>>>>>> industries
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> that these will also come into play as 4K displays 
>>>>>>>>>>>>>>>>>>> (already
>>>>>>>>>>>>>>>>>>> available)
>>>>>>>>>>>>>>>>>>> become more common on the desktop.  We should make sure
>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> what we
>>>>>>>>>>>>>>>>>>> come up with here can provide native compatibility with
>>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>>> platform's policies and standard practices.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If you've investigated the MS policies I'd like to 
>>>>>>>>>>>>>>>>>>> see a
>>>>>>>>>>>>>>>>>>> summary so
>>>>>>>>>>>>>>>>>>> that we can consider them as we review this API...
>>>>>>>>>>>>>>>>>>     There is the Windows Guidelines for scaling to pixel
>>>>>>>>>>>>>>>>>> density:
>>>>>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/hh465362.aspx 
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     which says that Windows has automatic resource 
>>>>>>>>>>>>>>>>>> loading
>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>> supports
>>>>>>>>>>>>>>>>>> three version of images scaling (100%, 140%, and 180%)
>>>>>>>>>>>>>>>>>> --------------------------------
>>>>>>>>>>>>>>>>>> Without scaling, as the pixel density of a display 
>>>>>>>>>>>>>>>>>> device
>>>>>>>>>>>>>>>>>> increases, the
>>>>>>>>>>>>>>>>>> physical sizes of objects on screen get smaller.
>>>>>>>>>>>>>>>>>> When UI would otherwise be too small to touch and 
>>>>>>>>>>>>>>>>>> when text
>>>>>>>>>>>>>>>>>> gets
>>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>> small to read,
>>>>>>>>>>>>>>>>>> Windows scales the system and app UI to one of the 
>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>> scaling
>>>>>>>>>>>>>>>>>> plateaus:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>      1.0 (100%, no scaling is applied)
>>>>>>>>>>>>>>>>>>      1.4 (140% scaling)
>>>>>>>>>>>>>>>>>>      1.8 (180% scaling)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Windows determines which scaling plateau to use based 
>>>>>>>>>>>>>>>>>> on the
>>>>>>>>>>>>>>>>>> physical
>>>>>>>>>>>>>>>>>> screen size, the screen resolution, the DPI of the
>>>>>>>>>>>>>>>>>> screen, and
>>>>>>>>>>>>>>>>>> form
>>>>>>>>>>>>>>>>>> factor.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Use resource loading for bitmap images in the app 
>>>>>>>>>>>>>>>>>> package
>>>>>>>>>>>>>>>>>> For
>>>>>>>>>>>>>>>>>> bitmap
>>>>>>>>>>>>>>>>>> images stored
>>>>>>>>>>>>>>>>>> in the app package, provide a separate image for each
>>>>>>>>>>>>>>>>>> scaling
>>>>>>>>>>>>>>>>>> factor(100%, 140%, and 180%),
>>>>>>>>>>>>>>>>>> and name your image files using the "scale" naming
>>>>>>>>>>>>>>>>>> convention
>>>>>>>>>>>>>>>>>> described
>>>>>>>>>>>>>>>>>> below.
>>>>>>>>>>>>>>>>>> Windows loads the right image for the current scale
>>>>>>>>>>>>>>>>>> automatically.
>>>>>>>>>>>>>>>>>> --------------------------------
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>   The image name convention for the various scales is:
>>>>>>>>>>>>>>>>>>     images/logo.scale-100.png
>>>>>>>>>>>>>>>>>>     images/logo.scale-140.png
>>>>>>>>>>>>>>>>>>     images/logo.scale-180.png
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    The 'ms-appx:///images/logo.png' uri is used to 
>>>>>>>>>>>>>>>>>> load the
>>>>>>>>>>>>>>>>>> image
>>>>>>>>>>>>>>>>>> in an
>>>>>>>>>>>>>>>>>> application.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    If we want to support this in the same way as it 
>>>>>>>>>>>>>>>>>> is done
>>>>>>>>>>>>>>>>>> for Mac
>>>>>>>>>>>>>>>>>> OS X
>>>>>>>>>>>>>>>>>>    the WToolkit should return MultiResolution image in
>>>>>>>>>>>>>>>>>> case if
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> loaded image has .scale-* qualifiers.
>>>>>>>>>>>>>>>>>>    The Graphics class can request an image with 
>>>>>>>>>>>>>>>>>> necessary
>>>>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>>>>> from the MultiResolution image.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    It seems that nothing should be changed in the
>>>>>>>>>>>>>>>>>> MultiResolution
>>>>>>>>>>>>>>>>>> interface in this case.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>     Thanks,
>>>>>>>>>>>>>>>>>>     Alexandr.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 1/14/14 2:54 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>>>>>>>>>>    bug: 
>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8029339
>>>>>>>>>>>>>>>>>>>>    webrev:
>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.00
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    This is a proposal to introduce an API that 
>>>>>>>>>>>>>>>>>>>> allows to
>>>>>>>>>>>>>>>>>>>> create a
>>>>>>>>>>>>>>>>>>>> custom
>>>>>>>>>>>>>>>>>>>> multi resolution image.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I. It seems reasonable that the API should provide two
>>>>>>>>>>>>>>>>>>>> basic
>>>>>>>>>>>>>>>>>>>> operations:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>   1. Get the resolution variant based on the requested
>>>>>>>>>>>>>>>>>>>> image
>>>>>>>>>>>>>>>>>>>> width and
>>>>>>>>>>>>>>>>>>>> height:
>>>>>>>>>>>>>>>>>>>>      - Image getResolutionVariant(int width, int 
>>>>>>>>>>>>>>>>>>>> height)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>     Usually the system provides the scale factor which
>>>>>>>>>>>>>>>>>>>> represents
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> number of pixels corresponding to each linear unit 
>>>>>>>>>>>>>>>>>>>> on the
>>>>>>>>>>>>>>>>>>>> display.
>>>>>>>>>>>>>>>>>>>>     However, it has sense to combine the scale 
>>>>>>>>>>>>>>>>>>>> factor and
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>>>> transformations to get the actual image size to be
>>>>>>>>>>>>>>>>>>>> displayed.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>   2. Get all provided resolution variants:
>>>>>>>>>>>>>>>>>>>>     - List<Image> getResolutionVariants()
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    There are several uses cases:
>>>>>>>>>>>>>>>>>>>>     - Create a new multi-resolution image based on the
>>>>>>>>>>>>>>>>>>>> given
>>>>>>>>>>>>>>>>>>>> multi-resolution image.
>>>>>>>>>>>>>>>>>>>>     - Pass to the native system the multi-resolution
>>>>>>>>>>>>>>>>>>>> image. For
>>>>>>>>>>>>>>>>>>>> example,
>>>>>>>>>>>>>>>>>>>> a use can set to the system the custom 
>>>>>>>>>>>>>>>>>>>> multi-resolution
>>>>>>>>>>>>>>>>>>>> cursor.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> II. There are some possible ways where the new API 
>>>>>>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>>>>>> added
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>   1. java.awt.Image.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    The 2 new methods can be added to the Image 
>>>>>>>>>>>>>>>>>>>> class. A
>>>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>> override
>>>>>>>>>>>>>>>>>>>>    the getResolutionVariant() and 
>>>>>>>>>>>>>>>>>>>> getResolutionVariants()
>>>>>>>>>>>>>>>>>>>> methods to
>>>>>>>>>>>>>>>>>>>> provide the resolution variants
>>>>>>>>>>>>>>>>>>>>    or there can be default implementations of these
>>>>>>>>>>>>>>>>>>>> methods
>>>>>>>>>>>>>>>>>>>> if a
>>>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>>> puts resolution variants
>>>>>>>>>>>>>>>>>>>>    to the list in the sorted order.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    To check that the image has resolution variants the
>>>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>>> statement can be used:
>>>>>>>>>>>>>>>>>>>> image.getResolutionVariants().size()
>>>>>>>>>>>>>>>>>>>> != 1
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    The disadvantage is that there is an overhead 
>>>>>>>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>>>>>>>> Image
>>>>>>>>>>>>>>>>>>>> class
>>>>>>>>>>>>>>>>>>>> should contain the List object and not all
>>>>>>>>>>>>>>>>>>>>    images can have resolution variants.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>   2. Introduce new MultiResolutionImage interface.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    A user should extend Image class and implement the
>>>>>>>>>>>>>>>>>>>> MultiResolutionImage interface.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    For example:
>>>>>>>>>>>>>>>>>>>>    ---------------------
>>>>>>>>>>>>>>>>>>>>      public class CustomMultiResolutionImage extends
>>>>>>>>>>>>>>>>>>>> BufferedImage
>>>>>>>>>>>>>>>>>>>>              implements MultiResolutionImage {
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>          Image highResolutionImage;
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>          public 
>>>>>>>>>>>>>>>>>>>> CustomMultiResolutionImage(BufferedImage
>>>>>>>>>>>>>>>>>>>> baseImage,
>>>>>>>>>>>>>>>>>>>> BufferedImage highResolutionImage) {
>>>>>>>>>>>>>>>>>>>> super(baseImage.getWidth(),
>>>>>>>>>>>>>>>>>>>> baseImage.getHeight(),
>>>>>>>>>>>>>>>>>>>> baseImage.getType());
>>>>>>>>>>>>>>>>>>>> this.highResolutionImage = highResolutionImage;
>>>>>>>>>>>>>>>>>>>>              Graphics g = getGraphics();
>>>>>>>>>>>>>>>>>>>> g.drawImage(baseImage, 0, 0, null);
>>>>>>>>>>>>>>>>>>>>              g.dispose();
>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>          @Override
>>>>>>>>>>>>>>>>>>>>          public Image getResolutionVariant(int 
>>>>>>>>>>>>>>>>>>>> width, int
>>>>>>>>>>>>>>>>>>>> height) {
>>>>>>>>>>>>>>>>>>>>              return ((width <= getWidth() && height <=
>>>>>>>>>>>>>>>>>>>> getHeight()))
>>>>>>>>>>>>>>>>>>>>                      ? this : highResolutionImage;
>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>          @Override
>>>>>>>>>>>>>>>>>>>>          public List<Image> getResolutionVariants() {
>>>>>>>>>>>>>>>>>>>>              return Arrays.asList(this,
>>>>>>>>>>>>>>>>>>>> highResolutionImage);
>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>>    ---------------------
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>   The current fix adds the MultiResolutionImage 
>>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> public
>>>>>>>>>>>>>>>>>>>> resolution variant rendering hints.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>



From philip.race at oracle.com  Fri May 16 17:12:32 2014
From: philip.race at oracle.com (Phil Race)
Date: Fri, 16 May 2014 10:12:32 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review request for 8029339
 Custom MultiResolution image support on HiDPI displays
In-Reply-To: <537639D5.9000206@oracle.com>
References: <52D51764.8020103@oracle.com> <52DF2F98.3030503@oracle.com>
	<52F4BCEB.9040702@oracle.com> <52F5782A.9060300@oracle.com>
	<52FB7E3E.6050000@oracle.com> <52FC14EC.9080503@oracle.com>
	<53037D3D.80709@oracle.com> <5307E71E.50607@oracle.com>
	<530F3592.40600@oracle.com> <532B00AD.1000704@oracle.com>
	<532B7EC5.9000206@oracle.com> <532C4DD7.1080804@oracle.com>
	<532CD202.5070508@oracle.com> <53302A8E.6090107@oracle.com>
	<53343914.6090004@oracle.com> <533C8DDB.5000406@oracle.com>
	<533E9D42.10409@oracle.com> <53598D86.5020607@oracle.com>
	<535A7509.6050802@oracle.com> <5370DC41.5080608@oracle.com>
	<537639D5.9000206@oracle.com>
Message-ID: <53764700.2060309@oracle.com>

I think Jim was looking at this. I am not sure if you yet answered all 
his questions/concerns.

There's a lot of API here and it will take more time than I have right 
now just to get
my head around it so do not expect a quick answer.

1. Why is there no javadoc on the new API on Toolkit ?

2. What kinds of classes are expected to implement MultiResolutionImage
Application ones or platform ones ?

3. can you better explain all these parameters :

   49      * @param logicalDPIX the logical horizontal DPI of the desktop.
   50      * @param logicalDPIY the logical vertical DPI of the desktop.
   51      * @param baseImageWidth the width of the base image.
   52      * @param baseImageHeight the height of the base image.
   53      * @param destImageWidth the width of the destination image.
   54      * @param destImageHeight the height of the destination image.
   55      * @return image resolution variant.


4.    public List<Image> getResolutionVariants();

So this implies a fixed, known ahead of time set of images ?
Why is it required to have this API ? How will anyone be able to
tell which is which and use the list ?

5.  Why is the rendering hint needed ?

-phil.


On 5/16/2014 9:16 AM, Alexander Scherbatiy wrote:
>
>   Hi Phil,
>
>   I need a reviewer from the 2d group for the fix. Could you take a 
> look at the fix and review it?
>
>   Thanks,
>   Alexandr.
>
>
> On 5/12/2014 6:35 PM, Alexander Scherbatiy wrote:
>>
>>   There was a long thread about the image with sub-pixel resolution 
>> drawing  on Mac OS X:
>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005559.html 
>>
>>
>>  It was pointed out that Icon images that can be programmatically 
>> generated also need to have HiDPI support:
>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005566.html 
>>
>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005569.html 
>>
>>
>>  All requests about Mac OS X HiDPI support were included to the 
>> umbrella issue:
>>    7124410 [macosx] Lion HiDPI support
>>    https://bugs.openjdk.java.net/browse/JDK-7124410
>>
>>  Thanks,
>>  Alexandr.
>>
>> On 4/25/2014 6:45 PM, Alexander Scherbatiy wrote:
>>> On 4/25/2014 2:17 AM, Jim Graham wrote:
>>>> Hi Alexandr,
>>>>
>>>> I asked for who was requesting these facilities and you responded 
>>>> with the solution you are planning to provide.
>>>>
>>>> I don't care what the solution looks like if we have nobody asking 
>>>> for the feature - I am asking who is asking for these capabilities?
>>>
>>>    This is the request from the AWT team for the HiDPI support.
>>>
>>>    Thanks,
>>>    Alexandr.
>>>>
>>>>             ...jim
>>>>
>>>> On 4/4/14 4:53 AM, Alexander Scherbatiy wrote:
>>>>> On 4/3/2014 2:23 AM, Jim Graham wrote:
>>>>>> Hi Alexandr,
>>>>>>
>>>>>> The back and forth is getting confusing here, so I thought I'd 
>>>>>> try to
>>>>>> summarize and start fresh(ish):
>>>>>>
>>>>>> 1. We need to support @2x internally for MacOS compatibility (done).
>>>>>>
>>>>>> 2. We will need to support _DPI images for Win-DPI compatibility 
>>>>>> (TBD).
>>>>>>
>>>>>> 3. Customers may have their own collection of images to bundle
>>>>>> together into an MR image (working on that here).  What is the push
>>>>>> for this?  Is this simply parity with Mac interfaces?
>>>>>
>>>>>          ----------
>>>>>          Image[] resolutionVariants = // get sorted by sizes array of
>>>>> resolution variants;
>>>>>          Image mrImage =
>>>>> Toolkit.getDefaultToolkit().createMRImage(baseImageIndex,
>>>>> resolutionVariants);
>>>>>          ----------
>>>>>
>>>>>       Here is the proposed patch:
>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.04/
>>>>>
>>>>>> 4. Customers may want to synthetically generate images at arbitrary
>>>>>> resolutions (a variation that is impacting this solution). What is
>>>>>> the push for this?
>>>>>          ----------
>>>>>          Image mrImage =
>>>>> Toolkit.getDefaultToolkit().createMRImage(baseImageWidth, 
>>>>> baseImageHeight,
>>>>>                  new float[][]{{100, 100}, {150, 150}, {200, 
>>>>> 200}}, //
>>>>> resolution variants sizes
>>>>>                  (rvWidth, rvHeight) -> {  /* generate a resolution
>>>>> variant */  });
>>>>>         ----------
>>>>>
>>>>>>
>>>>>> 5. I'm guessing that customers might want to override the logic to
>>>>>> choose from among multiple resolutions.  That came from me based on
>>>>>> seeing Mac and Win using different selection logic and our 
>>>>>> history of
>>>>>> developers split between those wanting cross-platform consistency 
>>>>>> and
>>>>>> those wanting consistency with native apps on each platform. Also,
>>>>>> the needs of an animator may differ from the needs of a
>>>>>> resolution-settable-document editor as to how dynamically the images
>>>>>> shift between resolution variants.
>>>>>         ----------
>>>>>          Image[] resolutionVariants = // get sorted by sizes array of
>>>>> resolution variants;
>>>>>          Image mrImage = ImageResolutionHelper.createMRImage(
>>>>>                  (rvWidth, rvHeight, resolutionVariants) -> { /*use a
>>>>> custom logic to choose a resolution variant from an array of 
>>>>> images*/},
>>>>>                  (logicalDPI, baseImageSize, destImageSize) ->
>>>>> destImageSize, // calculate the custom aware resolution variant size
>>>>>                  baseImageIndex, resolutionVariants);
>>>>>         ----------
>>>>>
>>>>>     or just extend the CustomMultiResolutionImage which has Image 
>>>>> as the
>>>>> parent class:
>>>>>
>>>>> --------------------
>>>>>   public class CustomMultiResolutionImage extends
>>>>> AbstractMultiResolutionImage {
>>>>>
>>>>>      @Override
>>>>>      public Image getResolutionVariant(float logicalDPIX, float
>>>>> logicalDPIY,
>>>>>              float baseImageWidth, float baseImageHeight,
>>>>>              float destImageWidth, float destImageHeight) {
>>>>>          // return a resolution variant based on the given logical 
>>>>> DPI,
>>>>>          // base image size, or destination image size
>>>>>      }
>>>>>
>>>>>      @Override
>>>>>      public List<Image> getResolutionVariants() {
>>>>>          // return a list of resolution variants
>>>>>      }
>>>>>
>>>>>      @Override
>>>>>      protected Image getBaseImage() {
>>>>>          // return the base image
>>>>>      }
>>>>> }
>>>>> --------------------
>>>>>>
>>>>>> Is that a fair summary of all of the considerations so far, or did I
>>>>>> miss something?
>>>>>     I think it should cover the main needs.
>>>>>
>>>>>      Thanks,
>>>>>      Alexandr.
>>>>>>
>>>>>>             ...jim
>>>>>>
>>>>>> On 3/27/14 7:43 AM, Alexander Scherbatiy wrote:
>>>>>>>
>>>>>>>   Below are some thoughts about TK.createMRImage(...) method
>>>>>>>
>>>>>>> On 3/24/2014 4:52 PM, Alexander Scherbatiy wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>>   Could you review the updated fix:
>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.03/
>>>>>>>>
>>>>>>>>   - baseImageWidth/Height arguments are added to the
>>>>>>>> getResolutionVariant(...) method
>>>>>>>>   - dest image sizes are reverted to included DPI scale
>>>>>>>>   - AbstractMultiResolutionImage is added. It needs only to 
>>>>>>>> implement
>>>>>>>> only 3 methods from the AbstractMultiResolutionImage class
>>>>>>>>     to create a custom multi-resolution image. For example:
>>>>>>>>
>>>>>>>> On 3/22/2014 3:57 AM, Jim Graham wrote:
>>>>>>>>>
>>>>>>>>> Your code example below can be expressed as an implementation 
>>>>>>>>> of the
>>>>>>>>> single-method, lambda-compatible interface that expresses just 
>>>>>>>>> the
>>>>>>>>> getRV() method. They could easily do:
>>>>>>>>>
>>>>>>>>> final Image baseImage = ...;
>>>>>>>>> TK.createMRImage(new RVInterface() {
>>>>>>>>>     public Image getRV(...) {
>>>>>>>>>         // calculate rvWidth and rvHeight
>>>>>>>>>         // look up rvWidth/rvHeight in a database of images
>>>>>>>>>         // possibly contruct a new image
>>>>>>>>>         return rvImage;
>>>>>>>>>     }
>>>>>>>>> }, baseImage);
>>>>>>>>>
>>>>>>>       The RVInterface mixes the logic that construct an image and
>>>>>>> chooses the necessary resolution variant.
>>>>>>>       It is ok if a developer always implements this interface. 
>>>>>>> If it
>>>>>>> needs to have DPI/Transform/Platform aware RVInterface the image
>>>>>>> construction logic should be separated.
>>>>>>>
>>>>>>>      Does  TK.createMRImage() method implies that Platform aware 
>>>>>>> logic
>>>>>>> should be used for a resolution-variant choosing?
>>>>>>>      If so, may be general createMRImage() can be placed in the
>>>>>>> ImageResolutionHelper.
>>>>>>>>> The main issue I see is if you might want the newly constructed
>>>>>>>>> variants to appear in the List returned from the getVariants()
>>>>>>>>> method.  I'm not sure what value that would have beyond simply
>>>>>>>>> returning the base media that the object uses from which to 
>>>>>>>>> construct
>>>>>>>>> its variants...?
>>>>>>>
>>>>>>>    It can be solved by using something like array of image sizes or
>>>>>>> other seeds and a mapper that can create an image from the given 
>>>>>>> seed.
>>>>>>>
>>>>>>>   It can look like:
>>>>>>> -------------------------
>>>>>>> public class ImageResolutionHelper {
>>>>>>>      public interface RVChooser {
>>>>>>>
>>>>>>>          public Image getRV(
>>>>>>>                  float logicalDPIX, float logicalDPIY,
>>>>>>>                  float baseImageWidth, float baseImageHeight,
>>>>>>>                  float destImageWidth, float destImageHeight,
>>>>>>>                  final Image... resolutionVariants);
>>>>>>>      }
>>>>>>>
>>>>>>>      public static final RVChooser DPI_AWARE = ...;
>>>>>>>      public static final RVChooser TRANSFORM_AWARE = ...;
>>>>>>>
>>>>>>>      // resolutionVariants is an array of  sorted by 
>>>>>>> width/height images
>>>>>>>      static Image createMRImage(final RVChooser rvChooser,
>>>>>>>              final int baseImageIndex, final Image...
>>>>>>> resolutionVariants) { ... }
>>>>>>>
>>>>>>>      // sorted by width/height images should be generated from 
>>>>>>> seeds
>>>>>>>      static <Type> Image createMRImage(final RVChooser rvChooser,
>>>>>>>              final Type baseImageSeed, final Function<Type, Image>
>>>>>>> mapper, final Type... rvSeeds) {...}
>>>>>>> }
>>>>>>>
>>>>>>> public abstract class Toolkit {
>>>>>>>      public abstract Image createMRImage(int baseImageIndex, 
>>>>>>> Image...
>>>>>>> resolutionVariants); // Platform aware rv chooser is used
>>>>>>>      public abstract RVChooser getPlatformRVChooser() ;
>>>>>>> }
>>>>>>> --------------------------
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>>
>>>>>>>>>
>>>>>>>>>>      I think it is better to provide both the 
>>>>>>>>>> MultiResolutionImage
>>>>>>>>>> and
>>>>>>>>>> its implementation based on the given resolution variants array.
>>>>>>>>>
>>>>>>>>> It occurs to me that even if we don't go with a 
>>>>>>>>> lambda-factory-based
>>>>>>>>> approach like what I'm describing, it might make sense to 
>>>>>>>>> provide a
>>>>>>>>> baseMR implementation that they can subclass to keep them from 
>>>>>>>>> trying
>>>>>>>>> to subclass off of BufferedImage instead.  I really would like to
>>>>>>>>> avoid "custom MR images are subclasses of BufImg" if we can as I
>>>>>>>>> think the mix of concepts is a little jarring...
>>>>>>>>>
>>>>>>>>>             ...jim
>>>>>>>>>
>>>>>>>>>>     The implementation could look like:
>>>>>>>>>> ---------------------------------
>>>>>>>>>> public class CustomMultiResolutionImage extends Image implements
>>>>>>>>>> MultiResolutionImage {
>>>>>>>>>>
>>>>>>>>>>      int baseImageIndex;
>>>>>>>>>>      Image[] resolutionVariants;
>>>>>>>>>>
>>>>>>>>>>      public CustomMultiResolutionImage(int baseImageIndex,
>>>>>>>>>>              Image... resolutionVariants) {
>>>>>>>>>>          this.baseImageIndex = baseImageIndex;
>>>>>>>>>>          this.resolutionVariants = resolutionVariants;
>>>>>>>>>>      }
>>>>>>>>>>
>>>>>>>>>>      @Override
>>>>>>>>>>      public int getWidth(ImageObserver observer) {
>>>>>>>>>>          return getBaseImage().getWidth(null);
>>>>>>>>>>      }
>>>>>>>>>>
>>>>>>>>>>      @Override
>>>>>>>>>>      public int getHeight(ImageObserver observer) {
>>>>>>>>>>          return getBaseImage().getHeight(null);
>>>>>>>>>>      }
>>>>>>>>>>
>>>>>>>>>>      @Override
>>>>>>>>>>      public ImageProducer getSource() {
>>>>>>>>>>          return getBaseImage().getSource();
>>>>>>>>>>      }
>>>>>>>>>>
>>>>>>>>>>      @Override
>>>>>>>>>>      public Graphics getGraphics() {
>>>>>>>>>>          return getBaseImage().getGraphics();
>>>>>>>>>>      }
>>>>>>>>>>
>>>>>>>>>>      @Override
>>>>>>>>>>      public Object getProperty(String name, ImageObserver 
>>>>>>>>>> observer) {
>>>>>>>>>>          return getBaseImage().getProperty(name, observer);
>>>>>>>>>>      }
>>>>>>>>>>
>>>>>>>>>>      @Override
>>>>>>>>>>      public Image getResolutionVariant(float logicalDPIX, float
>>>>>>>>>> logicalDPIY,
>>>>>>>>>>              float destinationImageWidth, float
>>>>>>>>>> destinationImageHeight) {
>>>>>>>>>>              // calculate resolution variant width/height
>>>>>>>>>>          return getResolutionVariant(rvWidth, rvHeight);
>>>>>>>>>>      }
>>>>>>>>>>
>>>>>>>>>>      @Override
>>>>>>>>>>      public List<Image> getResolutionVariants() {
>>>>>>>>>>          return Arrays.asList(resolutionVariants);
>>>>>>>>>>      }
>>>>>>>>>>
>>>>>>>>>>      private Image getResolutionVariant(float rvWidth, float
>>>>>>>>>> rvHeight) {
>>>>>>>>>>          // return a resolution variant based on the given 
>>>>>>>>>> width and
>>>>>>>>>> height
>>>>>>>>>>      }
>>>>>>>>>>
>>>>>>>>>>      private Image getBaseImage() {
>>>>>>>>>>          return resolutionVariants[baseImageIndex];
>>>>>>>>>>      }
>>>>>>>>>> }
>>>>>>>>>> ---------------------------------
>>>>>>>>>>
>>>>>>>>>>    Thanks,
>>>>>>>>>>    Alexandr.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Then we provide one of these from TK.get/createImage() when the
>>>>>>>>>>> platform detects @2x, or Win8-style variants.
>>>>>>>>>>>
>>>>>>>>>>> For custom images we provide TK.createMRImage(lambda getRV, 
>>>>>>>>>>> Image
>>>>>>>>>>> variants...) and TK.createMRImage(Image variants...);
>>>>>>>>>>>
>>>>>>>>>>> Since the get<List> method is just bookkeeping, I don't see 
>>>>>>>>>>> them
>>>>>>>>>>> needing to override it, so the getRV() method is really the 
>>>>>>>>>>> only
>>>>>>>>>>> thing
>>>>>>>>>>> they might want to override, and we can tie into the new Lambda
>>>>>>>>>>> capabilities by making a single-method interface for it that 
>>>>>>>>>>> they
>>>>>>>>>>> supply in a factory method.
>>>>>>>>>>>
>>>>>>>>>>> I realize that the interface you created is more fundamentally
>>>>>>>>>>> OO, but
>>>>>>>>>>> the Image class has always been special in this regard in 
>>>>>>>>>>> the AWT
>>>>>>>>>>> ecosystem (in so far as we do not support someone 
>>>>>>>>>>> implementing their
>>>>>>>>>>> own Image subclass even though it is technically possible).
>>>>>>>>>>> Because of
>>>>>>>>>>> this special nature of Image, we end up with the situation 
>>>>>>>>>>> that if
>>>>>>>>>>> someone were given a need to create a subclass of Image, 
>>>>>>>>>>> then they
>>>>>>>>>>> would turn to BufImg as their superclass even though BufImg is
>>>>>>>>>>> essentially an implementation-specific leaf node on the 
>>>>>>>>>>> Image class
>>>>>>>>>>> hierarchy.  This approach with a factory method to create an
>>>>>>>>>>> internal
>>>>>>>>>>> subclass of the new MRI class mirrors the existing cases of 
>>>>>>>>>>> Image
>>>>>>>>>>> objects that come from factories as well.
>>>>>>>>>>>
>>>>>>>>>>> Thoughts?
>>>>>>>>>>>
>>>>>>>>>>>             ...jim
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 3/20/14 7:52 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>    Hello,
>>>>>>>>>>>>
>>>>>>>>>>>>    Could you review the updated version of the fix:
>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.01/
>>>>>>>>>>>>
>>>>>>>>>>>>   - The "getResolutionVariant(int width, int height)" 
>>>>>>>>>>>> method from
>>>>>>>>>>>> MultiResolutionImage class is changed to
>>>>>>>>>>>>     Image getResolutionVariant(float logicalDPIX, float
>>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>> float width, float height, AffineTransform transform);
>>>>>>>>>>>>
>>>>>>>>>>>>   - sun.awt.image.ImageResolutionHelper class is added. The
>>>>>>>>>>>> sun.awt.image.MultiResolutionToolkitImage and
>>>>>>>>>>>> sun.awt.image.MultiResolutionBufferedImage classes are used
>>>>>>>>>>>> PLATFORM  ImageResolutionHelper.
>>>>>>>>>>>>
>>>>>>>>>>>>   The  MultiResolutionImage interface implementation could 
>>>>>>>>>>>> look
>>>>>>>>>>>> like:
>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>> public class CustomMultiResolutionImage extends BufferedImage
>>>>>>>>>>>> implements
>>>>>>>>>>>> MultiResolutionImage {
>>>>>>>>>>>>
>>>>>>>>>>>>      private final Image[] resolutionVariants;
>>>>>>>>>>>>
>>>>>>>>>>>>      public CustomMultiResolutionImage(int baseIndex, Image...
>>>>>>>>>>>> images) {
>>>>>>>>>>>> super(images[baseIndex].getWidth(null),
>>>>>>>>>>>> images[baseIndex].getHeight(null),
>>>>>>>>>>>> BufferedImage.TYPE_INT_RGB);
>>>>>>>>>>>>          this.resolutionVariants = images;
>>>>>>>>>>>>          Graphics g = getGraphics();
>>>>>>>>>>>>          g.drawImage(images[baseIndex], 0, 0, null);
>>>>>>>>>>>>          g.dispose();
>>>>>>>>>>>>      }
>>>>>>>>>>>>
>>>>>>>>>>>>      @Override
>>>>>>>>>>>>      public Image getResolutionVariant(float logicalDPIX, 
>>>>>>>>>>>> float
>>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>>              float width, float height, AffineTransform
>>>>>>>>>>>> transform) {
>>>>>>>>>>>>          return getResolutionVariant(logicalDPIX * width,
>>>>>>>>>>>> logicalDPIY *
>>>>>>>>>>>> height);
>>>>>>>>>>>>      }
>>>>>>>>>>>>
>>>>>>>>>>>>      @Override
>>>>>>>>>>>>      public List<Image> getResolutionVariants() {
>>>>>>>>>>>>          return Arrays.asList(resolutionVariants);
>>>>>>>>>>>>      }
>>>>>>>>>>>>
>>>>>>>>>>>>      public Image getResolutionVariant(double width, double
>>>>>>>>>>>> height) {
>>>>>>>>>>>>          for (Image image : resolutionVariants) {
>>>>>>>>>>>>              if (width <= image.getWidth(null) && height <=
>>>>>>>>>>>> image.getHeight(null)) {
>>>>>>>>>>>>                  return image;
>>>>>>>>>>>>              }
>>>>>>>>>>>>          }
>>>>>>>>>>>>          return this;
>>>>>>>>>>>>      }
>>>>>>>>>>>> }
>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>    Thanks,
>>>>>>>>>>>>    Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>> On 2/27/2014 4:54 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>> On 2/22/2014 3:54 AM, Jim Graham wrote:
>>>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2/18/14 7:33 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>   Hi Jim,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Let's divide the discussion into two part.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   1. Where it is better to hold resolution variants?
>>>>>>>>>>>>>>>      Putting resolution variants in Image class brings some
>>>>>>>>>>>>>>> questions like:
>>>>>>>>>>>>>>>    - Some type of images do not need to have resolution 
>>>>>>>>>>>>>>> variants
>>>>>>>>>>>>>>>    - Should resolution variants have the same type as 
>>>>>>>>>>>>>>> the base
>>>>>>>>>>>>>>> image?
>>>>>>>>>>>>>>>    - getResolutionVariants() method can return copy of the
>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>> list
>>>>>>>>>>>>>>> so add/removeRV methods should be also added.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    There are pros and cons for placing resolution 
>>>>>>>>>>>>>>> variants to
>>>>>>>>>>>>>>> Image
>>>>>>>>>>>>>>> class or to a separate intreface.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I agree that this could be a separate interface. In my 
>>>>>>>>>>>>>> examples
>>>>>>>>>>>>>> below I was just sticking them inside an "Image{}" to 
>>>>>>>>>>>>>> show where
>>>>>>>>>>>>>> they
>>>>>>>>>>>>>> lived in the set of involved objects, not a specific
>>>>>>>>>>>>>> recommendation
>>>>>>>>>>>>>> that they actually be new methods on the base class 
>>>>>>>>>>>>>> itself. I
>>>>>>>>>>>>>> probably should have put a comment there about that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> With respect to add/remove - that is assuming a need for 
>>>>>>>>>>>>>> manual
>>>>>>>>>>>>>> construction of an image set, right? Forgive me if I'm
>>>>>>>>>>>>>> forgetting
>>>>>>>>>>>>>> something, but I seem to recall that manual Multi-Res 
>>>>>>>>>>>>>> images was
>>>>>>>>>>>>>> proposed as a way for developers to introduce @2x support
>>>>>>>>>>>>>> themselves,
>>>>>>>>>>>>>> but if we are internally managing @2x and -DPI variants 
>>>>>>>>>>>>>> for them,
>>>>>>>>>>>>>> then I'm not sure if there is actual developer need to 
>>>>>>>>>>>>>> manually
>>>>>>>>>>>>>> construct their own.  Am I forgetting something?
>>>>>>>>>>>>>    The NSImage has addRepresentation/removeRepresentation
>>>>>>>>>>>>> methods to
>>>>>>>>>>>>> work with image representations on Mac OS X.
>>>>>>>>>>>>>    The java.awt.Image class should provide similar
>>>>>>>>>>>>> functionality to
>>>>>>>>>>>>> have the possibilities as Cocoa on HiDPI displays.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   2. Using scale factor/image sizes/scaled image sizes to
>>>>>>>>>>>>>>> retreive a
>>>>>>>>>>>>>>> resolution variant.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    May be it is better to have a structure that provide all
>>>>>>>>>>>>>>> necessary
>>>>>>>>>>>>>>> information  to query the resolution variant: scale factor,
>>>>>>>>>>>>>>> draw area
>>>>>>>>>>>>>>> width/height, transformed area width/height?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    For example:
>>>>>>>>>>>>>>>    ---------------------
>>>>>>>>>>>>>>>      public interface MultiResolutionImage {
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>          interface DrawAreaInfo {
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>              float getScaleFactor();
>>>>>>>>>>>>>>>              float getAreaWidth();
>>>>>>>>>>>>>>>              float getAreaHeight();
>>>>>>>>>>>>>>>              float getTransformedAreaWidth();
>>>>>>>>>>>>>>>              float getTransformedAreaHeight();
>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>          public Image getResolutionVariant(DrawAreaInfo
>>>>>>>>>>>>>>> drawAreaInfo) ;
>>>>>>>>>>>>>>>          public List<Image> getResolutionVariants();
>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>    ---------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The problem with a constructor is that this is something 
>>>>>>>>>>>>>> that is
>>>>>>>>>>>>>> (potentially) done on every drawImage() call, which means 
>>>>>>>>>>>>>> we are
>>>>>>>>>>>>>> inviting GC into the equation.  If we can come up with a 
>>>>>>>>>>>>>> simple
>>>>>>>>>>>>>> "just
>>>>>>>>>>>>>> a couple/3/4 numbers" way to embed that data into a 
>>>>>>>>>>>>>> method call
>>>>>>>>>>>>>> argument list then we can make this lighter weight.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What about simply having floating point (double) 
>>>>>>>>>>>>>> dimensions on
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> rendered size
>>>>>>>>>>>>>       There should be a way to choose a resolution variant
>>>>>>>>>>>>> based on
>>>>>>>>>>>>> requested drawing size or transformed drawing size.
>>>>>>>>>>>>>       At least a current transformation should be included 
>>>>>>>>>>>>> too.
>>>>>>>>>>>>>> plus a single floating point "logical DPI" for the screen?
>>>>>>>>>>>>>      There is the ID2D1Factory::GetDesktopDpi method which 
>>>>>>>>>>>>> returns
>>>>>>>>>>>>> dpiX and dpiY.
>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316
>>>>>>>>>>>>>
>>>>>>>>>>>>>     That means that logicalDPIX/Y can have different values.
>>>>>>>>>>>>>      At least it is described in the
>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/ff684173
>>>>>>>>>>>>>      "To get the DPI setting, call the 
>>>>>>>>>>>>> ID2D1Factory::GetDesktopDpi
>>>>>>>>>>>>> method. The DPI is returned as two floating-point values, 
>>>>>>>>>>>>> one for
>>>>>>>>>>>>> the
>>>>>>>>>>>>> x-axis and one for the y-axis. In theory, these values can 
>>>>>>>>>>>>> differ.
>>>>>>>>>>>>> Calculate a separate scaling factor for each axis."
>>>>>>>>>>>>>
>>>>>>>>>>>>>   The getResolutionVariant method could look like:
>>>>>>>>>>>>>    --------------------------------------
>>>>>>>>>>>>>     public Image getResolutionVariant(float logicalDPIX, 
>>>>>>>>>>>>> float
>>>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>>>             float widthX, float widthY, AffineTransform
>>>>>>>>>>>>> transform);
>>>>>>>>>>>>>    --------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>>  If the image is known (either passed as an argument or the
>>>>>>>>>>>>>> method is
>>>>>>>>>>>>>> called on the image), then it can provide the original WH.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    The MultiResolutionImage default implementation could 
>>>>>>>>>>>>>>> allow
>>>>>>>>>>>>>>> to use
>>>>>>>>>>>>>>> different strategies like scale factor/transfom/OS based
>>>>>>>>>>>>>>>    to query a resolution variant. The OS based strategy 
>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>> used by
>>>>>>>>>>>>>>> default.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For Mac policy, all we need is the transformed 
>>>>>>>>>>>>>> dimensions, which
>>>>>>>>>>>>>> can
>>>>>>>>>>>>>> be passed in as FP for generality.  For Windows policy, 
>>>>>>>>>>>>>> all we
>>>>>>>>>>>>>> need
>>>>>>>>>>>>>> is logical DPI for the screen.   What other information 
>>>>>>>>>>>>>> would we
>>>>>>>>>>>>>> need, or would an algorithm like to use, that can't be 
>>>>>>>>>>>>>> computed
>>>>>>>>>>>>>> from
>>>>>>>>>>>>>> those 2 pieces?
>>>>>>>>>>>>>      The aim is to provide a base class that can be used to
>>>>>>>>>>>>> create a
>>>>>>>>>>>>> MultiResolutionImage like:
>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/diff/ae53ebce5fa3/src/share/classes/sun/awt/image/MultiResolutionBufferedImage.java 
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>      A developer should be able to implement a custom 
>>>>>>>>>>>>> algorithm to
>>>>>>>>>>>>> query a resolution variant.
>>>>>>>>>>>>>
>>>>>>>>>>>>>     It can be done by overriding the getResolutionVariant 
>>>>>>>>>>>>> image:
>>>>>>>>>>>>>    -----------------------
>>>>>>>>>>>>>         Image mrImage = new MultiResolutionBufferedImage(){
>>>>>>>>>>>>>             @Override
>>>>>>>>>>>>>             public Image getResolutionVariant(...) {
>>>>>>>>>>>>>                 // Custom logic here
>>>>>>>>>>>>>             }
>>>>>>>>>>>>>         };
>>>>>>>>>>>>>    -----------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>    Or it can be done by using resolution variant choosers 
>>>>>>>>>>>>> so a
>>>>>>>>>>>>> developer can implement custom resolution variant query:
>>>>>>>>>>>>>    -----------------------
>>>>>>>>>>>>> public class MultiResolutionBufferedImage implements
>>>>>>>>>>>>> MultiResolutionImage{
>>>>>>>>>>>>>
>>>>>>>>>>>>>     interface ResolutionVariantChooser{
>>>>>>>>>>>>>         Image getResolutionVariant(dpi, size,..., List<Image>
>>>>>>>>>>>>> resolutionVariants);
>>>>>>>>>>>>>     }
>>>>>>>>>>>>>     ResolutionVariantChooser TRANSFORM_BASED = null;
>>>>>>>>>>>>>     ResolutionVariantChooser DPI_BASED = null;
>>>>>>>>>>>>>
>>>>>>>>>>>>>     ResolutionVariantChooser rvChooser;
>>>>>>>>>>>>>
>>>>>>>>>>>>>     @Override
>>>>>>>>>>>>>     public Image getResolutionVariant(dpi, size,...,) {
>>>>>>>>>>>>>         return rvChooser.getResolutionVariant(dpi, size,...,
>>>>>>>>>>>>> getResolutionVariants());
>>>>>>>>>>>>>     }
>>>>>>>>>>>>> }
>>>>>>>>>>>>>    -----------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Thanks,
>>>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2/13/2014 4:42 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>> On 2/12/14 5:59 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>> On 2/8/2014 4:19 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>>> The primary thing that I was concerned about was the
>>>>>>>>>>>>>>>>>> presence of
>>>>>>>>>>>>>>>>>> integers in the API when Windows uses non-integer 
>>>>>>>>>>>>>>>>>> multiples
>>>>>>>>>>>>>>>>>       It would make sense to pass real numbers to the
>>>>>>>>>>>>>>>>> getResolutionVariant() method  if the difference between
>>>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>>>> variants sizes is 1.
>>>>>>>>>>>>>>>>>       It seems that it is not a common case.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I was thinking of other API that is related to this, 
>>>>>>>>>>>>>>>> such as
>>>>>>>>>>>>>>>> the API
>>>>>>>>>>>>>>>> that queries the scaling factor from a SurfaceManager. I
>>>>>>>>>>>>>>>> seem to
>>>>>>>>>>>>>>>> remember some integer return values in that, but 
>>>>>>>>>>>>>>>> Windows might
>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>> the answer 1.4 or 1.8, depending on the screen scaling 
>>>>>>>>>>>>>>>> factor
>>>>>>>>>>>>>>>> that was
>>>>>>>>>>>>>>>> determined from the UI.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In terms of the getResolutionVariant() method here, those
>>>>>>>>>>>>>>>> non-integer
>>>>>>>>>>>>>>>> screen scaling factors don't directly impact this API. 
>>>>>>>>>>>>>>>> But, we
>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>> some issues with the use of integers there from other 
>>>>>>>>>>>>>>>> sources:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - That API assumes that the caller will determine the 
>>>>>>>>>>>>>>>> pixel
>>>>>>>>>>>>>>>> size
>>>>>>>>>>>>>>>> needed, but the actual media choice is determined with
>>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>>> techniques on Mac and Windows so this means that the 
>>>>>>>>>>>>>>>> caller
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>> to worry about platform conventions. Is that the right
>>>>>>>>>>>>>>>> tradeoff?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - The technique recommended for Mac involves computing the
>>>>>>>>>>>>>>>> precise
>>>>>>>>>>>>>>>> size desired using the current transform, which may be a
>>>>>>>>>>>>>>>> floating
>>>>>>>>>>>>>>>> point value, so the integer values used in this API are 
>>>>>>>>>>>>>>>> already
>>>>>>>>>>>>>>>> approximations and there is no documentation on how to
>>>>>>>>>>>>>>>> generate the
>>>>>>>>>>>>>>>> proper integer.  In particular, the current code in SG2D
>>>>>>>>>>>>>>>> naively
>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>> a cast to integer to determine the values to supply which
>>>>>>>>>>>>>>>> means a
>>>>>>>>>>>>>>>> transformed size of W+0.5 will be truncated to W and 
>>>>>>>>>>>>>>>> the lower
>>>>>>>>>>>>>>>> resolution image will be used. Does that conform to Mac
>>>>>>>>>>>>>>>> guidelines? Do
>>>>>>>>>>>>>>>> they require the truncated size to reach W+1 before the 
>>>>>>>>>>>>>>>> next
>>>>>>>>>>>>>>>> size is
>>>>>>>>>>>>>>>> used?  Passing in float or double values would sidestep 
>>>>>>>>>>>>>>>> all of
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> since then the comparisons would be done with full 
>>>>>>>>>>>>>>>> precision,
>>>>>>>>>>>>>>>> but as
>>>>>>>>>>>>>>>> long as we can determine a "best practices compatible 
>>>>>>>>>>>>>>>> with all
>>>>>>>>>>>>>>>> platforms" rule on how to round to integers, then integers
>>>>>>>>>>>>>>>> are OK
>>>>>>>>>>>>>>>> there.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - The Windows document you cite below suggests that the
>>>>>>>>>>>>>>>> determination
>>>>>>>>>>>>>>>> should be made by looking at the Screen DPI and 
>>>>>>>>>>>>>>>> choosing the
>>>>>>>>>>>>>>>> next
>>>>>>>>>>>>>>>> higher media variant based on that screen DPI. They do not
>>>>>>>>>>>>>>>> specify
>>>>>>>>>>>>>>>> choosing media based on the current transform as is 
>>>>>>>>>>>>>>>> done for
>>>>>>>>>>>>>>>> Mac.  If
>>>>>>>>>>>>>>>> we stick with supplying values that are used to 
>>>>>>>>>>>>>>>> determine which
>>>>>>>>>>>>>>>> media
>>>>>>>>>>>>>>>> to use, then on Windows we should not take the 
>>>>>>>>>>>>>>>> transform into
>>>>>>>>>>>>>>>> account,
>>>>>>>>>>>>>>>> but instead query the SurfaceManager for the scale 
>>>>>>>>>>>>>>>> factor and
>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>> transform by those values (even if the current 
>>>>>>>>>>>>>>>> transform was
>>>>>>>>>>>>>>>> manually
>>>>>>>>>>>>>>>> overridden to identity).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There are pros and cons to both approaches.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Mac ensures that you are always using the best media 
>>>>>>>>>>>>>>>> for any
>>>>>>>>>>>>>>>> given
>>>>>>>>>>>>>>>> render operation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But, Windows ensure more consistency in the face of other
>>>>>>>>>>>>>>>> scaling.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The thing to consider is that if you have a 500x500 image
>>>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>>>> 1000x1000 variant and you rendering it at 500x500 and then
>>>>>>>>>>>>>>>> 501x501,
>>>>>>>>>>>>>>>> that first jump will be fairly jarring as the scaled 
>>>>>>>>>>>>>>>> version
>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>> 1000x1000 will not look precisely like the original 
>>>>>>>>>>>>>>>> 500x500
>>>>>>>>>>>>>>>> did.
>>>>>>>>>>>>>>>> With
>>>>>>>>>>>>>>>> @2x images only, this effect is minimized so the 
>>>>>>>>>>>>>>>> advantage of
>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>> using "the best media for a given render operation" may
>>>>>>>>>>>>>>>> outweigh the
>>>>>>>>>>>>>>>> inconsistency issue.  But, on Windows where the media are
>>>>>>>>>>>>>>>> 1.4x or
>>>>>>>>>>>>>>>> 1.8x
>>>>>>>>>>>>>>>> in size, a downscaled image will start to show more
>>>>>>>>>>>>>>>> interpolation
>>>>>>>>>>>>>>>> noise and so the balance of the two choices may shift more
>>>>>>>>>>>>>>>> towards not
>>>>>>>>>>>>>>>> wanting a jarring shift.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We might want one or more of the following:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - Developer chooses policy (TX_AWARE, DPI_AWARE,
>>>>>>>>>>>>>>>> ALWAYS_LARGEST,
>>>>>>>>>>>>>>>> NONE,
>>>>>>>>>>>>>>>> PLATFORM) where the last policy would use TX_AWARE on 
>>>>>>>>>>>>>>>> Mac and
>>>>>>>>>>>>>>>> DPI_AWARE on Windows
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - We create our own policy and always use it (TX_AWARE? or
>>>>>>>>>>>>>>>> DPI_AWARE?)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - We create our own policy that dynamically chooses one 
>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>> above
>>>>>>>>>>>>>>>> strategies depending on platform or available media or ???
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - We could create an optional interface for them to 
>>>>>>>>>>>>>>>> install
>>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>>> own
>>>>>>>>>>>>>>>> algorithm as well.  I think it would work best as a 
>>>>>>>>>>>>>>>> delegate
>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>> that one installs into Image so that it can be used 
>>>>>>>>>>>>>>>> with any
>>>>>>>>>>>>>>>> image
>>>>>>>>>>>>>>>> without having to subclass (it wouldn't really have 
>>>>>>>>>>>>>>>> much to do
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> BufferedImages or VolatileImages, though):
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> class Image {
>>>>>>>>>>>>>>>>     void setResolutionHelper(ImageResolutionHelper foo);
>>>>>>>>>>>>>>>>     List<Image> getResolutionVariants();
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> or:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> class Graphics {
>>>>>>>>>>>>>>>>      void setResolutionHelper(ImageResolutionHelper foo);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> or - anywhere else it could be installed more centrally 
>>>>>>>>>>>>>>>> (per
>>>>>>>>>>>>>>>> App
>>>>>>>>>>>>>>>> context)?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and the interface would be something like one of these
>>>>>>>>>>>>>>>> variants:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> interface ImageResolutionHelper {
>>>>>>>>>>>>>>>>     // This version would prevent substituting a random 
>>>>>>>>>>>>>>>> image:
>>>>>>>>>>>>>>>>     // They have to return an index into the 
>>>>>>>>>>>>>>>> List<Image> for
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> image...
>>>>>>>>>>>>>>>>     public int chooseVariant(Image img, double dpi, 
>>>>>>>>>>>>>>>> number w,
>>>>>>>>>>>>>>>> number h);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> or:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     // This version would allow substituting an arbitrary
>>>>>>>>>>>>>>>> image:
>>>>>>>>>>>>>>>>     public Image getVariant(Image img, double dpi, 
>>>>>>>>>>>>>>>> number w,
>>>>>>>>>>>>>>>> number
>>>>>>>>>>>>>>>> h);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Since they would be in full control of the policy, 
>>>>>>>>>>>>>>>> though, we
>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>> unfortunately always have to call this, there would be 
>>>>>>>>>>>>>>>> no more
>>>>>>>>>>>>>>>> testing
>>>>>>>>>>>>>>>> in SG2D to see "if" we need to deal with DPI, though 
>>>>>>>>>>>>>>>> perhaps we
>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>> document some internal conditions in which we do not 
>>>>>>>>>>>>>>>> call it
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> common cases (but that would have to be well agreed not to
>>>>>>>>>>>>>>>> get in
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> way of reasonable uses of the API and well documented)?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Note that we would have to do a security audit to make 
>>>>>>>>>>>>>>>> sure
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> random image substitution couldn't allow any sort of 
>>>>>>>>>>>>>>>> "screen
>>>>>>>>>>>>>>>> phishing"
>>>>>>>>>>>>>>>> exploit.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> and also what policy they use for choosing scaled 
>>>>>>>>>>>>>>>>>> images.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I don't see a mention of taking the current transform 
>>>>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>>>>> account,
>>>>>>>>>>>>>>>>>> just physical issues like screen DPI and form factor. 
>>>>>>>>>>>>>>>>>> They
>>>>>>>>>>>>>>>>>> talk
>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>> resolution plateaus and in their recommendations 
>>>>>>>>>>>>>>>>>> section they
>>>>>>>>>>>>>>>>>> tell the
>>>>>>>>>>>>>>>>>> developer to use a particular property that tells 
>>>>>>>>>>>>>>>>>> them the
>>>>>>>>>>>>>>>>>> screen
>>>>>>>>>>>>>>>>>> resolution to figure out which image to load if they are
>>>>>>>>>>>>>>>>>> loading
>>>>>>>>>>>>>>>>>> manually.  There is no discussion about dynamically 
>>>>>>>>>>>>>>>>>> loading
>>>>>>>>>>>>>>>>>> multiple
>>>>>>>>>>>>>>>>>> versions of the image based on a dynamic program-applied
>>>>>>>>>>>>>>>>>> transform
>>>>>>>>>>>>>>>>>> factor as is done on MacOS.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Also, they tell developers to draw images to a 
>>>>>>>>>>>>>>>>>> specific size
>>>>>>>>>>>>>>>>>> rather
>>>>>>>>>>>>>>>>>> than using auto-sizing.  That begs the question as to 
>>>>>>>>>>>>>>>>>> how
>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>> interpret a call to draw an image just using a 
>>>>>>>>>>>>>>>>>> location in
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> presence of various DPI factors.
>>>>>>>>>>>>>>>>>       There is an interesting doc that describes how 
>>>>>>>>>>>>>>>>> to write
>>>>>>>>>>>>>>>>> DPI-aware
>>>>>>>>>>>>>>>>> Win32 applications:
>>>>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/dd464646%28v=vs.85%29.aspx 
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>       It is suggested to handle WM_DPICHANGED message, 
>>>>>>>>>>>>>>>>> load
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> graphic
>>>>>>>>>>>>>>>>> that has slightly greater resolution to the current 
>>>>>>>>>>>>>>>>> DPI and
>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>> StretchBlt
>>>>>>>>>>>>>>>>>       to scale down the image.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>      Thanks,
>>>>>>>>>>>>>>>>>      Alexandr.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 2/7/14 3:00 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>> On 1/22/2014 6:40 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>>>>> Hi Alexander,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Before we get too far down the road on this API, I 
>>>>>>>>>>>>>>>>>>>> think we
>>>>>>>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>>>>>>> the way in which MacOS processes multi-resolution 
>>>>>>>>>>>>>>>>>>>> images
>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> HiDPI
>>>>>>>>>>>>>>>>>>>> screens, but have we investigated the processes that
>>>>>>>>>>>>>>>>>>>> Windows
>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>> under Windows 8?  My impression is that Windows 8 has
>>>>>>>>>>>>>>>>>>>> included a
>>>>>>>>>>>>>>>>>>>> number of new techniques for dealing with the high
>>>>>>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>>>>>>> displays
>>>>>>>>>>>>>>>>>>>> that it will run on in the Windows tablet and mobile
>>>>>>>>>>>>>>>>>>>> industries
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> that these will also come into play as 4K displays 
>>>>>>>>>>>>>>>>>>>> (already
>>>>>>>>>>>>>>>>>>>> available)
>>>>>>>>>>>>>>>>>>>> become more common on the desktop.  We should make 
>>>>>>>>>>>>>>>>>>>> sure
>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>> what we
>>>>>>>>>>>>>>>>>>>> come up with here can provide native compatibility 
>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>>>> platform's policies and standard practices.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If you've investigated the MS policies I'd like to 
>>>>>>>>>>>>>>>>>>>> see a
>>>>>>>>>>>>>>>>>>>> summary so
>>>>>>>>>>>>>>>>>>>> that we can consider them as we review this API...
>>>>>>>>>>>>>>>>>>>     There is the Windows Guidelines for scaling to 
>>>>>>>>>>>>>>>>>>> pixel
>>>>>>>>>>>>>>>>>>> density:
>>>>>>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/hh465362.aspx 
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>     which says that Windows has automatic resource 
>>>>>>>>>>>>>>>>>>> loading
>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> supports
>>>>>>>>>>>>>>>>>>> three version of images scaling (100%, 140%, and 180%)
>>>>>>>>>>>>>>>>>>> --------------------------------
>>>>>>>>>>>>>>>>>>> Without scaling, as the pixel density of a display 
>>>>>>>>>>>>>>>>>>> device
>>>>>>>>>>>>>>>>>>> increases, the
>>>>>>>>>>>>>>>>>>> physical sizes of objects on screen get smaller.
>>>>>>>>>>>>>>>>>>> When UI would otherwise be too small to touch and 
>>>>>>>>>>>>>>>>>>> when text
>>>>>>>>>>>>>>>>>>> gets
>>>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>>> small to read,
>>>>>>>>>>>>>>>>>>> Windows scales the system and app UI to one of the 
>>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>> scaling
>>>>>>>>>>>>>>>>>>> plateaus:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>      1.0 (100%, no scaling is applied)
>>>>>>>>>>>>>>>>>>>      1.4 (140% scaling)
>>>>>>>>>>>>>>>>>>>      1.8 (180% scaling)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Windows determines which scaling plateau to use 
>>>>>>>>>>>>>>>>>>> based on the
>>>>>>>>>>>>>>>>>>> physical
>>>>>>>>>>>>>>>>>>> screen size, the screen resolution, the DPI of the
>>>>>>>>>>>>>>>>>>> screen, and
>>>>>>>>>>>>>>>>>>> form
>>>>>>>>>>>>>>>>>>> factor.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Use resource loading for bitmap images in the app 
>>>>>>>>>>>>>>>>>>> package
>>>>>>>>>>>>>>>>>>> For
>>>>>>>>>>>>>>>>>>> bitmap
>>>>>>>>>>>>>>>>>>> images stored
>>>>>>>>>>>>>>>>>>> in the app package, provide a separate image for each
>>>>>>>>>>>>>>>>>>> scaling
>>>>>>>>>>>>>>>>>>> factor(100%, 140%, and 180%),
>>>>>>>>>>>>>>>>>>> and name your image files using the "scale" naming
>>>>>>>>>>>>>>>>>>> convention
>>>>>>>>>>>>>>>>>>> described
>>>>>>>>>>>>>>>>>>> below.
>>>>>>>>>>>>>>>>>>> Windows loads the right image for the current scale
>>>>>>>>>>>>>>>>>>> automatically.
>>>>>>>>>>>>>>>>>>> --------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>   The image name convention for the various scales is:
>>>>>>>>>>>>>>>>>>>     images/logo.scale-100.png
>>>>>>>>>>>>>>>>>>>     images/logo.scale-140.png
>>>>>>>>>>>>>>>>>>>     images/logo.scale-180.png
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>    The 'ms-appx:///images/logo.png' uri is used to 
>>>>>>>>>>>>>>>>>>> load the
>>>>>>>>>>>>>>>>>>> image
>>>>>>>>>>>>>>>>>>> in an
>>>>>>>>>>>>>>>>>>> application.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>    If we want to support this in the same way as it 
>>>>>>>>>>>>>>>>>>> is done
>>>>>>>>>>>>>>>>>>> for Mac
>>>>>>>>>>>>>>>>>>> OS X
>>>>>>>>>>>>>>>>>>>    the WToolkit should return MultiResolution image in
>>>>>>>>>>>>>>>>>>> case if
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> loaded image has .scale-* qualifiers.
>>>>>>>>>>>>>>>>>>>    The Graphics class can request an image with 
>>>>>>>>>>>>>>>>>>> necessary
>>>>>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>>>>>> from the MultiResolution image.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>    It seems that nothing should be changed in the
>>>>>>>>>>>>>>>>>>> MultiResolution
>>>>>>>>>>>>>>>>>>> interface in this case.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>     Thanks,
>>>>>>>>>>>>>>>>>>>     Alexandr.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 1/14/14 2:54 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>>>>>>>>>>>    bug: 
>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8029339
>>>>>>>>>>>>>>>>>>>>>    webrev:
>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.00
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>    This is a proposal to introduce an API that 
>>>>>>>>>>>>>>>>>>>>> allows to
>>>>>>>>>>>>>>>>>>>>> create a
>>>>>>>>>>>>>>>>>>>>> custom
>>>>>>>>>>>>>>>>>>>>> multi resolution image.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I. It seems reasonable that the API should provide 
>>>>>>>>>>>>>>>>>>>>> two
>>>>>>>>>>>>>>>>>>>>> basic
>>>>>>>>>>>>>>>>>>>>> operations:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   1. Get the resolution variant based on the 
>>>>>>>>>>>>>>>>>>>>> requested
>>>>>>>>>>>>>>>>>>>>> image
>>>>>>>>>>>>>>>>>>>>> width and
>>>>>>>>>>>>>>>>>>>>> height:
>>>>>>>>>>>>>>>>>>>>>      - Image getResolutionVariant(int width, int 
>>>>>>>>>>>>>>>>>>>>> height)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>     Usually the system provides the scale factor 
>>>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>>>> represents
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> number of pixels corresponding to each linear unit 
>>>>>>>>>>>>>>>>>>>>> on the
>>>>>>>>>>>>>>>>>>>>> display.
>>>>>>>>>>>>>>>>>>>>>     However, it has sense to combine the scale 
>>>>>>>>>>>>>>>>>>>>> factor and
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>>>>> transformations to get the actual image size to be
>>>>>>>>>>>>>>>>>>>>> displayed.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   2. Get all provided resolution variants:
>>>>>>>>>>>>>>>>>>>>>     - List<Image> getResolutionVariants()
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>    There are several uses cases:
>>>>>>>>>>>>>>>>>>>>>     - Create a new multi-resolution image based on 
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> given
>>>>>>>>>>>>>>>>>>>>> multi-resolution image.
>>>>>>>>>>>>>>>>>>>>>     - Pass to the native system the multi-resolution
>>>>>>>>>>>>>>>>>>>>> image. For
>>>>>>>>>>>>>>>>>>>>> example,
>>>>>>>>>>>>>>>>>>>>> a use can set to the system the custom 
>>>>>>>>>>>>>>>>>>>>> multi-resolution
>>>>>>>>>>>>>>>>>>>>> cursor.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> II. There are some possible ways where the new API 
>>>>>>>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>>>>>>> added
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   1. java.awt.Image.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>    The 2 new methods can be added to the Image 
>>>>>>>>>>>>>>>>>>>>> class. A
>>>>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>> override
>>>>>>>>>>>>>>>>>>>>>    the getResolutionVariant() and 
>>>>>>>>>>>>>>>>>>>>> getResolutionVariants()
>>>>>>>>>>>>>>>>>>>>> methods to
>>>>>>>>>>>>>>>>>>>>> provide the resolution variants
>>>>>>>>>>>>>>>>>>>>>    or there can be default implementations of these
>>>>>>>>>>>>>>>>>>>>> methods
>>>>>>>>>>>>>>>>>>>>> if a
>>>>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>>>> puts resolution variants
>>>>>>>>>>>>>>>>>>>>>    to the list in the sorted order.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>    To check that the image has resolution variants 
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>>>> statement can be used:
>>>>>>>>>>>>>>>>>>>>> image.getResolutionVariants().size()
>>>>>>>>>>>>>>>>>>>>> != 1
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>    The disadvantage is that there is an overhead 
>>>>>>>>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>>>>>>>>> Image
>>>>>>>>>>>>>>>>>>>>> class
>>>>>>>>>>>>>>>>>>>>> should contain the List object and not all
>>>>>>>>>>>>>>>>>>>>>    images can have resolution variants.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   2. Introduce new MultiResolutionImage interface.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>    A user should extend Image class and implement the
>>>>>>>>>>>>>>>>>>>>> MultiResolutionImage interface.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>    For example:
>>>>>>>>>>>>>>>>>>>>>    ---------------------
>>>>>>>>>>>>>>>>>>>>>      public class CustomMultiResolutionImage extends
>>>>>>>>>>>>>>>>>>>>> BufferedImage
>>>>>>>>>>>>>>>>>>>>>              implements MultiResolutionImage {
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>          Image highResolutionImage;
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>          public 
>>>>>>>>>>>>>>>>>>>>> CustomMultiResolutionImage(BufferedImage
>>>>>>>>>>>>>>>>>>>>> baseImage,
>>>>>>>>>>>>>>>>>>>>> BufferedImage highResolutionImage) {
>>>>>>>>>>>>>>>>>>>>> super(baseImage.getWidth(),
>>>>>>>>>>>>>>>>>>>>> baseImage.getHeight(),
>>>>>>>>>>>>>>>>>>>>> baseImage.getType());
>>>>>>>>>>>>>>>>>>>>> this.highResolutionImage = highResolutionImage;
>>>>>>>>>>>>>>>>>>>>>              Graphics g = getGraphics();
>>>>>>>>>>>>>>>>>>>>> g.drawImage(baseImage, 0, 0, null);
>>>>>>>>>>>>>>>>>>>>>              g.dispose();
>>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>          @Override
>>>>>>>>>>>>>>>>>>>>>          public Image getResolutionVariant(int 
>>>>>>>>>>>>>>>>>>>>> width, int
>>>>>>>>>>>>>>>>>>>>> height) {
>>>>>>>>>>>>>>>>>>>>>              return ((width <= getWidth() && 
>>>>>>>>>>>>>>>>>>>>> height <=
>>>>>>>>>>>>>>>>>>>>> getHeight()))
>>>>>>>>>>>>>>>>>>>>>                      ? this : highResolutionImage;
>>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>          @Override
>>>>>>>>>>>>>>>>>>>>>          public List<Image> getResolutionVariants() {
>>>>>>>>>>>>>>>>>>>>>              return Arrays.asList(this,
>>>>>>>>>>>>>>>>>>>>> highResolutionImage);
>>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>>>    ---------------------
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   The current fix adds the MultiResolutionImage 
>>>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> public
>>>>>>>>>>>>>>>>>>>>> resolution variant rendering hints.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>



From philip.race at oracle.com  Fri May 16 19:33:41 2014
From: philip.race at oracle.com (Phil Race)
Date: Fri, 16 May 2014 12:33:41 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> JDK-8041679 Replace uses of
 StringBuffer with StringBuilder within the JDK
In-Reply-To: <007101BF-30BC-4761-A13A-0AE1EAD36DF5@oracle.com>
References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com>	<5371FDBD.9020002@oracle.com>	<0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com>	<53728B83.1060307@oracle.com>	<8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com>	<537331E5.4070108@oracle.com>
	<007101BF-30BC-4761-A13A-0AE1EAD36DF5@oracle.com>
Message-ID: <53766815.40600@oracle.com>

On 5/16/2014 5:13 AM, Paul Sandoz wrote:
> On May 14, 2014, at 11:05 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>> :
>>>
>>> This code is under src/share/classes, so it's not clear to me what classes i can modify and push in the jdk9-dev/jdk repo or not. It's confusing! Is there a list online somewhere?
>>>
>>> Out of all the classes here:
>>>
>>>    http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/
>>>
>>> exactly which ones should be pushed to the client forest and which ones to the jdk9-dev forest? all of them, or just a sub-set?
All of the classes in that webrev are client (awt/swing/2d) so should go 
to client.


BTW I am behind on email but w.r.t the variable changes, then if you at 
least make it consistent that
will be fine by me.

 > -phil. Is there a white-list of packages available to determine which 
classes should be pushed to the client jdk repo rather than the dev jdk 
repo?

Any public API with a package prefix that begins with
java.applet, java.awt, java.beans,  javax.imageio, javax.print, 
javax.sound, javax.swing
and all implementation classes thereof ..

-phil.




From omajid at redhat.com  Sat May 17 00:45:30 2014
From: omajid at redhat.com (Omair Majid)
Date: Fri, 16 May 2014 20:45:30 -0400
Subject: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg
Message-ID: <20140517004529.GD4370@redhat.com>

Hi,

Webrevs are at:
http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/00
http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/00.jdk

This patch modifies OpenJDK to allow building and running using the
system copy of libjpeg. This follows my previous changes for lcms
and a lot of the decisions made on that patch apply here.

This is the last of my system-library patches :)

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681


From mike.duigou at oracle.com  Sat May 17 03:37:56 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 16 May 2014 20:37:56 -0700
Subject: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg
In-Reply-To: <20140517004529.GD4370@redhat.com>
References: <20140517004529.GD4370@redhat.com>
Message-ID: <8A315662-FB18-4387-908A-B93AC1A2E395@oracle.com>

[not a review]

On May 16 2014, at 17:45 , Omair Majid <omajid at redhat.com> wrote:

> Hi,
> 
> Webrevs are at:
> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/00
> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/00.jdk
> 
> This patch modifies OpenJDK to allow building and running using the
> system copy of libjpeg. This follows my previous changes for lcms
> and a lot of the decisions made on that patch apply here.
> 
> This is the last of my system-library patches :)

A very useful contribution!

Mike



From paul.sandoz at oracle.com  Mon May 19 06:53:52 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 19 May 2014 07:53:52 +0100
Subject: [OpenJDK 2D-Dev] <AWT Dev> JDK-8041679 Replace uses of
	StringBuffer with StringBuilder within the JDK
In-Reply-To: <53766815.40600@oracle.com>
References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com>	<5371FDBD.9020002@oracle.com>	<0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com>	<53728B83.1060307@oracle.com>	<8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com>	<537331E5.4070108@oracle.com>
	<007101BF-30BC-4761-A13A-0AE1EAD36DF5@oracle.com>
	<53766815.40600@oracle.com>
Message-ID: <6F7CE86A-E4B7-4F6B-B698-6426890D1409@oracle.com>

On May 16, 2014, at 8:33 PM, Phil Race <philip.race at oracle.com> wrote:
> On 5/16/2014 5:13 AM, Paul Sandoz wrote:
>> On May 14, 2014, at 11:05 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>> :
>>>> 
>>>> This code is under src/share/classes, so it's not clear to me what classes i can modify and push in the jdk9-dev/jdk repo or not. It's confusing! Is there a list online somewhere?
>>>> 
>>>> Out of all the classes here:
>>>> 
>>>>   http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/
>>>> 
>>>> exactly which ones should be pushed to the client forest and which ones to the jdk9-dev forest? all of them, or just a sub-set?
> All of the classes in that webrev are client (awt/swing/2d) so should go to client.
> 
> 
> BTW I am behind on email but w.r.t the variable changes, then if you at least make it consistent that
> will be fine by me.
> 

I updated to avoid the unnecessary name change you pointed out, but i have left all others after reviewing.


> > -phil. Is there a white-list of packages available to determine which classes should be pushed to the client jdk repo rather than the dev jdk repo?
> 
> Any public API with a package prefix that begins with
> java.applet, java.awt, java.beans,  javax.imageio, javax.print, javax.sound, javax.swing
> and all implementation classes thereof ..
> 

Thanks.

If i don't have permission to push to the client repo (which might be likely) i will need to hand over the patch to yourself or Sergey to commit. And i presume this will have to be a separate issue.

How long would it take for the changes to the client jdk repo to make it's way into the jdk9-dev jdk repo?

--

It's quite clear to me this process does not scale. The amount of work that has to be done to treat the above mentioned packages separately is rapidly accelerating away from the work required to make such changes to the point at which it is extremely tempting to not bother to make such changes, which is bad because code starts ossifying.

What happens if i just commit to dev/jdk instead? :-)

Paul.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140519/faad1fb5/signature.asc>

From Alan.Bateman at oracle.com  Mon May 19 07:50:52 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 19 May 2014 08:50:52 +0100
Subject: [OpenJDK 2D-Dev] <AWT Dev> JDK-8041679 Replace uses of
 StringBuffer with StringBuilder within the JDK
In-Reply-To: <6F7CE86A-E4B7-4F6B-B698-6426890D1409@oracle.com>
References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com>	<5371FDBD.9020002@oracle.com>	<0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com>	<53728B83.1060307@oracle.com>	<8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com>	<537331E5.4070108@oracle.com>	<007101BF-30BC-4761-A13A-0AE1EAD36DF5@oracle.com>	<53766815.40600@oracle.com>
	<6F7CE86A-E4B7-4F6B-B698-6426890D1409@oracle.com>
Message-ID: <5379B7DC.2020206@oracle.com>

On 19/05/2014 07:53, Paul Sandoz wrote:
> If i don't have permission to push to the client repo (which might be likely) i will need to hand over the patch to yourself or Sergey to commit. And i presume this will have to be a separate issue.
If you do decide to split this then it will require creating a second 
issue JIRA to avoid running foul of jcheck when jdk/client eventually 
pushes to jdk/dev. I don't know how often jdk9/client integrates into 
jdk9/dev but it doesn't seem to be very frequent (hg incoming suggests 
there is currently about a month of changes backed up in jdk9/client but 
there may be issues to explain this).

For this specific case then it doesn't seem worth it, it would be much 
less effort to just push the lot to jdk9/dev. Clearly if there were 
substantive changes then it would be important to push the changes to 
the forest where they are most likely to get tested but it hardly seems 
worth it here. From what I can tell then Phil or others sync up 
jdk9/client regularly and that might be the most efficient way to get 
these changes into jdk9/client.

-Alan


From alexandr.scherbatiy at oracle.com  Mon May 19 10:46:47 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Mon, 19 May 2014 14:46:47 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review request for 8029339
 Custom MultiResolution image support on HiDPI displays
In-Reply-To: <53764700.2060309@oracle.com>
References: <52D51764.8020103@oracle.com> <52DF2F98.3030503@oracle.com>
	<52F4BCEB.9040702@oracle.com> <52F5782A.9060300@oracle.com>
	<52FB7E3E.6050000@oracle.com> <52FC14EC.9080503@oracle.com>
	<53037D3D.80709@oracle.com> <5307E71E.50607@oracle.com>
	<530F3592.40600@oracle.com> <532B00AD.1000704@oracle.com>
	<532B7EC5.9000206@oracle.com> <532C4DD7.1080804@oracle.com>
	<532CD202.5070508@oracle.com> <53302A8E.6090107@oracle.com>
	<53343914.6090004@oracle.com> <533C8DDB.5000406@oracle.com>
	<533E9D42.10409@oracle.com> <53598D86.5020607@oracle.com>
	<535A7509.6050802@oracle.com> <5370DC41.5080608@oracle.com>
	<537639D5.9000206@oracle.com> <53764700.2060309@oracle.com>
Message-ID: <5379E117.6010202@oracle.com>


   Hi Phil,

On 5/16/2014 9:12 PM, Phil Race wrote:
> I think Jim was looking at this. I am not sure if you yet answered all 
> his questions/concerns.
>
> There's a lot of API here and it will take more time than I have right 
> now just to get
> my head around it so do not expect a quick answer.
>
> 1. Why is there no javadoc on the new API on Toolkit ?
   It was decided to split the original issue on two parts:
        - this fix adds only MultiResolutionImage interface and 
AbstractMultiResolutionImage class.
            Here is the webrev for it: 
http://cr.openjdk.java.net/~alexsch/8029339/webrev.05/
       - the Toolkit related API is moved to the separate issue

   Could you review the current fix:
      http://cr.openjdk.java.net/~alexsch/8029339/webrev.05/

> 2. What kinds of classes are expected to implement MultiResolutionImage
> Application ones or platform ones ?
     Both.
     - Application: A developer can provide a set of images with 
different resolutions to create a multi-resolution image. An image with 
best-fitting resolution
         will be drawn on HiDPI display.
     - Platform: we used it to support Aqua L&F on HiDPI displays.

> 3. can you better explain all these parameters :
>
>   49      * @param logicalDPIX the logical horizontal DPI of the desktop.
>   50      * @param logicalDPIY the logical vertical DPI of the desktop.
>   51      * @param baseImageWidth the width of the base image.
>   52      * @param baseImageHeight the height of the base image.
>   53      * @param destImageWidth the width of the destination image.
>   54      * @param destImageHeight the height of the destination image.
>   55      * @return image resolution variant.

     Could we postpone it to the CCC request?

>
> 4.    public List<Image> getResolutionVariants();
>
> So this implies a fixed, known ahead of time set of images ?
> Why is it required to have this API ? How will anyone be able to
> tell which is which and use the list ?

    Here are some usages from the JDK code:
     - AquaImagefactory.getAppIconCompositedOn(final Image background)
        The original multi-resolution image is used to create another 
multi-resolution image with the background
     - AquaUtils.generateLightenedImage(Image image, ImageFilter filter)
       The original multi-resolution image is used to create lightening 
multi-resolution image
     - CImage.createFromImage(final Image image)
         Resolution variants from a multi-resolution image are used to 
create an NSImage
     - CCustomCursor:  it is possible set a custom cursor which contains 
resolution variants to the native system

     Usually the getResolutionVariants() method is used to create one 
multi-resolution image based on the another multi-resolution image.

> 5. Why is the rendering hint needed ?
       Someone can manually switch off the multi-resolution image 
drawing from graphics so only the base image will be drawn.
       It is useful for the performance reason. There is a choice to 
draw the high-resolution image slowly or the low-resolution image faster.

    Thanks,
    Alexandr.
> -phil.
>
>
> On 5/16/2014 9:16 AM, Alexander Scherbatiy wrote:
>>
>>   Hi Phil,
>>
>>   I need a reviewer from the 2d group for the fix. Could you take a 
>> look at the fix and review it?
>>
>>   Thanks,
>>   Alexandr.
>>
>>
>> On 5/12/2014 6:35 PM, Alexander Scherbatiy wrote:
>>>
>>>   There was a long thread about the image with sub-pixel resolution 
>>> drawing  on Mac OS X:
>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005559.html 
>>>
>>>
>>>  It was pointed out that Icon images that can be programmatically 
>>> generated also need to have HiDPI support:
>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005566.html 
>>>
>>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005569.html 
>>>
>>>
>>>  All requests about Mac OS X HiDPI support were included to the 
>>> umbrella issue:
>>>    7124410 [macosx] Lion HiDPI support
>>>    https://bugs.openjdk.java.net/browse/JDK-7124410
>>>
>>>  Thanks,
>>>  Alexandr.
>>>
>>> On 4/25/2014 6:45 PM, Alexander Scherbatiy wrote:
>>>> On 4/25/2014 2:17 AM, Jim Graham wrote:
>>>>> Hi Alexandr,
>>>>>
>>>>> I asked for who was requesting these facilities and you responded 
>>>>> with the solution you are planning to provide.
>>>>>
>>>>> I don't care what the solution looks like if we have nobody asking 
>>>>> for the feature - I am asking who is asking for these capabilities?
>>>>
>>>>    This is the request from the AWT team for the HiDPI support.
>>>>
>>>>    Thanks,
>>>>    Alexandr.
>>>>>
>>>>>             ...jim
>>>>>
>>>>> On 4/4/14 4:53 AM, Alexander Scherbatiy wrote:
>>>>>> On 4/3/2014 2:23 AM, Jim Graham wrote:
>>>>>>> Hi Alexandr,
>>>>>>>
>>>>>>> The back and forth is getting confusing here, so I thought I'd 
>>>>>>> try to
>>>>>>> summarize and start fresh(ish):
>>>>>>>
>>>>>>> 1. We need to support @2x internally for MacOS compatibility 
>>>>>>> (done).
>>>>>>>
>>>>>>> 2. We will need to support _DPI images for Win-DPI compatibility 
>>>>>>> (TBD).
>>>>>>>
>>>>>>> 3. Customers may have their own collection of images to bundle
>>>>>>> together into an MR image (working on that here). What is the push
>>>>>>> for this?  Is this simply parity with Mac interfaces?
>>>>>>
>>>>>>          ----------
>>>>>>          Image[] resolutionVariants = // get sorted by sizes 
>>>>>> array of
>>>>>> resolution variants;
>>>>>>          Image mrImage =
>>>>>> Toolkit.getDefaultToolkit().createMRImage(baseImageIndex,
>>>>>> resolutionVariants);
>>>>>>          ----------
>>>>>>
>>>>>>       Here is the proposed patch:
>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.04/
>>>>>>
>>>>>>> 4. Customers may want to synthetically generate images at arbitrary
>>>>>>> resolutions (a variation that is impacting this solution). What is
>>>>>>> the push for this?
>>>>>>          ----------
>>>>>>          Image mrImage =
>>>>>> Toolkit.getDefaultToolkit().createMRImage(baseImageWidth, 
>>>>>> baseImageHeight,
>>>>>>                  new float[][]{{100, 100}, {150, 150}, {200, 
>>>>>> 200}}, //
>>>>>> resolution variants sizes
>>>>>>                  (rvWidth, rvHeight) -> {  /* generate a resolution
>>>>>> variant */  });
>>>>>>         ----------
>>>>>>
>>>>>>>
>>>>>>> 5. I'm guessing that customers might want to override the logic to
>>>>>>> choose from among multiple resolutions.  That came from me based on
>>>>>>> seeing Mac and Win using different selection logic and our 
>>>>>>> history of
>>>>>>> developers split between those wanting cross-platform 
>>>>>>> consistency and
>>>>>>> those wanting consistency with native apps on each platform. Also,
>>>>>>> the needs of an animator may differ from the needs of a
>>>>>>> resolution-settable-document editor as to how dynamically the 
>>>>>>> images
>>>>>>> shift between resolution variants.
>>>>>>         ----------
>>>>>>          Image[] resolutionVariants = // get sorted by sizes 
>>>>>> array of
>>>>>> resolution variants;
>>>>>>          Image mrImage = ImageResolutionHelper.createMRImage(
>>>>>>                  (rvWidth, rvHeight, resolutionVariants) -> { 
>>>>>> /*use a
>>>>>> custom logic to choose a resolution variant from an array of 
>>>>>> images*/},
>>>>>>                  (logicalDPI, baseImageSize, destImageSize) ->
>>>>>> destImageSize, // calculate the custom aware resolution variant size
>>>>>>                  baseImageIndex, resolutionVariants);
>>>>>>         ----------
>>>>>>
>>>>>>     or just extend the CustomMultiResolutionImage which has Image 
>>>>>> as the
>>>>>> parent class:
>>>>>>
>>>>>> --------------------
>>>>>>   public class CustomMultiResolutionImage extends
>>>>>> AbstractMultiResolutionImage {
>>>>>>
>>>>>>      @Override
>>>>>>      public Image getResolutionVariant(float logicalDPIX, float
>>>>>> logicalDPIY,
>>>>>>              float baseImageWidth, float baseImageHeight,
>>>>>>              float destImageWidth, float destImageHeight) {
>>>>>>          // return a resolution variant based on the given 
>>>>>> logical DPI,
>>>>>>          // base image size, or destination image size
>>>>>>      }
>>>>>>
>>>>>>      @Override
>>>>>>      public List<Image> getResolutionVariants() {
>>>>>>          // return a list of resolution variants
>>>>>>      }
>>>>>>
>>>>>>      @Override
>>>>>>      protected Image getBaseImage() {
>>>>>>          // return the base image
>>>>>>      }
>>>>>> }
>>>>>> --------------------
>>>>>>>
>>>>>>> Is that a fair summary of all of the considerations so far, or 
>>>>>>> did I
>>>>>>> miss something?
>>>>>>     I think it should cover the main needs.
>>>>>>
>>>>>>      Thanks,
>>>>>>      Alexandr.
>>>>>>>
>>>>>>>             ...jim
>>>>>>>
>>>>>>> On 3/27/14 7:43 AM, Alexander Scherbatiy wrote:
>>>>>>>>
>>>>>>>>   Below are some thoughts about TK.createMRImage(...) method
>>>>>>>>
>>>>>>>> On 3/24/2014 4:52 PM, Alexander Scherbatiy wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>>   Could you review the updated fix:
>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.03/
>>>>>>>>>
>>>>>>>>>   - baseImageWidth/Height arguments are added to the
>>>>>>>>> getResolutionVariant(...) method
>>>>>>>>>   - dest image sizes are reverted to included DPI scale
>>>>>>>>>   - AbstractMultiResolutionImage is added. It needs only to 
>>>>>>>>> implement
>>>>>>>>> only 3 methods from the AbstractMultiResolutionImage class
>>>>>>>>>     to create a custom multi-resolution image. For example:
>>>>>>>>>
>>>>>>>>> On 3/22/2014 3:57 AM, Jim Graham wrote:
>>>>>>>>>>
>>>>>>>>>> Your code example below can be expressed as an implementation 
>>>>>>>>>> of the
>>>>>>>>>> single-method, lambda-compatible interface that expresses 
>>>>>>>>>> just the
>>>>>>>>>> getRV() method. They could easily do:
>>>>>>>>>>
>>>>>>>>>> final Image baseImage = ...;
>>>>>>>>>> TK.createMRImage(new RVInterface() {
>>>>>>>>>>     public Image getRV(...) {
>>>>>>>>>>         // calculate rvWidth and rvHeight
>>>>>>>>>>         // look up rvWidth/rvHeight in a database of images
>>>>>>>>>>         // possibly contruct a new image
>>>>>>>>>>         return rvImage;
>>>>>>>>>>     }
>>>>>>>>>> }, baseImage);
>>>>>>>>>>
>>>>>>>>       The RVInterface mixes the logic that construct an image and
>>>>>>>> chooses the necessary resolution variant.
>>>>>>>>       It is ok if a developer always implements this interface. 
>>>>>>>> If it
>>>>>>>> needs to have DPI/Transform/Platform aware RVInterface the image
>>>>>>>> construction logic should be separated.
>>>>>>>>
>>>>>>>>      Does  TK.createMRImage() method implies that Platform 
>>>>>>>> aware logic
>>>>>>>> should be used for a resolution-variant choosing?
>>>>>>>>      If so, may be general createMRImage() can be placed in the
>>>>>>>> ImageResolutionHelper.
>>>>>>>>>> The main issue I see is if you might want the newly constructed
>>>>>>>>>> variants to appear in the List returned from the getVariants()
>>>>>>>>>> method.  I'm not sure what value that would have beyond simply
>>>>>>>>>> returning the base media that the object uses from which to 
>>>>>>>>>> construct
>>>>>>>>>> its variants...?
>>>>>>>>
>>>>>>>>    It can be solved by using something like array of image 
>>>>>>>> sizes or
>>>>>>>> other seeds and a mapper that can create an image from the 
>>>>>>>> given seed.
>>>>>>>>
>>>>>>>>   It can look like:
>>>>>>>> -------------------------
>>>>>>>> public class ImageResolutionHelper {
>>>>>>>>      public interface RVChooser {
>>>>>>>>
>>>>>>>>          public Image getRV(
>>>>>>>>                  float logicalDPIX, float logicalDPIY,
>>>>>>>>                  float baseImageWidth, float baseImageHeight,
>>>>>>>>                  float destImageWidth, float destImageHeight,
>>>>>>>>                  final Image... resolutionVariants);
>>>>>>>>      }
>>>>>>>>
>>>>>>>>      public static final RVChooser DPI_AWARE = ...;
>>>>>>>>      public static final RVChooser TRANSFORM_AWARE = ...;
>>>>>>>>
>>>>>>>>      // resolutionVariants is an array of  sorted by 
>>>>>>>> width/height images
>>>>>>>>      static Image createMRImage(final RVChooser rvChooser,
>>>>>>>>              final int baseImageIndex, final Image...
>>>>>>>> resolutionVariants) { ... }
>>>>>>>>
>>>>>>>>      // sorted by width/height images should be generated from 
>>>>>>>> seeds
>>>>>>>>      static <Type> Image createMRImage(final RVChooser rvChooser,
>>>>>>>>              final Type baseImageSeed, final Function<Type, Image>
>>>>>>>> mapper, final Type... rvSeeds) {...}
>>>>>>>> }
>>>>>>>>
>>>>>>>> public abstract class Toolkit {
>>>>>>>>      public abstract Image createMRImage(int baseImageIndex, 
>>>>>>>> Image...
>>>>>>>> resolutionVariants); // Platform aware rv chooser is used
>>>>>>>>      public abstract RVChooser getPlatformRVChooser() ;
>>>>>>>> }
>>>>>>>> --------------------------
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>      I think it is better to provide both the 
>>>>>>>>>>> MultiResolutionImage
>>>>>>>>>>> and
>>>>>>>>>>> its implementation based on the given resolution variants 
>>>>>>>>>>> array.
>>>>>>>>>>
>>>>>>>>>> It occurs to me that even if we don't go with a 
>>>>>>>>>> lambda-factory-based
>>>>>>>>>> approach like what I'm describing, it might make sense to 
>>>>>>>>>> provide a
>>>>>>>>>> baseMR implementation that they can subclass to keep them 
>>>>>>>>>> from trying
>>>>>>>>>> to subclass off of BufferedImage instead.  I really would 
>>>>>>>>>> like to
>>>>>>>>>> avoid "custom MR images are subclasses of BufImg" if we can as I
>>>>>>>>>> think the mix of concepts is a little jarring...
>>>>>>>>>>
>>>>>>>>>>             ...jim
>>>>>>>>>>
>>>>>>>>>>>     The implementation could look like:
>>>>>>>>>>> ---------------------------------
>>>>>>>>>>> public class CustomMultiResolutionImage extends Image 
>>>>>>>>>>> implements
>>>>>>>>>>> MultiResolutionImage {
>>>>>>>>>>>
>>>>>>>>>>>      int baseImageIndex;
>>>>>>>>>>>      Image[] resolutionVariants;
>>>>>>>>>>>
>>>>>>>>>>>      public CustomMultiResolutionImage(int baseImageIndex,
>>>>>>>>>>>              Image... resolutionVariants) {
>>>>>>>>>>>          this.baseImageIndex = baseImageIndex;
>>>>>>>>>>>          this.resolutionVariants = resolutionVariants;
>>>>>>>>>>>      }
>>>>>>>>>>>
>>>>>>>>>>>      @Override
>>>>>>>>>>>      public int getWidth(ImageObserver observer) {
>>>>>>>>>>>          return getBaseImage().getWidth(null);
>>>>>>>>>>>      }
>>>>>>>>>>>
>>>>>>>>>>>      @Override
>>>>>>>>>>>      public int getHeight(ImageObserver observer) {
>>>>>>>>>>>          return getBaseImage().getHeight(null);
>>>>>>>>>>>      }
>>>>>>>>>>>
>>>>>>>>>>>      @Override
>>>>>>>>>>>      public ImageProducer getSource() {
>>>>>>>>>>>          return getBaseImage().getSource();
>>>>>>>>>>>      }
>>>>>>>>>>>
>>>>>>>>>>>      @Override
>>>>>>>>>>>      public Graphics getGraphics() {
>>>>>>>>>>>          return getBaseImage().getGraphics();
>>>>>>>>>>>      }
>>>>>>>>>>>
>>>>>>>>>>>      @Override
>>>>>>>>>>>      public Object getProperty(String name, ImageObserver 
>>>>>>>>>>> observer) {
>>>>>>>>>>>          return getBaseImage().getProperty(name, observer);
>>>>>>>>>>>      }
>>>>>>>>>>>
>>>>>>>>>>>      @Override
>>>>>>>>>>>      public Image getResolutionVariant(float logicalDPIX, float
>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>              float destinationImageWidth, float
>>>>>>>>>>> destinationImageHeight) {
>>>>>>>>>>>              // calculate resolution variant width/height
>>>>>>>>>>>          return getResolutionVariant(rvWidth, rvHeight);
>>>>>>>>>>>      }
>>>>>>>>>>>
>>>>>>>>>>>      @Override
>>>>>>>>>>>      public List<Image> getResolutionVariants() {
>>>>>>>>>>>          return Arrays.asList(resolutionVariants);
>>>>>>>>>>>      }
>>>>>>>>>>>
>>>>>>>>>>>      private Image getResolutionVariant(float rvWidth, float
>>>>>>>>>>> rvHeight) {
>>>>>>>>>>>          // return a resolution variant based on the given 
>>>>>>>>>>> width and
>>>>>>>>>>> height
>>>>>>>>>>>      }
>>>>>>>>>>>
>>>>>>>>>>>      private Image getBaseImage() {
>>>>>>>>>>>          return resolutionVariants[baseImageIndex];
>>>>>>>>>>>      }
>>>>>>>>>>> }
>>>>>>>>>>> ---------------------------------
>>>>>>>>>>>
>>>>>>>>>>>    Thanks,
>>>>>>>>>>>    Alexandr.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Then we provide one of these from TK.get/createImage() when 
>>>>>>>>>>>> the
>>>>>>>>>>>> platform detects @2x, or Win8-style variants.
>>>>>>>>>>>>
>>>>>>>>>>>> For custom images we provide TK.createMRImage(lambda getRV, 
>>>>>>>>>>>> Image
>>>>>>>>>>>> variants...) and TK.createMRImage(Image variants...);
>>>>>>>>>>>>
>>>>>>>>>>>> Since the get<List> method is just bookkeeping, I don't see 
>>>>>>>>>>>> them
>>>>>>>>>>>> needing to override it, so the getRV() method is really the 
>>>>>>>>>>>> only
>>>>>>>>>>>> thing
>>>>>>>>>>>> they might want to override, and we can tie into the new 
>>>>>>>>>>>> Lambda
>>>>>>>>>>>> capabilities by making a single-method interface for it 
>>>>>>>>>>>> that they
>>>>>>>>>>>> supply in a factory method.
>>>>>>>>>>>>
>>>>>>>>>>>> I realize that the interface you created is more fundamentally
>>>>>>>>>>>> OO, but
>>>>>>>>>>>> the Image class has always been special in this regard in 
>>>>>>>>>>>> the AWT
>>>>>>>>>>>> ecosystem (in so far as we do not support someone 
>>>>>>>>>>>> implementing their
>>>>>>>>>>>> own Image subclass even though it is technically possible).
>>>>>>>>>>>> Because of
>>>>>>>>>>>> this special nature of Image, we end up with the situation 
>>>>>>>>>>>> that if
>>>>>>>>>>>> someone were given a need to create a subclass of Image, 
>>>>>>>>>>>> then they
>>>>>>>>>>>> would turn to BufImg as their superclass even though BufImg is
>>>>>>>>>>>> essentially an implementation-specific leaf node on the 
>>>>>>>>>>>> Image class
>>>>>>>>>>>> hierarchy.  This approach with a factory method to create an
>>>>>>>>>>>> internal
>>>>>>>>>>>> subclass of the new MRI class mirrors the existing cases of 
>>>>>>>>>>>> Image
>>>>>>>>>>>> objects that come from factories as well.
>>>>>>>>>>>>
>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>
>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 3/20/14 7:52 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>    Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>>    Could you review the updated version of the fix:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.01/
>>>>>>>>>>>>>
>>>>>>>>>>>>>   - The "getResolutionVariant(int width, int height)" 
>>>>>>>>>>>>> method from
>>>>>>>>>>>>> MultiResolutionImage class is changed to
>>>>>>>>>>>>>     Image getResolutionVariant(float logicalDPIX, float
>>>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>>> float width, float height, AffineTransform transform);
>>>>>>>>>>>>>
>>>>>>>>>>>>>   - sun.awt.image.ImageResolutionHelper class is added. The
>>>>>>>>>>>>> sun.awt.image.MultiResolutionToolkitImage and
>>>>>>>>>>>>> sun.awt.image.MultiResolutionBufferedImage classes are used
>>>>>>>>>>>>> PLATFORM  ImageResolutionHelper.
>>>>>>>>>>>>>
>>>>>>>>>>>>>   The  MultiResolutionImage interface implementation could 
>>>>>>>>>>>>> look
>>>>>>>>>>>>> like:
>>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>> public class CustomMultiResolutionImage extends BufferedImage
>>>>>>>>>>>>> implements
>>>>>>>>>>>>> MultiResolutionImage {
>>>>>>>>>>>>>
>>>>>>>>>>>>>      private final Image[] resolutionVariants;
>>>>>>>>>>>>>
>>>>>>>>>>>>>      public CustomMultiResolutionImage(int baseIndex, 
>>>>>>>>>>>>> Image...
>>>>>>>>>>>>> images) {
>>>>>>>>>>>>> super(images[baseIndex].getWidth(null),
>>>>>>>>>>>>> images[baseIndex].getHeight(null),
>>>>>>>>>>>>> BufferedImage.TYPE_INT_RGB);
>>>>>>>>>>>>>          this.resolutionVariants = images;
>>>>>>>>>>>>>          Graphics g = getGraphics();
>>>>>>>>>>>>>          g.drawImage(images[baseIndex], 0, 0, null);
>>>>>>>>>>>>>          g.dispose();
>>>>>>>>>>>>>      }
>>>>>>>>>>>>>
>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>      public Image getResolutionVariant(float logicalDPIX, 
>>>>>>>>>>>>> float
>>>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>>>              float width, float height, AffineTransform
>>>>>>>>>>>>> transform) {
>>>>>>>>>>>>>          return getResolutionVariant(logicalDPIX * width,
>>>>>>>>>>>>> logicalDPIY *
>>>>>>>>>>>>> height);
>>>>>>>>>>>>>      }
>>>>>>>>>>>>>
>>>>>>>>>>>>>      @Override
>>>>>>>>>>>>>      public List<Image> getResolutionVariants() {
>>>>>>>>>>>>>          return Arrays.asList(resolutionVariants);
>>>>>>>>>>>>>      }
>>>>>>>>>>>>>
>>>>>>>>>>>>>      public Image getResolutionVariant(double width, double
>>>>>>>>>>>>> height) {
>>>>>>>>>>>>>          for (Image image : resolutionVariants) {
>>>>>>>>>>>>>              if (width <= image.getWidth(null) && height <=
>>>>>>>>>>>>> image.getHeight(null)) {
>>>>>>>>>>>>>                  return image;
>>>>>>>>>>>>>              }
>>>>>>>>>>>>>          }
>>>>>>>>>>>>>          return this;
>>>>>>>>>>>>>      }
>>>>>>>>>>>>> }
>>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>    Thanks,
>>>>>>>>>>>>>    Alexandr.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2/27/2014 4:54 PM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>> On 2/22/2014 3:54 AM, Jim Graham wrote:
>>>>>>>>>>>>>>> Hi Alexandr,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2/18/14 7:33 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>   Hi Jim,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Let's divide the discussion into two part.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   1. Where it is better to hold resolution variants?
>>>>>>>>>>>>>>>>      Putting resolution variants in Image class brings 
>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>> questions like:
>>>>>>>>>>>>>>>>    - Some type of images do not need to have resolution 
>>>>>>>>>>>>>>>> variants
>>>>>>>>>>>>>>>>    - Should resolution variants have the same type as 
>>>>>>>>>>>>>>>> the base
>>>>>>>>>>>>>>>> image?
>>>>>>>>>>>>>>>>    - getResolutionVariants() method can return copy of the
>>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>>> list
>>>>>>>>>>>>>>>> so add/removeRV methods should be also added.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    There are pros and cons for placing resolution 
>>>>>>>>>>>>>>>> variants to
>>>>>>>>>>>>>>>> Image
>>>>>>>>>>>>>>>> class or to a separate intreface.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I agree that this could be a separate interface. In my 
>>>>>>>>>>>>>>> examples
>>>>>>>>>>>>>>> below I was just sticking them inside an "Image{}" to 
>>>>>>>>>>>>>>> show where
>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>> lived in the set of involved objects, not a specific
>>>>>>>>>>>>>>> recommendation
>>>>>>>>>>>>>>> that they actually be new methods on the base class 
>>>>>>>>>>>>>>> itself. I
>>>>>>>>>>>>>>> probably should have put a comment there about that.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> With respect to add/remove - that is assuming a need for 
>>>>>>>>>>>>>>> manual
>>>>>>>>>>>>>>> construction of an image set, right? Forgive me if I'm
>>>>>>>>>>>>>>> forgetting
>>>>>>>>>>>>>>> something, but I seem to recall that manual Multi-Res 
>>>>>>>>>>>>>>> images was
>>>>>>>>>>>>>>> proposed as a way for developers to introduce @2x support
>>>>>>>>>>>>>>> themselves,
>>>>>>>>>>>>>>> but if we are internally managing @2x and -DPI variants 
>>>>>>>>>>>>>>> for them,
>>>>>>>>>>>>>>> then I'm not sure if there is actual developer need to 
>>>>>>>>>>>>>>> manually
>>>>>>>>>>>>>>> construct their own.  Am I forgetting something?
>>>>>>>>>>>>>>    The NSImage has addRepresentation/removeRepresentation
>>>>>>>>>>>>>> methods to
>>>>>>>>>>>>>> work with image representations on Mac OS X.
>>>>>>>>>>>>>>    The java.awt.Image class should provide similar
>>>>>>>>>>>>>> functionality to
>>>>>>>>>>>>>> have the possibilities as Cocoa on HiDPI displays.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   2. Using scale factor/image sizes/scaled image sizes to
>>>>>>>>>>>>>>>> retreive a
>>>>>>>>>>>>>>>> resolution variant.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    May be it is better to have a structure that provide 
>>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>> necessary
>>>>>>>>>>>>>>>> information  to query the resolution variant: scale 
>>>>>>>>>>>>>>>> factor,
>>>>>>>>>>>>>>>> draw area
>>>>>>>>>>>>>>>> width/height, transformed area width/height?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    For example:
>>>>>>>>>>>>>>>>    ---------------------
>>>>>>>>>>>>>>>>      public interface MultiResolutionImage {
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>          interface DrawAreaInfo {
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>              float getScaleFactor();
>>>>>>>>>>>>>>>>              float getAreaWidth();
>>>>>>>>>>>>>>>>              float getAreaHeight();
>>>>>>>>>>>>>>>>              float getTransformedAreaWidth();
>>>>>>>>>>>>>>>>              float getTransformedAreaHeight();
>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>          public Image getResolutionVariant(DrawAreaInfo
>>>>>>>>>>>>>>>> drawAreaInfo) ;
>>>>>>>>>>>>>>>>          public List<Image> getResolutionVariants();
>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>    ---------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The problem with a constructor is that this is something 
>>>>>>>>>>>>>>> that is
>>>>>>>>>>>>>>> (potentially) done on every drawImage() call, which 
>>>>>>>>>>>>>>> means we are
>>>>>>>>>>>>>>> inviting GC into the equation.  If we can come up with a 
>>>>>>>>>>>>>>> simple
>>>>>>>>>>>>>>> "just
>>>>>>>>>>>>>>> a couple/3/4 numbers" way to embed that data into a 
>>>>>>>>>>>>>>> method call
>>>>>>>>>>>>>>> argument list then we can make this lighter weight.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What about simply having floating point (double) 
>>>>>>>>>>>>>>> dimensions on
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> rendered size
>>>>>>>>>>>>>>       There should be a way to choose a resolution variant
>>>>>>>>>>>>>> based on
>>>>>>>>>>>>>> requested drawing size or transformed drawing size.
>>>>>>>>>>>>>>       At least a current transformation should be 
>>>>>>>>>>>>>> included too.
>>>>>>>>>>>>>>> plus a single floating point "logical DPI" for the screen?
>>>>>>>>>>>>>>      There is the ID2D1Factory::GetDesktopDpi method 
>>>>>>>>>>>>>> which returns
>>>>>>>>>>>>>> dpiX and dpiY.
>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316 
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     That means that logicalDPIX/Y can have different values.
>>>>>>>>>>>>>>      At least it is described in the
>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/ff684173 
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>      "To get the DPI setting, call the 
>>>>>>>>>>>>>> ID2D1Factory::GetDesktopDpi
>>>>>>>>>>>>>> method. The DPI is returned as two floating-point values, 
>>>>>>>>>>>>>> one for
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> x-axis and one for the y-axis. In theory, these values 
>>>>>>>>>>>>>> can differ.
>>>>>>>>>>>>>> Calculate a separate scaling factor for each axis."
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   The getResolutionVariant method could look like:
>>>>>>>>>>>>>> --------------------------------------
>>>>>>>>>>>>>>     public Image getResolutionVariant(float logicalDPIX, 
>>>>>>>>>>>>>> float
>>>>>>>>>>>>>> logicalDPIY,
>>>>>>>>>>>>>>             float widthX, float widthY, AffineTransform
>>>>>>>>>>>>>> transform);
>>>>>>>>>>>>>> --------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  If the image is known (either passed as an argument or the
>>>>>>>>>>>>>>> method is
>>>>>>>>>>>>>>> called on the image), then it can provide the original WH.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    The MultiResolutionImage default implementation 
>>>>>>>>>>>>>>>> could allow
>>>>>>>>>>>>>>>> to use
>>>>>>>>>>>>>>>> different strategies like scale factor/transfom/OS based
>>>>>>>>>>>>>>>>    to query a resolution variant. The OS based strategy 
>>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>> used by
>>>>>>>>>>>>>>>> default.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For Mac policy, all we need is the transformed 
>>>>>>>>>>>>>>> dimensions, which
>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>> be passed in as FP for generality. For Windows policy, 
>>>>>>>>>>>>>>> all we
>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>> is logical DPI for the screen.   What other information 
>>>>>>>>>>>>>>> would we
>>>>>>>>>>>>>>> need, or would an algorithm like to use, that can't be 
>>>>>>>>>>>>>>> computed
>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>> those 2 pieces?
>>>>>>>>>>>>>>      The aim is to provide a base class that can be used to
>>>>>>>>>>>>>> create a
>>>>>>>>>>>>>> MultiResolutionImage like:
>>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/diff/ae53ebce5fa3/src/share/classes/sun/awt/image/MultiResolutionBufferedImage.java 
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>      A developer should be able to implement a custom 
>>>>>>>>>>>>>> algorithm to
>>>>>>>>>>>>>> query a resolution variant.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     It can be done by overriding the getResolutionVariant 
>>>>>>>>>>>>>> image:
>>>>>>>>>>>>>>    -----------------------
>>>>>>>>>>>>>>         Image mrImage = new MultiResolutionBufferedImage(){
>>>>>>>>>>>>>>             @Override
>>>>>>>>>>>>>>             public Image getResolutionVariant(...) {
>>>>>>>>>>>>>>                 // Custom logic here
>>>>>>>>>>>>>>             }
>>>>>>>>>>>>>>         };
>>>>>>>>>>>>>>    -----------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    Or it can be done by using resolution variant choosers 
>>>>>>>>>>>>>> so a
>>>>>>>>>>>>>> developer can implement custom resolution variant query:
>>>>>>>>>>>>>>    -----------------------
>>>>>>>>>>>>>> public class MultiResolutionBufferedImage implements
>>>>>>>>>>>>>> MultiResolutionImage{
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     interface ResolutionVariantChooser{
>>>>>>>>>>>>>>         Image getResolutionVariant(dpi, size,..., 
>>>>>>>>>>>>>> List<Image>
>>>>>>>>>>>>>> resolutionVariants);
>>>>>>>>>>>>>>     }
>>>>>>>>>>>>>>     ResolutionVariantChooser TRANSFORM_BASED = null;
>>>>>>>>>>>>>>     ResolutionVariantChooser DPI_BASED = null;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     ResolutionVariantChooser rvChooser;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     @Override
>>>>>>>>>>>>>>     public Image getResolutionVariant(dpi, size,...,) {
>>>>>>>>>>>>>>         return rvChooser.getResolutionVariant(dpi, size,...,
>>>>>>>>>>>>>> getResolutionVariants());
>>>>>>>>>>>>>>     }
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>    -----------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Thanks,
>>>>>>>>>>>>>>   Alexandr.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2/13/2014 4:42 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>> On 2/12/14 5:59 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>> On 2/8/2014 4:19 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>>>> The primary thing that I was concerned about was the
>>>>>>>>>>>>>>>>>>> presence of
>>>>>>>>>>>>>>>>>>> integers in the API when Windows uses non-integer 
>>>>>>>>>>>>>>>>>>> multiples
>>>>>>>>>>>>>>>>>>       It would make sense to pass real numbers to the
>>>>>>>>>>>>>>>>>> getResolutionVariant() method if the difference between
>>>>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>>>>> variants sizes is 1.
>>>>>>>>>>>>>>>>>>       It seems that it is not a common case.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I was thinking of other API that is related to this, 
>>>>>>>>>>>>>>>>> such as
>>>>>>>>>>>>>>>>> the API
>>>>>>>>>>>>>>>>> that queries the scaling factor from a SurfaceManager. I
>>>>>>>>>>>>>>>>> seem to
>>>>>>>>>>>>>>>>> remember some integer return values in that, but 
>>>>>>>>>>>>>>>>> Windows might
>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>> the answer 1.4 or 1.8, depending on the screen scaling 
>>>>>>>>>>>>>>>>> factor
>>>>>>>>>>>>>>>>> that was
>>>>>>>>>>>>>>>>> determined from the UI.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In terms of the getResolutionVariant() method here, those
>>>>>>>>>>>>>>>>> non-integer
>>>>>>>>>>>>>>>>> screen scaling factors don't directly impact this API. 
>>>>>>>>>>>>>>>>> But, we
>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>> some issues with the use of integers there from other 
>>>>>>>>>>>>>>>>> sources:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - That API assumes that the caller will determine the 
>>>>>>>>>>>>>>>>> pixel
>>>>>>>>>>>>>>>>> size
>>>>>>>>>>>>>>>>> needed, but the actual media choice is determined with
>>>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>>>> techniques on Mac and Windows so this means that the 
>>>>>>>>>>>>>>>>> caller
>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>> to worry about platform conventions. Is that the right
>>>>>>>>>>>>>>>>> tradeoff?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - The technique recommended for Mac involves computing 
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> precise
>>>>>>>>>>>>>>>>> size desired using the current transform, which may be a
>>>>>>>>>>>>>>>>> floating
>>>>>>>>>>>>>>>>> point value, so the integer values used in this API 
>>>>>>>>>>>>>>>>> are already
>>>>>>>>>>>>>>>>> approximations and there is no documentation on how to
>>>>>>>>>>>>>>>>> generate the
>>>>>>>>>>>>>>>>> proper integer.  In particular, the current code in SG2D
>>>>>>>>>>>>>>>>> naively
>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>> a cast to integer to determine the values to supply which
>>>>>>>>>>>>>>>>> means a
>>>>>>>>>>>>>>>>> transformed size of W+0.5 will be truncated to W and 
>>>>>>>>>>>>>>>>> the lower
>>>>>>>>>>>>>>>>> resolution image will be used. Does that conform to Mac
>>>>>>>>>>>>>>>>> guidelines? Do
>>>>>>>>>>>>>>>>> they require the truncated size to reach W+1 before 
>>>>>>>>>>>>>>>>> the next
>>>>>>>>>>>>>>>>> size is
>>>>>>>>>>>>>>>>> used?  Passing in float or double values would 
>>>>>>>>>>>>>>>>> sidestep all of
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>> since then the comparisons would be done with full 
>>>>>>>>>>>>>>>>> precision,
>>>>>>>>>>>>>>>>> but as
>>>>>>>>>>>>>>>>> long as we can determine a "best practices compatible 
>>>>>>>>>>>>>>>>> with all
>>>>>>>>>>>>>>>>> platforms" rule on how to round to integers, then 
>>>>>>>>>>>>>>>>> integers
>>>>>>>>>>>>>>>>> are OK
>>>>>>>>>>>>>>>>> there.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - The Windows document you cite below suggests that the
>>>>>>>>>>>>>>>>> determination
>>>>>>>>>>>>>>>>> should be made by looking at the Screen DPI and 
>>>>>>>>>>>>>>>>> choosing the
>>>>>>>>>>>>>>>>> next
>>>>>>>>>>>>>>>>> higher media variant based on that screen DPI. They do 
>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> specify
>>>>>>>>>>>>>>>>> choosing media based on the current transform as is 
>>>>>>>>>>>>>>>>> done for
>>>>>>>>>>>>>>>>> Mac.  If
>>>>>>>>>>>>>>>>> we stick with supplying values that are used to 
>>>>>>>>>>>>>>>>> determine which
>>>>>>>>>>>>>>>>> media
>>>>>>>>>>>>>>>>> to use, then on Windows we should not take the 
>>>>>>>>>>>>>>>>> transform into
>>>>>>>>>>>>>>>>> account,
>>>>>>>>>>>>>>>>> but instead query the SurfaceManager for the scale 
>>>>>>>>>>>>>>>>> factor and
>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>> transform by those values (even if the current 
>>>>>>>>>>>>>>>>> transform was
>>>>>>>>>>>>>>>>> manually
>>>>>>>>>>>>>>>>> overridden to identity).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> There are pros and cons to both approaches.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Mac ensures that you are always using the best media 
>>>>>>>>>>>>>>>>> for any
>>>>>>>>>>>>>>>>> given
>>>>>>>>>>>>>>>>> render operation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But, Windows ensure more consistency in the face of other
>>>>>>>>>>>>>>>>> scaling.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The thing to consider is that if you have a 500x500 image
>>>>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>>>>> 1000x1000 variant and you rendering it at 500x500 and 
>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>> 501x501,
>>>>>>>>>>>>>>>>> that first jump will be fairly jarring as the scaled 
>>>>>>>>>>>>>>>>> version
>>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>>> 1000x1000 will not look precisely like the original 
>>>>>>>>>>>>>>>>> 500x500
>>>>>>>>>>>>>>>>> did.
>>>>>>>>>>>>>>>>> With
>>>>>>>>>>>>>>>>> @2x images only, this effect is minimized so the 
>>>>>>>>>>>>>>>>> advantage of
>>>>>>>>>>>>>>>>> always
>>>>>>>>>>>>>>>>> using "the best media for a given render operation" may
>>>>>>>>>>>>>>>>> outweigh the
>>>>>>>>>>>>>>>>> inconsistency issue.  But, on Windows where the media are
>>>>>>>>>>>>>>>>> 1.4x or
>>>>>>>>>>>>>>>>> 1.8x
>>>>>>>>>>>>>>>>> in size, a downscaled image will start to show more
>>>>>>>>>>>>>>>>> interpolation
>>>>>>>>>>>>>>>>> noise and so the balance of the two choices may shift 
>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>> towards not
>>>>>>>>>>>>>>>>> wanting a jarring shift.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We might want one or more of the following:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - Developer chooses policy (TX_AWARE, DPI_AWARE,
>>>>>>>>>>>>>>>>> ALWAYS_LARGEST,
>>>>>>>>>>>>>>>>> NONE,
>>>>>>>>>>>>>>>>> PLATFORM) where the last policy would use TX_AWARE on 
>>>>>>>>>>>>>>>>> Mac and
>>>>>>>>>>>>>>>>> DPI_AWARE on Windows
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - We create our own policy and always use it 
>>>>>>>>>>>>>>>>> (TX_AWARE? or
>>>>>>>>>>>>>>>>> DPI_AWARE?)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - We create our own policy that dynamically chooses 
>>>>>>>>>>>>>>>>> one of the
>>>>>>>>>>>>>>>>> above
>>>>>>>>>>>>>>>>> strategies depending on platform or available media or 
>>>>>>>>>>>>>>>>> ???
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - We could create an optional interface for them to 
>>>>>>>>>>>>>>>>> install
>>>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>>>> own
>>>>>>>>>>>>>>>>> algorithm as well.  I think it would work best as a 
>>>>>>>>>>>>>>>>> delegate
>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>> that one installs into Image so that it can be used 
>>>>>>>>>>>>>>>>> with any
>>>>>>>>>>>>>>>>> image
>>>>>>>>>>>>>>>>> without having to subclass (it wouldn't really have 
>>>>>>>>>>>>>>>>> much to do
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> BufferedImages or VolatileImages, though):
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> class Image {
>>>>>>>>>>>>>>>>>     void setResolutionHelper(ImageResolutionHelper foo);
>>>>>>>>>>>>>>>>>     List<Image> getResolutionVariants();
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> or:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> class Graphics {
>>>>>>>>>>>>>>>>>      void setResolutionHelper(ImageResolutionHelper foo);
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> or - anywhere else it could be installed more 
>>>>>>>>>>>>>>>>> centrally (per
>>>>>>>>>>>>>>>>> App
>>>>>>>>>>>>>>>>> context)?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> and the interface would be something like one of these
>>>>>>>>>>>>>>>>> variants:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> interface ImageResolutionHelper {
>>>>>>>>>>>>>>>>>     // This version would prevent substituting a 
>>>>>>>>>>>>>>>>> random image:
>>>>>>>>>>>>>>>>>     // They have to return an index into the 
>>>>>>>>>>>>>>>>> List<Image> for
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>> image...
>>>>>>>>>>>>>>>>>     public int chooseVariant(Image img, double dpi, 
>>>>>>>>>>>>>>>>> number w,
>>>>>>>>>>>>>>>>> number h);
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> or:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     // This version would allow substituting an arbitrary
>>>>>>>>>>>>>>>>> image:
>>>>>>>>>>>>>>>>>     public Image getVariant(Image img, double dpi, 
>>>>>>>>>>>>>>>>> number w,
>>>>>>>>>>>>>>>>> number
>>>>>>>>>>>>>>>>> h);
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Since they would be in full control of the policy, 
>>>>>>>>>>>>>>>>> though, we
>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>> unfortunately always have to call this, there would be 
>>>>>>>>>>>>>>>>> no more
>>>>>>>>>>>>>>>>> testing
>>>>>>>>>>>>>>>>> in SG2D to see "if" we need to deal with DPI, though 
>>>>>>>>>>>>>>>>> perhaps we
>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>> document some internal conditions in which we do not 
>>>>>>>>>>>>>>>>> call it
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> common cases (but that would have to be well agreed 
>>>>>>>>>>>>>>>>> not to
>>>>>>>>>>>>>>>>> get in
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> way of reasonable uses of the API and well documented)?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Note that we would have to do a security audit to make 
>>>>>>>>>>>>>>>>> sure
>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>> random image substitution couldn't allow any sort of 
>>>>>>>>>>>>>>>>> "screen
>>>>>>>>>>>>>>>>> phishing"
>>>>>>>>>>>>>>>>> exploit.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> and also what policy they use for choosing scaled 
>>>>>>>>>>>>>>>>>>> images.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I don't see a mention of taking the current 
>>>>>>>>>>>>>>>>>>> transform into
>>>>>>>>>>>>>>>>>>> account,
>>>>>>>>>>>>>>>>>>> just physical issues like screen DPI and form 
>>>>>>>>>>>>>>>>>>> factor. They
>>>>>>>>>>>>>>>>>>> talk
>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>> resolution plateaus and in their recommendations 
>>>>>>>>>>>>>>>>>>> section they
>>>>>>>>>>>>>>>>>>> tell the
>>>>>>>>>>>>>>>>>>> developer to use a particular property that tells 
>>>>>>>>>>>>>>>>>>> them the
>>>>>>>>>>>>>>>>>>> screen
>>>>>>>>>>>>>>>>>>> resolution to figure out which image to load if they 
>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>> loading
>>>>>>>>>>>>>>>>>>> manually.  There is no discussion about dynamically 
>>>>>>>>>>>>>>>>>>> loading
>>>>>>>>>>>>>>>>>>> multiple
>>>>>>>>>>>>>>>>>>> versions of the image based on a dynamic 
>>>>>>>>>>>>>>>>>>> program-applied
>>>>>>>>>>>>>>>>>>> transform
>>>>>>>>>>>>>>>>>>> factor as is done on MacOS.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Also, they tell developers to draw images to a 
>>>>>>>>>>>>>>>>>>> specific size
>>>>>>>>>>>>>>>>>>> rather
>>>>>>>>>>>>>>>>>>> than using auto-sizing.  That begs the question as 
>>>>>>>>>>>>>>>>>>> to how
>>>>>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>>>>> interpret a call to draw an image just using a 
>>>>>>>>>>>>>>>>>>> location in
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> presence of various DPI factors.
>>>>>>>>>>>>>>>>>>       There is an interesting doc that describes how 
>>>>>>>>>>>>>>>>>> to write
>>>>>>>>>>>>>>>>>> DPI-aware
>>>>>>>>>>>>>>>>>> Win32 applications:
>>>>>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/dd464646%28v=vs.85%29.aspx 
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>       It is suggested to handle WM_DPICHANGED 
>>>>>>>>>>>>>>>>>> message, load
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> graphic
>>>>>>>>>>>>>>>>>> that has slightly greater resolution to the current 
>>>>>>>>>>>>>>>>>> DPI and
>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>> StretchBlt
>>>>>>>>>>>>>>>>>>       to scale down the image.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>      Thanks,
>>>>>>>>>>>>>>>>>>      Alexandr.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 2/7/14 3:00 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>>> On 1/22/2014 6:40 AM, Jim Graham wrote:
>>>>>>>>>>>>>>>>>>>>> Hi Alexander,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Before we get too far down the road on this API, I 
>>>>>>>>>>>>>>>>>>>>> think we
>>>>>>>>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>>>>>>>> the way in which MacOS processes multi-resolution 
>>>>>>>>>>>>>>>>>>>>> images
>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>> HiDPI
>>>>>>>>>>>>>>>>>>>>> screens, but have we investigated the processes that
>>>>>>>>>>>>>>>>>>>>> Windows
>>>>>>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>>>>>>> under Windows 8?  My impression is that Windows 8 has
>>>>>>>>>>>>>>>>>>>>> included a
>>>>>>>>>>>>>>>>>>>>> number of new techniques for dealing with the high
>>>>>>>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>>>>>>>> displays
>>>>>>>>>>>>>>>>>>>>> that it will run on in the Windows tablet and mobile
>>>>>>>>>>>>>>>>>>>>> industries
>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> that these will also come into play as 4K displays 
>>>>>>>>>>>>>>>>>>>>> (already
>>>>>>>>>>>>>>>>>>>>> available)
>>>>>>>>>>>>>>>>>>>>> become more common on the desktop.  We should make 
>>>>>>>>>>>>>>>>>>>>> sure
>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> what we
>>>>>>>>>>>>>>>>>>>>> come up with here can provide native compatibility 
>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>> either
>>>>>>>>>>>>>>>>>>>>> platform's policies and standard practices.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If you've investigated the MS policies I'd like to 
>>>>>>>>>>>>>>>>>>>>> see a
>>>>>>>>>>>>>>>>>>>>> summary so
>>>>>>>>>>>>>>>>>>>>> that we can consider them as we review this API...
>>>>>>>>>>>>>>>>>>>>     There is the Windows Guidelines for scaling to 
>>>>>>>>>>>>>>>>>>>> pixel
>>>>>>>>>>>>>>>>>>>> density:
>>>>>>>>>>>>>>>>>>>> http://msdn.microsoft.com/en-us/library/windows/apps/hh465362.aspx 
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>     which says that Windows has automatic resource 
>>>>>>>>>>>>>>>>>>>> loading
>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>> supports
>>>>>>>>>>>>>>>>>>>> three version of images scaling (100%, 140%, and 180%)
>>>>>>>>>>>>>>>>>>>> --------------------------------
>>>>>>>>>>>>>>>>>>>> Without scaling, as the pixel density of a display 
>>>>>>>>>>>>>>>>>>>> device
>>>>>>>>>>>>>>>>>>>> increases, the
>>>>>>>>>>>>>>>>>>>> physical sizes of objects on screen get smaller.
>>>>>>>>>>>>>>>>>>>> When UI would otherwise be too small to touch and 
>>>>>>>>>>>>>>>>>>>> when text
>>>>>>>>>>>>>>>>>>>> gets
>>>>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>>>> small to read,
>>>>>>>>>>>>>>>>>>>> Windows scales the system and app UI to one of the 
>>>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>>> scaling
>>>>>>>>>>>>>>>>>>>> plateaus:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>      1.0 (100%, no scaling is applied)
>>>>>>>>>>>>>>>>>>>>      1.4 (140% scaling)
>>>>>>>>>>>>>>>>>>>>      1.8 (180% scaling)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Windows determines which scaling plateau to use 
>>>>>>>>>>>>>>>>>>>> based on the
>>>>>>>>>>>>>>>>>>>> physical
>>>>>>>>>>>>>>>>>>>> screen size, the screen resolution, the DPI of the
>>>>>>>>>>>>>>>>>>>> screen, and
>>>>>>>>>>>>>>>>>>>> form
>>>>>>>>>>>>>>>>>>>> factor.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Use resource loading for bitmap images in the app 
>>>>>>>>>>>>>>>>>>>> package
>>>>>>>>>>>>>>>>>>>> For
>>>>>>>>>>>>>>>>>>>> bitmap
>>>>>>>>>>>>>>>>>>>> images stored
>>>>>>>>>>>>>>>>>>>> in the app package, provide a separate image for each
>>>>>>>>>>>>>>>>>>>> scaling
>>>>>>>>>>>>>>>>>>>> factor(100%, 140%, and 180%),
>>>>>>>>>>>>>>>>>>>> and name your image files using the "scale" naming
>>>>>>>>>>>>>>>>>>>> convention
>>>>>>>>>>>>>>>>>>>> described
>>>>>>>>>>>>>>>>>>>> below.
>>>>>>>>>>>>>>>>>>>> Windows loads the right image for the current scale
>>>>>>>>>>>>>>>>>>>> automatically.
>>>>>>>>>>>>>>>>>>>> --------------------------------
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>   The image name convention for the various scales is:
>>>>>>>>>>>>>>>>>>>> images/logo.scale-100.png
>>>>>>>>>>>>>>>>>>>> images/logo.scale-140.png
>>>>>>>>>>>>>>>>>>>> images/logo.scale-180.png
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    The 'ms-appx:///images/logo.png' uri is used to 
>>>>>>>>>>>>>>>>>>>> load the
>>>>>>>>>>>>>>>>>>>> image
>>>>>>>>>>>>>>>>>>>> in an
>>>>>>>>>>>>>>>>>>>> application.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    If we want to support this in the same way as it 
>>>>>>>>>>>>>>>>>>>> is done
>>>>>>>>>>>>>>>>>>>> for Mac
>>>>>>>>>>>>>>>>>>>> OS X
>>>>>>>>>>>>>>>>>>>>    the WToolkit should return MultiResolution image in
>>>>>>>>>>>>>>>>>>>> case if
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> loaded image has .scale-* qualifiers.
>>>>>>>>>>>>>>>>>>>>    The Graphics class can request an image with 
>>>>>>>>>>>>>>>>>>>> necessary
>>>>>>>>>>>>>>>>>>>> resolution
>>>>>>>>>>>>>>>>>>>> from the MultiResolution image.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    It seems that nothing should be changed in the
>>>>>>>>>>>>>>>>>>>> MultiResolution
>>>>>>>>>>>>>>>>>>>> interface in this case.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>     Thanks,
>>>>>>>>>>>>>>>>>>>>     Alexandr.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 1/14/14 2:54 AM, Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Could you review the fix:
>>>>>>>>>>>>>>>>>>>>>>    bug: 
>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8029339
>>>>>>>>>>>>>>>>>>>>>>    webrev:
>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.00 
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>    This is a proposal to introduce an API that 
>>>>>>>>>>>>>>>>>>>>>> allows to
>>>>>>>>>>>>>>>>>>>>>> create a
>>>>>>>>>>>>>>>>>>>>>> custom
>>>>>>>>>>>>>>>>>>>>>> multi resolution image.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I. It seems reasonable that the API should 
>>>>>>>>>>>>>>>>>>>>>> provide two
>>>>>>>>>>>>>>>>>>>>>> basic
>>>>>>>>>>>>>>>>>>>>>> operations:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>   1. Get the resolution variant based on the 
>>>>>>>>>>>>>>>>>>>>>> requested
>>>>>>>>>>>>>>>>>>>>>> image
>>>>>>>>>>>>>>>>>>>>>> width and
>>>>>>>>>>>>>>>>>>>>>> height:
>>>>>>>>>>>>>>>>>>>>>>      - Image getResolutionVariant(int width, int 
>>>>>>>>>>>>>>>>>>>>>> height)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>     Usually the system provides the scale factor 
>>>>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>>>>> represents
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> number of pixels corresponding to each linear 
>>>>>>>>>>>>>>>>>>>>>> unit on the
>>>>>>>>>>>>>>>>>>>>>> display.
>>>>>>>>>>>>>>>>>>>>>>     However, it has sense to combine the scale 
>>>>>>>>>>>>>>>>>>>>>> factor and
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>>>>>>>> transformations to get the actual image size to be
>>>>>>>>>>>>>>>>>>>>>> displayed.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>   2. Get all provided resolution variants:
>>>>>>>>>>>>>>>>>>>>>>     - List<Image> getResolutionVariants()
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>    There are several uses cases:
>>>>>>>>>>>>>>>>>>>>>>     - Create a new multi-resolution image based 
>>>>>>>>>>>>>>>>>>>>>> on the
>>>>>>>>>>>>>>>>>>>>>> given
>>>>>>>>>>>>>>>>>>>>>> multi-resolution image.
>>>>>>>>>>>>>>>>>>>>>>     - Pass to the native system the multi-resolution
>>>>>>>>>>>>>>>>>>>>>> image. For
>>>>>>>>>>>>>>>>>>>>>> example,
>>>>>>>>>>>>>>>>>>>>>> a use can set to the system the custom 
>>>>>>>>>>>>>>>>>>>>>> multi-resolution
>>>>>>>>>>>>>>>>>>>>>> cursor.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> II. There are some possible ways where the new 
>>>>>>>>>>>>>>>>>>>>>> API can be
>>>>>>>>>>>>>>>>>>>>>> added
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>   1. java.awt.Image.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>    The 2 new methods can be added to the Image 
>>>>>>>>>>>>>>>>>>>>>> class. A
>>>>>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>>>>> override
>>>>>>>>>>>>>>>>>>>>>>    the getResolutionVariant() and 
>>>>>>>>>>>>>>>>>>>>>> getResolutionVariants()
>>>>>>>>>>>>>>>>>>>>>> methods to
>>>>>>>>>>>>>>>>>>>>>> provide the resolution variants
>>>>>>>>>>>>>>>>>>>>>>    or there can be default implementations of these
>>>>>>>>>>>>>>>>>>>>>> methods
>>>>>>>>>>>>>>>>>>>>>> if a
>>>>>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>>>>> puts resolution variants
>>>>>>>>>>>>>>>>>>>>>>    to the list in the sorted order.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>    To check that the image has resolution 
>>>>>>>>>>>>>>>>>>>>>> variants the
>>>>>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>>>>> statement can be used:
>>>>>>>>>>>>>>>>>>>>>> image.getResolutionVariants().size()
>>>>>>>>>>>>>>>>>>>>>> != 1
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>    The disadvantage is that there is an overhead 
>>>>>>>>>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>>>>>>>>>> Image
>>>>>>>>>>>>>>>>>>>>>> class
>>>>>>>>>>>>>>>>>>>>>> should contain the List object and not all
>>>>>>>>>>>>>>>>>>>>>>    images can have resolution variants.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>   2. Introduce new MultiResolutionImage interface.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>    A user should extend Image class and implement 
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> MultiResolutionImage interface.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>    For example:
>>>>>>>>>>>>>>>>>>>>>>    ---------------------
>>>>>>>>>>>>>>>>>>>>>>      public class CustomMultiResolutionImage extends
>>>>>>>>>>>>>>>>>>>>>> BufferedImage
>>>>>>>>>>>>>>>>>>>>>>              implements MultiResolutionImage {
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>          Image highResolutionImage;
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>          public 
>>>>>>>>>>>>>>>>>>>>>> CustomMultiResolutionImage(BufferedImage
>>>>>>>>>>>>>>>>>>>>>> baseImage,
>>>>>>>>>>>>>>>>>>>>>> BufferedImage highResolutionImage) {
>>>>>>>>>>>>>>>>>>>>>> super(baseImage.getWidth(),
>>>>>>>>>>>>>>>>>>>>>> baseImage.getHeight(),
>>>>>>>>>>>>>>>>>>>>>> baseImage.getType());
>>>>>>>>>>>>>>>>>>>>>> this.highResolutionImage = highResolutionImage;
>>>>>>>>>>>>>>>>>>>>>>              Graphics g = getGraphics();
>>>>>>>>>>>>>>>>>>>>>> g.drawImage(baseImage, 0, 0, null);
>>>>>>>>>>>>>>>>>>>>>> g.dispose();
>>>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>          @Override
>>>>>>>>>>>>>>>>>>>>>>          public Image getResolutionVariant(int 
>>>>>>>>>>>>>>>>>>>>>> width, int
>>>>>>>>>>>>>>>>>>>>>> height) {
>>>>>>>>>>>>>>>>>>>>>>              return ((width <= getWidth() && 
>>>>>>>>>>>>>>>>>>>>>> height <=
>>>>>>>>>>>>>>>>>>>>>> getHeight()))
>>>>>>>>>>>>>>>>>>>>>>                      ? this : highResolutionImage;
>>>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>          @Override
>>>>>>>>>>>>>>>>>>>>>>          public List<Image> 
>>>>>>>>>>>>>>>>>>>>>> getResolutionVariants() {
>>>>>>>>>>>>>>>>>>>>>>              return Arrays.asList(this,
>>>>>>>>>>>>>>>>>>>>>> highResolutionImage);
>>>>>>>>>>>>>>>>>>>>>>          }
>>>>>>>>>>>>>>>>>>>>>>      }
>>>>>>>>>>>>>>>>>>>>>>    ---------------------
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>   The current fix adds the MultiResolutionImage 
>>>>>>>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>> public
>>>>>>>>>>>>>>>>>>>>>> resolution variant rendering hints.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>>
>



From joe.darcy at oracle.com  Mon May 19 16:35:31 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 19 May 2014 09:35:31 -0700
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8042864 : Fix raw and
 unchecked warnings in javax.print
In-Reply-To: <53756498.2040805@oracle.com>
References: <53751063.6070001@oracle.com> <537543D0.9010900@oracle.com>
	<53756498.2040805@oracle.com>
Message-ID: <537A32D3.9070302@oracle.com>

*ping*

Any other comments?

Thanks,

-Joe

On 05/15/2014 06:06 PM, Joe Darcy wrote:
> Hi Henry,
>
> On 05/15/2014 03:46 PM, Henry Jen wrote:
>> On 05/15/2014 12:07 PM, Joe Darcy wrote:
>>> Hello,
>>>
>>> Please review these change to fix
>>>
>>>      JDK-8042864 : Fix raw and unchecked warnings in javax.print
>>>      http://cr.openjdk.java.net/~darcy/8042864.0/
>>>
>>> Patch below.
>>
>> Looks good to me, just nit-picking.
>>
>>>
>>> --- old/src/share/classes/javax/print/PrintServiceLookup.java 
>>> 2014-05-15
>>> 12:04:20.000000000 -0700
>>> +++ new/src/share/classes/javax/print/PrintServiceLookup.java 
>>> 2014-05-15
>>> 12:04:20.000000000 -0700
>>> @@ -208,7 +207,7 @@
>>>        */
>>>       public static boolean registerServiceProvider(PrintServiceLookup
>>> sp) {
>>>           synchronized (PrintServiceLookup.class) {
>>> -            Iterator psIterator = getAllLookupServices().iterator();
>>> +            Iterator<?> psIterator = 
>>> getAllLookupServices().iterator();
>>>               while (psIterator.hasNext()) {
>>>                   try {
>>>                       Object lus = psIterator.next();
>>
>> We know this is Iterator<PrinterServiceLookup>, but this works.
>
> I can put the more precise type information in.
>
>>
>>> ---
>>> old/src/share/classes/javax/print/attribute/AttributeSetUtilities.java
>>> 2014-05-15 12:04:22.000000000 -0700
>>> +++
>>> new/src/share/classes/javax/print/attribute/AttributeSetUtilities.java
>>> 2014-05-15 12:04:22.000000000 -0700
>>> @@ -523,7 +523,7 @@
>>>       public static Class<?>
>>>           verifyAttributeCategory(Object object, Class<?> 
>>> interfaceName) {
>>>
>>> -        Class result = (Class) object;
>>> +        Class<?> result = (Class) object;
>>>           if (interfaceName.isAssignableFrom (result)) {
>>>               return result;
>>>           }
>>
>> Should the cast be (Class<?>) instead of (Class)?
>
> I think either is okay, but I'm fine to change this to Class<?>.
>
>>
>>> ---
>>> old/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java 
>>>
>>> 2014-05-15 12:04:24.000000000 -0700
>>> +++
>>> new/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java 
>>>
>>> 2014-05-15 12:04:23.000000000 -0700
>>> @@ -110,7 +110,7 @@
>>>        * @return  Printing attribute class (category), an instance 
>>> of class
>>>        *          {@link java.lang.Class java.lang.Class}.
>>>        */
>>> -    public final Class getCategory() {
>>> +    public final Class<DialogTypeSelection> getCategory() {
>>>           return DialogTypeSelection.class;
>>>       }
>>>
>>
>> Would this be too specific for this public API? <? extends Attribute> 
>> is defined in interface Attribute.
>
> Well, the javadoc does say that DialogTypeSelection.class is returned. 
> The DialogTypeSelection class does implement the Attribute interface 
> so all the typing works out fine as-is.
>
>>
>>
>>> ---
>>> old/src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java 
>>>
>>> 2014-05-15 12:04:25.000000000 -0700
>>> +++
>>> new/src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java 
>>>
>>> 2014-05-15 12:04:24.000000000 -0700
>>> @@ -242,16 +242,18 @@
>>>           extends AbstractSet<PrinterStateReason>
>>>       {
>>>           private Severity mySeverity;
>>> -        private Set myEntrySet;
>>> +        //
>>> +        private Set<Map.Entry<PrinterStateReason, Severity>> 
>>> myEntrySet;
>>>
>>> -        public PrinterStateReasonSet(Severity severity, Set 
>>> entrySet) {
>>> +        public PrinterStateReasonSet(Severity severity,
>>> + Set<Map.Entry<PrinterStateReason, Severity>> entrySet) {
>>>               mySeverity = severity;
>>>               myEntrySet = entrySet;
>>>           }
>>>
>>>           public int size() {
>>>               int result = 0;
>>> -            Iterator iter = iterator();
>>> +            Iterator<?> iter = iterator();
>>
>> We know it is Iterator<PrinterStateReason>.
>>
>>
>
> That was less clear when I addressed the warning on that line, but the 
> exact time works better.
>
> Updated webrev uploaded to:
>
>     http://cr.openjdk.java.net/~darcy/8042864.1
>
> Thanks for the review,
>
> -Joe
>



From philip.race at oracle.com  Mon May 19 17:18:45 2014
From: philip.race at oracle.com (Phil Race)
Date: Mon, 19 May 2014 10:18:45 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> JDK-8041679 Replace uses of
 StringBuffer with StringBuilder within the JDK
In-Reply-To: <5379B7DC.2020206@oracle.com>
References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com>	<5371FDBD.9020002@oracle.com>	<0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com>	<53728B83.1060307@oracle.com>	<8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com>	<537331E5.4070108@oracle.com>	<007101BF-30BC-4761-A13A-0AE1EAD36DF5@oracle.com>	<53766815.40600@oracle.com>	<6F7CE86A-E4B7-4F6B-B698-6426890D1409@oracle.com>
	<5379B7DC.2020206@oracle.com>
Message-ID: <537A3CF5.5010401@oracle.com>

On 5/19/2014 12:50 AM, Alan Bateman wrote:
> On 19/05/2014 07:53, Paul Sandoz wrote:
>> If i don't have permission to push to the client repo (which might be 
>> likely) i will need to hand over the patch to yourself or Sergey to 
>> commit. And i presume this will have to be a separate issue.
> If you do decide to split this then it will require creating a second 
> issue JIRA to avoid running foul of jcheck when jdk/client eventually 
> pushes to jdk/dev. I don't know how often jdk9/client integrates into 
> jdk9/dev but it doesn't seem to be very frequent (hg incoming suggests 
> there is currently about a month of changes backed up in jdk9/client 
> but there may be issues to explain this).
>
> For this specific case then it doesn't seem worth it, it would be much 
> less effort to just push the lot to jdk9/dev. Clearly if there were 
> substantive changes then it would be important to push the changes to 
> the forest where they are most likely to get tested but it hardly 
> seems worth it here. From what I can tell then Phil or others sync up 
> jdk9/client regularly and that might be the most efficient way to get 
> these changes into jdk9/client.
>
The changes should go through client for the reasons I already gave.
No new permissions are needed but it will need a unique bug id.

FWIW integrations are intended to be bi-weekly but holidays interfered 
this time.

-phil.

> -Alan



From jennifer.godinez at oracle.com  Mon May 19 18:21:40 2014
From: jennifer.godinez at oracle.com (Jennifer Godinez)
Date: Mon, 19 May 2014 11:21:40 -0700
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8042864 : Fix raw and
 unchecked warnings in javax.print
In-Reply-To: <537A32D3.9070302@oracle.com>
References: <53751063.6070001@oracle.com>
	<537543D0.9010900@oracle.com>	<53756498.2040805@oracle.com>
	<537A32D3.9070302@oracle.com>
Message-ID: <537A4BB4.3030602@oracle.com>

Looks good.

- Jennifer
On 5/19/2014 9:35 AM, Joe Darcy wrote:
> *ping*
>
> Any other comments?
>
> Thanks,
>
> -Joe
>
> On 05/15/2014 06:06 PM, Joe Darcy wrote:
>> Hi Henry,
>>
>> On 05/15/2014 03:46 PM, Henry Jen wrote:
>>> On 05/15/2014 12:07 PM, Joe Darcy wrote:
>>>> Hello,
>>>>
>>>> Please review these change to fix
>>>>
>>>>      JDK-8042864 : Fix raw and unchecked warnings in javax.print
>>>>      http://cr.openjdk.java.net/~darcy/8042864.0/
>>>>
>>>> Patch below.
>>>
>>> Looks good to me, just nit-picking.
>>>
>>>>
>>>> --- old/src/share/classes/javax/print/PrintServiceLookup.java 
>>>> 2014-05-15
>>>> 12:04:20.000000000 -0700
>>>> +++ new/src/share/classes/javax/print/PrintServiceLookup.java 
>>>> 2014-05-15
>>>> 12:04:20.000000000 -0700
>>>> @@ -208,7 +207,7 @@
>>>>        */
>>>>       public static boolean registerServiceProvider(PrintServiceLookup
>>>> sp) {
>>>>           synchronized (PrintServiceLookup.class) {
>>>> -            Iterator psIterator = getAllLookupServices().iterator();
>>>> +            Iterator<?> psIterator = 
>>>> getAllLookupServices().iterator();
>>>>               while (psIterator.hasNext()) {
>>>>                   try {
>>>>                       Object lus = psIterator.next();
>>>
>>> We know this is Iterator<PrinterServiceLookup>, but this works.
>>
>> I can put the more precise type information in.
>>
>>>
>>>> ---
>>>> old/src/share/classes/javax/print/attribute/AttributeSetUtilities.java
>>>> 2014-05-15 12:04:22.000000000 -0700
>>>> +++
>>>> new/src/share/classes/javax/print/attribute/AttributeSetUtilities.java
>>>> 2014-05-15 12:04:22.000000000 -0700
>>>> @@ -523,7 +523,7 @@
>>>>       public static Class<?>
>>>>           verifyAttributeCategory(Object object, Class<?> 
>>>> interfaceName) {
>>>>
>>>> -        Class result = (Class) object;
>>>> +        Class<?> result = (Class) object;
>>>>           if (interfaceName.isAssignableFrom (result)) {
>>>>               return result;
>>>>           }
>>>
>>> Should the cast be (Class<?>) instead of (Class)?
>>
>> I think either is okay, but I'm fine to change this to Class<?>.
>>
>>>
>>>> ---
>>>> old/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java 
>>>>
>>>> 2014-05-15 12:04:24.000000000 -0700
>>>> +++
>>>> new/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java 
>>>>
>>>> 2014-05-15 12:04:23.000000000 -0700
>>>> @@ -110,7 +110,7 @@
>>>>        * @return  Printing attribute class (category), an instance 
>>>> of class
>>>>        *          {@link java.lang.Class java.lang.Class}.
>>>>        */
>>>> -    public final Class getCategory() {
>>>> +    public final Class<DialogTypeSelection> getCategory() {
>>>>           return DialogTypeSelection.class;
>>>>       }
>>>>
>>>
>>> Would this be too specific for this public API? <? extends 
>>> Attribute> is defined in interface Attribute.
>>
>> Well, the javadoc does say that DialogTypeSelection.class is 
>> returned. The DialogTypeSelection class does implement the Attribute 
>> interface so all the typing works out fine as-is.
>>
>>>
>>>
>>>> ---
>>>> old/src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java 
>>>>
>>>> 2014-05-15 12:04:25.000000000 -0700
>>>> +++
>>>> new/src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java 
>>>>
>>>> 2014-05-15 12:04:24.000000000 -0700
>>>> @@ -242,16 +242,18 @@
>>>>           extends AbstractSet<PrinterStateReason>
>>>>       {
>>>>           private Severity mySeverity;
>>>> -        private Set myEntrySet;
>>>> +        //
>>>> +        private Set<Map.Entry<PrinterStateReason, Severity>> 
>>>> myEntrySet;
>>>>
>>>> -        public PrinterStateReasonSet(Severity severity, Set 
>>>> entrySet) {
>>>> +        public PrinterStateReasonSet(Severity severity,
>>>> + Set<Map.Entry<PrinterStateReason, Severity>> entrySet) {
>>>>               mySeverity = severity;
>>>>               myEntrySet = entrySet;
>>>>           }
>>>>
>>>>           public int size() {
>>>>               int result = 0;
>>>> -            Iterator iter = iterator();
>>>> +            Iterator<?> iter = iterator();
>>>
>>> We know it is Iterator<PrinterStateReason>.
>>>
>>>
>>
>> That was less clear when I addressed the warning on that line, but 
>> the exact time works better.
>>
>> Updated webrev uploaded to:
>>
>>     http://cr.openjdk.java.net/~darcy/8042864.1
>>
>> Thanks for the review,
>>
>> -Joe
>>
>



From philip.race at oracle.com  Mon May 19 18:36:17 2014
From: philip.race at oracle.com (Phil Race)
Date: Mon, 19 May 2014 11:36:17 -0700
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8042864 : Fix raw and
 unchecked warnings in javax.print
In-Reply-To: <537A32D3.9070302@oracle.com>
References: <53751063.6070001@oracle.com> <537543D0.9010900@oracle.com>
	<53756498.2040805@oracle.com> <537A32D3.9070302@oracle.com>
Message-ID: <537A4F21.5010803@oracle.com>

Some of these seem to need a CCC eg ..
In AttributeException

public Class<?>[] getUnsupportedAttributes();

  and ...

http://cr.openjdk.java.net/~darcy/8042864.0/src/share/classes/javax/print/MimeType.java.sdiff.html

public Map<String, String> getParameterMap() {



http://cr.openjdk.java.net/~darcy/8042864.0/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java.sdiff.html

< 113 public final Class getCategory() {

 > 113 public final Class<DialogTypeSelection> getCategory() {


getCategory() is a super-class method ..

So this seems wrong to me and I think|it should look like this ..|

http://docs.oracle.com/javase/8/docs/api/javax/print/attribute/Attribute.html
|Class <http://docs.oracle.com/javase/8/docs/api/java/lang/Class.html><? 
extends Attribute 
<http://docs.oracle.com/javase/8/docs/api/javax/print/attribute/Attribute.html>>| 
|getCategory 
<http://docs.oracle.com/javase/8/docs/api/javax/print/attribute/Attribute.html#getCategory-->()




-phil.
|
On 05/19/2014 09:35 AM, Joe Darcy wrote:
> *ping*
>
> Any other comments?
>
> Thanks,
>
> -Joe
>
> On 05/15/2014 06:06 PM, Joe Darcy wrote:
>> Hi Henry,
>>
>> On 05/15/2014 03:46 PM, Henry Jen wrote:
>>> On 05/15/2014 12:07 PM, Joe Darcy wrote:
>>>> Hello,
>>>>
>>>> Please review these change to fix
>>>>
>>>>      JDK-8042864 : Fix raw and unchecked warnings in javax.print
>>>>      http://cr.openjdk.java.net/~darcy/8042864.0/
>>>>
>>>> Patch below.
>>>
>>> Looks good to me, just nit-picking.
>>>
>>>>
>>>> --- old/src/share/classes/javax/print/PrintServiceLookup.java 
>>>> 2014-05-15
>>>> 12:04:20.000000000 -0700
>>>> +++ new/src/share/classes/javax/print/PrintServiceLookup.java 
>>>> 2014-05-15
>>>> 12:04:20.000000000 -0700
>>>> @@ -208,7 +207,7 @@
>>>>        */
>>>>       public static boolean registerServiceProvider(PrintServiceLookup
>>>> sp) {
>>>>           synchronized (PrintServiceLookup.class) {
>>>> -            Iterator psIterator = getAllLookupServices().iterator();
>>>> +            Iterator<?> psIterator = 
>>>> getAllLookupServices().iterator();
>>>>               while (psIterator.hasNext()) {
>>>>                   try {
>>>>                       Object lus = psIterator.next();
>>>
>>> We know this is Iterator<PrinterServiceLookup>, but this works.
>>
>> I can put the more precise type information in.
>>
>>>
>>>> ---
>>>> old/src/share/classes/javax/print/attribute/AttributeSetUtilities.java
>>>> 2014-05-15 12:04:22.000000000 -0700
>>>> +++
>>>> new/src/share/classes/javax/print/attribute/AttributeSetUtilities.java
>>>> 2014-05-15 12:04:22.000000000 -0700
>>>> @@ -523,7 +523,7 @@
>>>>       public static Class<?>
>>>>           verifyAttributeCategory(Object object, Class<?> 
>>>> interfaceName) {
>>>>
>>>> -        Class result = (Class) object;
>>>> +        Class<?> result = (Class) object;
>>>>           if (interfaceName.isAssignableFrom (result)) {
>>>>               return result;
>>>>           }
>>>
>>> Should the cast be (Class<?>) instead of (Class)?
>>
>> I think either is okay, but I'm fine to change this to Class<?>.
>>
>>>
>>>> ---
>>>> old/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java 
>>>>
>>>> 2014-05-15 12:04:24.000000000 -0700
>>>> +++
>>>> new/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java 
>>>>
>>>> 2014-05-15 12:04:23.000000000 -0700
>>>> @@ -110,7 +110,7 @@
>>>>        * @return  Printing attribute class (category), an instance 
>>>> of class
>>>>        *          {@link java.lang.Class java.lang.Class}.
>>>>        */
>>>> -    public final Class getCategory() {
>>>> +    public final Class<DialogTypeSelection> getCategory() {
>>>>           return DialogTypeSelection.class;
>>>>       }
>>>>
>>>
>>> Would this be too specific for this public API? <? extends 
>>> Attribute> is defined in interface Attribute.
>>
>> Well, the javadoc does say that DialogTypeSelection.class is 
>> returned. The DialogTypeSelection class does implement the Attribute 
>> interface so all the typing works out fine as-is.
>>
>>>
>>>
>>>> ---
>>>> old/src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java 
>>>>
>>>> 2014-05-15 12:04:25.000000000 -0700
>>>> +++
>>>> new/src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java 
>>>>
>>>> 2014-05-15 12:04:24.000000000 -0700
>>>> @@ -242,16 +242,18 @@
>>>>           extends AbstractSet<PrinterStateReason>
>>>>       {
>>>>           private Severity mySeverity;
>>>> -        private Set myEntrySet;
>>>> +        //
>>>> +        private Set<Map.Entry<PrinterStateReason, Severity>> 
>>>> myEntrySet;
>>>>
>>>> -        public PrinterStateReasonSet(Severity severity, Set 
>>>> entrySet) {
>>>> +        public PrinterStateReasonSet(Severity severity,
>>>> + Set<Map.Entry<PrinterStateReason, Severity>> entrySet) {
>>>>               mySeverity = severity;
>>>>               myEntrySet = entrySet;
>>>>           }
>>>>
>>>>           public int size() {
>>>>               int result = 0;
>>>> -            Iterator iter = iterator();
>>>> +            Iterator<?> iter = iterator();
>>>
>>> We know it is Iterator<PrinterStateReason>.
>>>
>>>
>>
>> That was less clear when I addressed the warning on that line, but 
>> the exact time works better.
>>
>> Updated webrev uploaded to:
>>
>>     http://cr.openjdk.java.net/~darcy/8042864.1
>>
>> Thanks for the review,
>>
>> -Joe
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140519/82cea1e8/attachment.html>

From anthony.petrov at oracle.com  Mon May 19 18:42:38 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Mon, 19 May 2014 22:42:38 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: Allow using the system libjpeg
In-Reply-To: <20140517004529.GD4370@redhat.com>
References: <20140517004529.GD4370@redhat.com>
Message-ID: <537A509E.2090504@oracle.com>

Hi Omair,

common/autoconf/libraries.m4
>  624       [use libjpeg from build system or OpenJDK source (system, bundled) @<:bundled@:>@])])

"@<:bundled@:>@" should read "@<:@bundled@:>@" - note the missing @.


make/lib/Awt2dLibraries.gmk
> 1236     LIBJPEG_CFLAGS := $(JDK_TOPDIR)/src/share/native/sun/awt/image/jpeg

Since these are compiler flags, I suppose this should read "-I<path>", 
not just "<path>".

Did you build with --with-jpeg=bundled ? Can the resulting JDK read jpeg 
files?

--
best regards,
Anthony

On 5/17/2014 4:45 AM, Omair Majid wrote:
> Hi,
>
> Webrevs are at:
> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/00
> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/00.jdk
>
> This patch modifies OpenJDK to allow building and running using the
> system copy of libjpeg. This follows my previous changes for lcms
> and a lot of the decisions made on that patch apply here.
>
> This is the last of my system-library patches :)
>
> Thanks,
> Omair
>


From joe.darcy at oracle.com  Mon May 19 18:54:48 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 19 May 2014 11:54:48 -0700
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8042864 : Fix raw and
 unchecked warnings in javax.print
In-Reply-To: <537A4F21.5010803@oracle.com>
References: <53751063.6070001@oracle.com> <537543D0.9010900@oracle.com>
	<53756498.2040805@oracle.com> <537A32D3.9070302@oracle.com>
	<537A4F21.5010803@oracle.com>
Message-ID: <537A5378.8000607@oracle.com>

Hi Phil,

On 05/19/2014 11:36 AM, Phil Race wrote:
> Some of these seem to need a CCC eg ..
> In AttributeException
>
> public Class<?>[] getUnsupportedAttributes();
>
>  and ...
>
> http://cr.openjdk.java.net/~darcy/8042864.0/src/share/classes/javax/print/MimeType.java.sdiff.html
>
> public Map<String, String> getParameterMap() {

That is correct; there are a few API changes that need to go through 
ccc. However, they are just the usual sorts of changes when an API is 
generified; I was going to file the request once the code review process 
was a bit further along.

>
>
>
> http://cr.openjdk.java.net/~darcy/8042864.0/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java.sdiff.html
>
> < 113 public final Class getCategory() {
>
> > 113 public final Class<DialogTypeSelection> getCategory() {
>
>
> getCategory() is a super-class method ..
>
> So this seems wrong to me and I think|it should look like this ..|
>
> http://docs.oracle.com/javase/8/docs/api/javax/print/attribute/Attribute.html
> |Class 
> <http://docs.oracle.com/javase/8/docs/api/java/lang/Class.html><? 
> extends Attribute 
> <http://docs.oracle.com/javase/8/docs/api/javax/print/attribute/Attribute.html>>| 
> |getCategory 
> <http://docs.oracle.com/javase/8/docs/api/javax/print/attribute/Attribute.html#getCategory-->()
>
>
> |

Part of the generics language feature was covariant overrides, that is, 
when a subtype overrides a methods from a supertype, the return type of 
the subtype method can be a more-specific type.

That is the case here; DialogTypeSelection is a subtype of "? extends 
Attribute" so the getCategory method in DialogTypeSelection is a 
covariant override of the superclass method. Moreover, since the 
superclass uses the "? extends Attribute" wildcard, the intention is for 
subclasses to override this method when possible.

Thanks,

-Joe

> |
>
> -phil.
> |
> On 05/19/2014 09:35 AM, Joe Darcy wrote:
>> *ping*
>>
>> Any other comments?
>>
>> Thanks,
>>
>> -Joe
>>
>> On 05/15/2014 06:06 PM, Joe Darcy wrote:
>>> Hi Henry,
>>>
>>> On 05/15/2014 03:46 PM, Henry Jen wrote:
>>>> On 05/15/2014 12:07 PM, Joe Darcy wrote:
>>>>> Hello,
>>>>>
>>>>> Please review these change to fix
>>>>>
>>>>>      JDK-8042864 : Fix raw and unchecked warnings in javax.print
>>>>> http://cr.openjdk.java.net/~darcy/8042864.0/
>>>>>
>>>>> Patch below.
>>>>
>>>> Looks good to me, just nit-picking.
>>>>
>>>>>
>>>>> --- old/src/share/classes/javax/print/PrintServiceLookup.java 
>>>>> 2014-05-15
>>>>> 12:04:20.000000000 -0700
>>>>> +++ new/src/share/classes/javax/print/PrintServiceLookup.java 
>>>>> 2014-05-15
>>>>> 12:04:20.000000000 -0700
>>>>> @@ -208,7 +207,7 @@
>>>>>        */
>>>>>       public static boolean 
>>>>> registerServiceProvider(PrintServiceLookup
>>>>> sp) {
>>>>>           synchronized (PrintServiceLookup.class) {
>>>>> -            Iterator psIterator = getAllLookupServices().iterator();
>>>>> +            Iterator<?> psIterator = 
>>>>> getAllLookupServices().iterator();
>>>>>               while (psIterator.hasNext()) {
>>>>>                   try {
>>>>>                       Object lus = psIterator.next();
>>>>
>>>> We know this is Iterator<PrinterServiceLookup>, but this works.
>>>
>>> I can put the more precise type information in.
>>>
>>>>
>>>>> ---
>>>>> old/src/share/classes/javax/print/attribute/AttributeSetUtilities.java 
>>>>>
>>>>> 2014-05-15 12:04:22.000000000 -0700
>>>>> +++
>>>>> new/src/share/classes/javax/print/attribute/AttributeSetUtilities.java 
>>>>>
>>>>> 2014-05-15 12:04:22.000000000 -0700
>>>>> @@ -523,7 +523,7 @@
>>>>>       public static Class<?>
>>>>>           verifyAttributeCategory(Object object, Class<?> 
>>>>> interfaceName) {
>>>>>
>>>>> -        Class result = (Class) object;
>>>>> +        Class<?> result = (Class) object;
>>>>>           if (interfaceName.isAssignableFrom (result)) {
>>>>>               return result;
>>>>>           }
>>>>
>>>> Should the cast be (Class<?>) instead of (Class)?
>>>
>>> I think either is okay, but I'm fine to change this to Class<?>.
>>>
>>>>
>>>>> ---
>>>>> old/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java 
>>>>>
>>>>> 2014-05-15 12:04:24.000000000 -0700
>>>>> +++
>>>>> new/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java 
>>>>>
>>>>> 2014-05-15 12:04:23.000000000 -0700
>>>>> @@ -110,7 +110,7 @@
>>>>>        * @return  Printing attribute class (category), an instance 
>>>>> of class
>>>>>        *          {@link java.lang.Class java.lang.Class}.
>>>>>        */
>>>>> -    public final Class getCategory() {
>>>>> +    public final Class<DialogTypeSelection> getCategory() {
>>>>>           return DialogTypeSelection.class;
>>>>>       }
>>>>>
>>>>
>>>> Would this be too specific for this public API? <? extends 
>>>> Attribute> is defined in interface Attribute.
>>>
>>> Well, the javadoc does say that DialogTypeSelection.class is 
>>> returned. The DialogTypeSelection class does implement the Attribute 
>>> interface so all the typing works out fine as-is.
>>>
>>>>
>>>>
>>>>> ---
>>>>> old/src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java 
>>>>>
>>>>> 2014-05-15 12:04:25.000000000 -0700
>>>>> +++
>>>>> new/src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java 
>>>>>
>>>>> 2014-05-15 12:04:24.000000000 -0700
>>>>> @@ -242,16 +242,18 @@
>>>>>           extends AbstractSet<PrinterStateReason>
>>>>>       {
>>>>>           private Severity mySeverity;
>>>>> -        private Set myEntrySet;
>>>>> +        //
>>>>> +        private Set<Map.Entry<PrinterStateReason, Severity>> 
>>>>> myEntrySet;
>>>>>
>>>>> -        public PrinterStateReasonSet(Severity severity, Set 
>>>>> entrySet) {
>>>>> +        public PrinterStateReasonSet(Severity severity,
>>>>> + Set<Map.Entry<PrinterStateReason, Severity>> entrySet) {
>>>>>               mySeverity = severity;
>>>>>               myEntrySet = entrySet;
>>>>>           }
>>>>>
>>>>>           public int size() {
>>>>>               int result = 0;
>>>>> -            Iterator iter = iterator();
>>>>> +            Iterator<?> iter = iterator();
>>>>
>>>> We know it is Iterator<PrinterStateReason>.
>>>>
>>>>
>>>
>>> That was less clear when I addressed the warning on that line, but 
>>> the exact time works better.
>>>
>>> Updated webrev uploaded to:
>>>
>>> http://cr.openjdk.java.net/~darcy/8042864.1
>>>
>>> Thanks for the review,
>>>
>>> -Joe
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140519/dc3e2f96/attachment.html>

From philip.race at oracle.com  Mon May 19 19:14:15 2014
From: philip.race at oracle.com (Phil Race)
Date: Mon, 19 May 2014 12:14:15 -0700
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8042864 : Fix raw and
 unchecked warnings in javax.print
In-Reply-To: <537A5378.8000607@oracle.com>
References: <53751063.6070001@oracle.com> <537543D0.9010900@oracle.com>
	<53756498.2040805@oracle.com> <537A32D3.9070302@oracle.com>
	<537A4F21.5010803@oracle.com> <537A5378.8000607@oracle.com>
Message-ID: <537A5807.6070502@oracle.com>

On 5/19/2014 11:54 AM, Joe Darcy wrote:
>>
>>
>> http://cr.openjdk.java.net/~darcy/8042864.0/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java.sdiff.html
>>
>> < 113 public final Class getCategory() {
>>
>> > 113 public final Class<DialogTypeSelection> getCategory() {
>>
>>
>> getCategory() is a super-class method ..
>>
>> So this seems wrong to me and I think|it should look like this ..|
>>
>> http://docs.oracle.com/javase/8/docs/api/javax/print/attribute/Attribute.html
>> |Class 
>> <http://docs.oracle.com/javase/8/docs/api/java/lang/Class.html><? 
>> extends Attribute 
>> <http://docs.oracle.com/javase/8/docs/api/javax/print/attribute/Attribute.html>>| 
>> |getCategory 
>> <http://docs.oracle.com/javase/8/docs/api/javax/print/attribute/Attribute.html#getCategory-->()
>>
>>
>> |
>
> Part of the generics language feature was covariant overrides, that 
> is, when a subtype overrides a methods from a supertype, the return 
> type of the subtype method can be a more-specific type.
>
> That is the case here; DialogTypeSelection is a subtype of "? extends 
> Attribute" so the getCategory method in DialogTypeSelection is a 
> covariant override of the superclass method. Moreover, since the 
> superclass uses the "? extends Attribute" wildcard, the intention is 
> for subclasses to override this method when possible.
>



1. FYI it appears I reviewed the .0 version since the reference to the 
.1 was so far down I didn't see it

2. I hadn't noticed until now that Henry also mentioned the 
getCategory() API ..

3. The 64 (!) other peer subclasses all use Class<? extends Attribute>.
    Yes, it will be a DialogTypeSelection but the primary use case is to 
be a member of a
   collection of Attribute so a more specific  API type isn't very 
useful at all .. and it
  will just stick out like a sore thumb.

-phil.



From joe.darcy at oracle.com  Mon May 19 19:49:20 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 19 May 2014 12:49:20 -0700
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8042864 : Fix raw and
 unchecked warnings in javax.print
In-Reply-To: <537A5807.6070502@oracle.com>
References: <53751063.6070001@oracle.com> <537543D0.9010900@oracle.com>
	<53756498.2040805@oracle.com> <537A32D3.9070302@oracle.com>
	<537A4F21.5010803@oracle.com> <537A5378.8000607@oracle.com>
	<537A5807.6070502@oracle.com>
Message-ID: <537A6040.4010302@oracle.com>

Revised webev at

     http://cr.openjdk.java.net/~darcy/8042864.2

Comments below.

On 05/19/2014 12:14 PM, Phil Race wrote:
> On 5/19/2014 11:54 AM, Joe Darcy wrote:
>>>
>>>
>>> http://cr.openjdk.java.net/~darcy/8042864.0/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java.sdiff.html 
>>>
>>>
>>> < 113 public final Class getCategory() {
>>>
>>> > 113 public final Class<DialogTypeSelection> getCategory() {
>>>
>>>
>>> getCategory() is a super-class method ..
>>>
>>> So this seems wrong to me and I think|it should look like this ..|
>>>
>>> http://docs.oracle.com/javase/8/docs/api/javax/print/attribute/Attribute.html 
>>>
>>> |Class 
>>> <http://docs.oracle.com/javase/8/docs/api/java/lang/Class.html><? 
>>> extends Attribute 
>>> <http://docs.oracle.com/javase/8/docs/api/javax/print/attribute/Attribute.html>>| 
>>> |getCategory 
>>> <http://docs.oracle.com/javase/8/docs/api/javax/print/attribute/Attribute.html#getCategory-->()
>>>
>>>
>>> |
>>
>> Part of the generics language feature was covariant overrides, that 
>> is, when a subtype overrides a methods from a supertype, the return 
>> type of the subtype method can be a more-specific type.
>>
>> That is the case here; DialogTypeSelection is a subtype of "? extends 
>> Attribute" so the getCategory method in DialogTypeSelection is a 
>> covariant override of the superclass method. Moreover, since the 
>> superclass uses the "? extends Attribute" wildcard, the intention is 
>> for subclasses to override this method when possible.
>>
>
>
>
> 1. FYI it appears I reviewed the .0 version since the reference to the 
> .1 was so far down I didn't see it
>
> 2. I hadn't noticed until now that Henry also mentioned the 
> getCategory() API ..
>
> 3. The 64 (!) other peer subclasses all use Class<? extends Attribute>.
>    Yes, it will be a DialogTypeSelection but the primary use case is 
> to be a member of a
>   collection of Attribute so a more specific  API type isn't very 
> useful at all .. and it
>  will just stick out like a sore thumb.
>
>

It is unfortunate that the other peer subclasses were suboptimally 
generified to not use a covariant return when this API was initially 
generified. From the sampling of methods I looked all, the methods in 
question are final and state something like "This method must return 
this specific Class object for the Foo class." Given that specification, 
the typing of the getCategory method should reflect the required 
behavior of the method and return a Class<Foo> rather than a Class<? 
extends Attribute>.

However, to be consistent with the existing poor generification, in the 
.2 version of the webrev above I have changed the return type of the 
method to the less informative Class<? extends Attribute>.

-Joe

PS I compile the classes before I send them out for a code review so if 
there is a type error that would break the build, that is caught beforehand.


From philip.race at oracle.com  Mon May 19 20:08:48 2014
From: philip.race at oracle.com (Phil Race)
Date: Mon, 19 May 2014 13:08:48 -0700
Subject: [OpenJDK 2D-Dev] JDK 9 RFR of JDK-8042864 : Fix raw and
 unchecked warnings in javax.print
In-Reply-To: <537A6040.4010302@oracle.com>
References: <53751063.6070001@oracle.com> <537543D0.9010900@oracle.com>
	<53756498.2040805@oracle.com> <537A32D3.9070302@oracle.com>
	<537A4F21.5010803@oracle.com> <537A5378.8000607@oracle.com>
	<537A5807.6070502@oracle.com> <537A6040.4010302@oracle.com>
Message-ID: <537A64D0.7090707@oracle.com>

OK now. I wouldn't necessarily agree the generification was poor, and it 
was a choice
made by someone else ..

-phil.

On 5/19/2014 12:49 PM, Joe Darcy wrote:
> Revised webev at
>
>     http://cr.openjdk.java.net/~darcy/8042864.2
>
> Comments below.
>
> On 05/19/2014 12:14 PM, Phil Race wrote:
>> On 5/19/2014 11:54 AM, Joe Darcy wrote:
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~darcy/8042864.0/src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java.sdiff.html 
>>>>
>>>>
>>>> < 113 public final Class getCategory() {
>>>>
>>>> > 113 public final Class<DialogTypeSelection> getCategory() {
>>>>
>>>>
>>>> getCategory() is a super-class method ..
>>>>
>>>> So this seems wrong to me and I think|it should look like this ..|
>>>>
>>>> http://docs.oracle.com/javase/8/docs/api/javax/print/attribute/Attribute.html 
>>>>
>>>> |Class 
>>>> <http://docs.oracle.com/javase/8/docs/api/java/lang/Class.html><? 
>>>> extends Attribute 
>>>> <http://docs.oracle.com/javase/8/docs/api/javax/print/attribute/Attribute.html>>| 
>>>> |getCategory 
>>>> <http://docs.oracle.com/javase/8/docs/api/javax/print/attribute/Attribute.html#getCategory-->()
>>>>
>>>>
>>>> |
>>>
>>> Part of the generics language feature was covariant overrides, that 
>>> is, when a subtype overrides a methods from a supertype, the return 
>>> type of the subtype method can be a more-specific type.
>>>
>>> That is the case here; DialogTypeSelection is a subtype of "? 
>>> extends Attribute" so the getCategory method in DialogTypeSelection 
>>> is a covariant override of the superclass method. Moreover, since 
>>> the superclass uses the "? extends Attribute" wildcard, the 
>>> intention is for subclasses to override this method when possible.
>>>
>>
>>
>>
>> 1. FYI it appears I reviewed the .0 version since the reference to 
>> the .1 was so far down I didn't see it
>>
>> 2. I hadn't noticed until now that Henry also mentioned the 
>> getCategory() API ..
>>
>> 3. The 64 (!) other peer subclasses all use Class<? extends Attribute>.
>>    Yes, it will be a DialogTypeSelection but the primary use case is 
>> to be a member of a
>>   collection of Attribute so a more specific  API type isn't very 
>> useful at all .. and it
>>  will just stick out like a sore thumb.
>>
>>
>
> It is unfortunate that the other peer subclasses were suboptimally 
> generified to not use a covariant return when this API was initially 
> generified. From the sampling of methods I looked all, the methods in 
> question are final and state something like "This method must return 
> this specific Class object for the Foo class." Given that 
> specification, the typing of the getCategory method should reflect the 
> required behavior of the method and return a Class<Foo> rather than a 
> Class<? extends Attribute>.
>
> However, to be consistent with the existing poor generification, in 
> the .2 version of the webrev above I have changed the return type of 
> the method to the less informative Class<? extends Attribute>.
>
> -Joe
>
> PS I compile the classes before I send them out for a code review so 
> if there is a type error that would break the build, that is caught 
> beforehand.



From luchsh at linux.vnet.ibm.com  Tue May 20 06:17:42 2014
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Tue, 20 May 2014 14:17:42 +0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> Review request for 8034218: AIX:
 Provide a better fontconfig.properties file
In-Reply-To: <CA+3eh13kDJ+Yh90j7bXv1e2+1dXkBxqwiqmqG0cLkCw-rJLVvg@mail.gmail.com>
References: <CAC-GWLfk5f0b=ufCcowDEvDyVuYFYkd2SUp9-0srLBh2r7gPDA@mail.gmail.com>
	<CA+3eh12cJpJBWPd1BXnSVTg0vziD66dP=y-RpXR5w5gsaO__Pw@mail.gmail.com>
	<5370F9E7.8050109@oracle.com> <5370FB1F.1070904@oracle.com>
	<CAC-GWLc79VLvEspuACAc_LeyJOYYLB368ECSLeEJ_t8T_-v+Lw@mail.gmail.com>
	<CA+3eh13kDJ+Yh90j7bXv1e2+1dXkBxqwiqmqG0cLkCw-rJLVvg@mail.gmail.com>
Message-ID: <CAC-GWLdwcd7=_C3R4e_tpvUDKS30w1aGA_oBcmTKLG2MginWgQ@mail.gmail.com>

Hi Volker,

I've updated the patch by dropping the those fonts configurations from
$JRE_LIB_FONTS directory.
The change is based on the SAP version, current change is primarily adding
support for CJK fonts, pls review.

http://cr.openjdk.java.net/~luchsh/JDK-8034218.v2/

Thanks
Jonathan


On Tue, May 13, 2014 at 5:25 PM, Volker Simonis <volker.simonis at gmail.com>wrote:

> Hi Jonathan,
>
> from all fontconfig files in make/data/fontconfig,
> solaris.fontconfig.properties is the only file which contains a single
> line referring to $JRE_LIB_FONTS. This is obviously a first-day bug
> which should be fixed.
>
> It simply makes no sense to define font files and default fonts with
> references to files which won't be in a JDK for sure. Again, if you
> could convince IBM to donate the corresponding fonts to the OpenJDK
> that would be great. Otherwise these entries should be dropped from
> the fontconfig files.
>
> Thank you and best regards,
> Volker
>
>
> On Tue, May 13, 2014 at 4:06 AM, Jonathan Lu <luchsh at linux.vnet.ibm.com>
> wrote:
> > Hi Phil, Volker,
> >
> > Thanks for your comments, but I noticed that JRE_LIB_FONTS has been
> referred
> > by the solaris fontconfig file,
> >
> > jdk/make/data/fontconfig/solaris.fontconfig.properties
> >
> > So I'm wondering if we can do this in the same way as Solaris platform.
> >
> >
> > Thanks
> > Jonathan
> >
> >
> >
> > On Tue, May 13, 2014 at 12:47 AM, Phil Race <philip.race at oracle.com>
> wrote:
> >>
> >> removed awt-dev ...
> >>
> >>
> >> > I don't think we should reference the fonts
> >> > under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties
> >>
> >> Volker is correct on this point.
> >>
> >> Since OpenJDK can't ship those fonts we made sure they were never used
> >> in any openjdk fontconfig file.
> >>
> >> -phil.
> >>
> >>
> >>
> >> On 05/12/2014 09:42 AM, Phil Race wrote:
> >>>
> >>> All,
> >>>
> >>> If you want to continue this discussion i should be restarted on 2d-dev
> >>> and awt-dev removed. AWT has nothing to do with the fonts ..
> >>> I've fixed the bug sub-cat.
> >>>
> >>> -phil.
> >>>
> >>> On 05/12/2014 09:06 AM, Volker Simonis wrote:
> >>>>
> >>>> Hi Jonathan,
> >>>>
> >>>> thanks for submitting this patch.
> >>>>
> >>>> Overall it looks good, but I don't think we should reference the fonts
> >>>> under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties
> >>>> (at least not until IBM will not also contribute the corresponding
> >>>> fonts :)
> >>>>
> >>>> I would also find it helpful to keep a reworked version of the
> comment:
> >>>>
> >>>>    27 # Minimal version for AIX using the standard Latin Type1 Fonts
> >>>> from the
> >>>>    28 # package X11.fnt.iso_T1. These fonts are installed by default
> >>>> into
> >>>>    29 # "/usr/lpp/X11/lib/X11/fonts/Type1" and sym-linked to
> >>>> "/usr/lib/X11/fonts/Type1"
> >>>>
> >>>> which mentions which AIX packages provide the other referenced font
> >>>> files.
> >>>>
> >>>> Thank you and best regards,
> >>>> Volker
> >>>>
> >>>>
> >>>>
> >>>> On Mon, May 12, 2014 at 12:37 PM, Jonathan Lu
> >>>> <luchsh at linux.vnet.ibm.com> wrote:
> >>>>>
> >>>>> Hi awt-dev,
> >>>>>
> >>>>> Please review the fix for issue:
> >>>>> https://bugs.openjdk.java.net/browse/JDK-8034218
> >>>>>
> >>>>> The changes are placed at
> >>>>> http://cr.openjdk.java.net/~luchsh/JDK-8034218/
> >>>>>
> >>>>> This patch is trying to provide a better fonctconfig.properties file
> >>>>> for AIX
> >>>>> platform,
> >>>>> which contains support for more languages, like CJK.
> >>>>>
> >>>>>
> >>>>> Thanks
> >>>>> Jonathan
> >>>>>
> >>>>>
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140520/b0ba5e23/attachment.html>

From paul.sandoz at oracle.com  Tue May 20 06:45:05 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 20 May 2014 07:45:05 +0100
Subject: [OpenJDK 2D-Dev] <AWT Dev> JDK-8041679 Replace uses of
	StringBuffer with StringBuilder within the JDK
In-Reply-To: <537A3CF5.5010401@oracle.com>
References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com>	<5371FDBD.9020002@oracle.com>	<0522DF2A-F91C-43D3-ABCF-CA74F8971DB5@oracle.com>	<53728B83.1060307@oracle.com>	<8A20EC45-A21E-49C8-9A8A-BDC16ED97B91@oracle.com>	<537331E5.4070108@oracle.com>	<007101BF-30BC-4761-A13A-0AE1EAD36DF5@oracle.com>	<53766815.40600@oracle.com>	<6F7CE86A-E4B7-4F6B-B698-6426890D1409@oracle.com>
	<5379B7DC.2020206@oracle.com> <537A3CF5.5010401@oracle.com>
Message-ID: <68F1F3CD-502A-4CBC-ABD6-7B1A24F9D3D8@oracle.com>


On May 19, 2014, at 6:18 PM, Phil Race <philip.race at oracle.com> wrote:

> On 5/19/2014 12:50 AM, Alan Bateman wrote:
>> On 19/05/2014 07:53, Paul Sandoz wrote:
>>> If i don't have permission to push to the client repo (which might be likely) i will need to hand over the patch to yourself or Sergey to commit. And i presume this will have to be a separate issue.
>> If you do decide to split this then it will require creating a second issue JIRA to avoid running foul of jcheck when jdk/client eventually pushes to jdk/dev. I don't know how often jdk9/client integrates into jdk9/dev but it doesn't seem to be very frequent (hg incoming suggests there is currently about a month of changes backed up in jdk9/client but there may be issues to explain this).
>> 
>> For this specific case then it doesn't seem worth it, it would be much less effort to just push the lot to jdk9/dev. Clearly if there were substantive changes then it would be important to push the changes to the forest where they are most likely to get tested but it hardly seems worth it here. From what I can tell then Phil or others sync up jdk9/client regularly and that might be the most efficient way to get these changes into jdk9/client.
>> 
> The changes should go through client for the reasons I already gave.

IIUC these were the reasons you gave in a previous email on this thread:

"I would not push hotspot changes to client either. Also lots of files
are being updated in client and doing it this way will minimise merges ..."

I don't find either very convincing.


> No new permissions are needed but it will need a unique bug id.
> 

Ok.


> FWIW integrations are intended to be bi-weekly but holidays interfered this time.
> 

Why does it take so long?

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140520/9b5789dd/signature.asc>

From volker.simonis at gmail.com  Tue May 20 08:34:09 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 20 May 2014 10:34:09 +0200
Subject: [OpenJDK 2D-Dev] <AWT Dev> Request for review: 8026385:
 [macosx] (awt) setjmp/longjmp changes the process signal mask on OS X
In-Reply-To: <A34B6713-5C40-42C2-9DF4-0CB695AF8D8F@oracle.com>
References: <C6AFC617-0DEE-4892-BDA1-AC7B3809FE49@oracle.com>
	<5372798B.1050103@oracle.com>
	<5A6B42D6-FCDC-4968-8D4C-F1CC777866F7@oracle.com>
	<53728153.3070002@oracle.com>
	<3E22C8BF-3F49-46F1-9565-45240DE28902@oracle.com>
	<EE677AB2-7CDE-4800-9AAB-C14A29CC4B3B@oracle.com>
	<4B720DD6-DF4F-4F00-979E-E02DC0FD70E2@oracle.com>
	<5374FB74.9040801@oracle.com>
	<504FD4A5-0921-4C49-87BA-64DF4D905F5D@oracle.com>
	<53762F1A.5030604@oracle.com>
	<877C69C9-8643-4BA5-87B0-6A0259BD9FBB@oracle.com>
	<CA+3eh10UNDG=+kieCZYrFapJU7d7rbQ7n+xxjJP_Tryi29gaFQ@mail.gmail.com>
	<A34B6713-5C40-42C2-9DF4-0CB695AF8D8F@oracle.com>
Message-ID: <CA+3eh136Hc2k=DXnwHAv5M=Ysd=ntV4_450qNnDy+bBCN1N=RA@mail.gmail.com>

Hi everybody,

I've analyzed this issue on AIX (and HPUX) and came to the conclusion
that it is not a problem on these platforms.

Just to make sure I got everything right, I'll summarize my
understanding of the problem here:

On MacOS, setjmp() saves the signal mask of the current thread BUT
restores the signal mask of the whole process after the corresponding
longjmp(). This obviously changes the signal mask of all threads which
had a different signal mask than the initial thread who called
setjmp(). I could easily reproduce this by loading a class which
provokes a verification exception in the un-fixed libverify.so.
Afterwards, the VM-thread won't listen to SIGQUIT anymore because it
now masks this signal in the same way like the Java thread which had
the verification exception.

On AIX/HPUX setjmp()/longjmp() is defined in the same way like on
MacOS in that it saves and restores the signal mask (and both
platforms provide _setjmp()/_longjmp() versions as well which do not
manipulate the signal mask). But while it is not clear from the
documentation, all my tests showed that longjmp() only restores the
signal mask of the current thread, which should be OK (i.e. I couldn't
see a blocked VM thread which doesn't react on SIQUIT anymore).

So to cut a long story short - no action seems to be required to fix
this issue on AIX:

As a side note I wonder why we didn't use sigsetjmp()/siglongjmp()
with a zero 'savemask' argument to fix this problem? It is
standardized by POSIX and would avoid the usage of "#ifdef __APPLE".

Thank you and best regards,
Volker


On Fri, May 16, 2014 at 6:04 PM, David DeHaven <david.dehaven at oracle.com> wrote:
>
> I'd thought about that, since Apple borrowed most of it's underpinnings from BSD, but had no evidence to suggest it was necessary.
>
> Anyways, at least you've identified and can rectify the issue :)
>
> -DrD-
>
>> Wow, sometimes it really makes sense to read apparently unrelated
>> email-threads on Friday afternoon:)
>>
>> It seems that AIX/HPUX have exactly the same problem like MacOS X.
>> From the AIX setjmp man-page:
>>
>> "The setjmp and longjmp subroutines save and restore the signal mask
>> sigmask (2), while _setjmp and _longjmp manipulate only the stack
>> context."
>>
>> From the HPUXM setjmp man-page:
>>
>> "setjmp(), longjmp()         These always save and restore the signal mask.
>> _setjmp(), _longjmp()        These never manipulate the signal mask."
>>
>> I think it doesn't make sense for you to wait pushing this until I
>> provide the corresponding AIX patches because anyway I'll have to
>> provide a fix not only for this issue but also for the other bugs you
>> mentioned (i.e. 8023786 and 8023720). So I'll better create a new bug
>> for AIX.
>>
>> Thank you and best regards,
>> Volker
>>
>> On Fri, May 16, 2014 at 5:38 PM, David DeHaven <david.dehaven at oracle.com> wrote:
>>>
>>> Thanks!
>>>
>>> -DrD-
>>>
>>>> The splashscreen changes look fine to me. Approved.
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 5/16/2014 7:18 PM, David DeHaven wrote:
>>>>>
>>>>> Could someone on AWT team approve the splashscreen changes?
>>>>>
>>>>> -DrD-
>>>>>
>>>>>> Approved.
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 5/15/2014 9:31 AM, David DeHaven wrote:
>>>>>>> Ping!
>>>>>>>
>>>>>>> Does this look OK?
>>>>>>>
>>>>>>> I've also filed an issue against JavaFX:
>>>>>>> https://javafx-jira.kenai.com/browse/RT-37125
>>>>>>>
>>>>>>> -DrD-
>>>>>>>
>>>>>>>>>>> I tried not modifying libpng but still ended up with lingering references to longjmp in pngread.o, despite libpng having png_ptr->longjmp_fn (bug in libpng?). pngread.c calls setjmp to set a default location to jump to in case the caller doesn't call setjmp, so if we continue down this path something in libpng must be modified. The only other option is to create our own setjmp.h and order it before /usr/include/setjmp.h, which seems dubious at best.
>>>>>>>>>>>
>>>>>>>>>>> I'm curious if the libpng changes are even needed since it's only used for splashscreen, which happens very early in the launch process. Also note that we didn't originally even call png_set_longjmp_fn, so any error should have resulted in an abort() instead of a call to longjmp... it appears we could retain the functionality we have today and #undef PNG_SETJMP_SUPPORTED (pngconf.h?). That would put the onus on developers to make sure their pngs don't have errors in them, or libsplashscreen will abort()...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> That's an interesting question and the answer might extend to the splashscreen changes too.
>>>>>>>>>> Its platform specific code and on MAC, the thread is created using pthreads directly and that
>>>>>>>>>> thread goes away once splashscreen is done. But its running at the same time as the VM
>>>>>>>>>> is booting up and creating threads and setting their signal masks. So I don't think you can
>>>>>>>>>> guarantee that it won't mess up the masks on the JRE threads if the PNG is bad. And I'm
>>>>>>>>>> also not sure you want to remove error handling from the library either.
>>>>>>>>>> So a HIGHLY VISIBLE DO NOT REMOVE comment might be the best you can do here.
>>>>>>>>> I have a better idea:
>>>>>>>>>
>>>>>>>>> png_default_error is the only place where png_longjmp is called. We could call png_set_error_fn to set up our own error handler (for Mac only), compile with PNG_SETJMP_SUPPORTED unset so it doesn't pull in setjmp/longjmp and our own implementation of the error handler would call _longjmp, which would jump back to where we call setjmp currently.
>>>>>>>> Ok, I figured out what's going on. It's not quite intuitive...
>>>>>>>>
>>>>>>>> png_jmpbuf is a macro defined in png.h, this calls png_set_longjmp_fn with longjmp, which is why I was seeing references to longjmp in the object file. That's what was throwing me off as it seems like it should only be getting the jmp_buf ptr stored in the png_ptr. I guess the intention was that setjmp/longjmp was optional, if you don't call setjmp then it just abort()s.
>>>>>>>>
>>>>>>>>
>>>>>>>> I changed splashscreen_png.c to:
>>>>>>>> #ifdef __APPLE__
>>>>>>>>   if (_setjmp(png_set_longjmp_fn(png_ptr, _longjmp, sizeof(jmp_buf)))) {
>>>>>>>> #else
>>>>>>>>   if (setjmp(png_jmpbuf(png_ptr))) {
>>>>>>>> #endif
>>>>>>>>
>>>>>>>> and it calls _longjmp instead. I verified this works by changing the macro to set png_longjmp to exit() and without the above change it does indeed exit prematurely with a bad png, with the change it reports the error but continues to load the application as would be expected.
>>>>>>>>
>>>>>>>> pngread.o still has a symbol table entry for _longjmp instead of __longjmp, but it's benign since we're ultimately forcing it to use the correct function. So I've left libpng completely unchanged.
>>>>>>>>
>>>>>>>>
>>>>>>>> With the change and using a bad png for splashscreen, I was able to get a stack trace once the application was running. Without the change to splashscreen_png.c, jstack was unable to connect to the process. So splashscreen absolutely can interfere with the signal handling.
>>>>>>>>
>>>>>>>>
>>>>>>>> Updated webrev:
>>>>>>>> http://cr.openjdk.java.net/~ddehaven/8026385/jdk.1/
>>>>>>>>
>>>>>>>> I can look into writing a regression test for this. It might not be trivial though since we're dealing with signal handlers, and if timing is a factor the test may not be reliable.
>>>>>>>>
>>>>>>>> -DrD-
>>>>>>>>
>>>>>>
>>>>>
>>>
>


From Sergey.Bylokhov at oracle.com  Tue May 20 16:42:45 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 20 May 2014 20:42:45 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8041644 [OGL] clip is ignored
 during surface->sw blit
Message-ID: <537B8605.9010204@oracle.com>

Hello.
Please review the fix for jdk 9, which is also targeted for jdk 8u20.
Description:
     Our implementation of opengl surface-> sw blit does not take into 
account the clipped area.
Suggested fix:
    I intersect a clip and a coordinates of destination, and if the 
resulted region is rectangle I use the usual blit, but if the region is 
complex I use intermediate buffer(like OGLAnyCompositeBlit.Blit() or 
OGLGeneralBlit.Blit()).

Bug: https://bugs.openjdk.java.net/browse/JDK-8041644
Webrev can be found at: http://cr.openjdk.java.net/~serb/8041644/webrev.00

-- 
Best regards, Sergey.



From staffan.larsen at oracle.com  Tue May 20 13:55:00 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 20 May 2014 15:55:00 +0200
Subject: [OpenJDK 2D-Dev] <AWT Dev> Request for review: 8026385:
	[macosx] (awt) setjmp/longjmp changes the process signal mask
	on OS X
In-Reply-To: <CA+3eh136Hc2k=DXnwHAv5M=Ysd=ntV4_450qNnDy+bBCN1N=RA@mail.gmail.com>
References: <C6AFC617-0DEE-4892-BDA1-AC7B3809FE49@oracle.com>
	<5372798B.1050103@oracle.com>
	<5A6B42D6-FCDC-4968-8D4C-F1CC777866F7@oracle.com>
	<53728153.3070002@oracle.com>
	<3E22C8BF-3F49-46F1-9565-45240DE28902@oracle.com>
	<EE677AB2-7CDE-4800-9AAB-C14A29CC4B3B@oracle.com>
	<4B720DD6-DF4F-4F00-979E-E02DC0FD70E2@oracle.com>
	<5374FB74.9040801@oracle.com>
	<504FD4A5-0921-4C49-87BA-64DF4D905F5D@oracle.com>
	<53762F1A.5030604@oracle.com>
	<877C69C9-8643-4BA5-87B0-6A0259BD9FBB@oracle.com>
	<CA+3eh10UNDG=+kieCZYrFapJU7d7rbQ7n+xxjJP_Tryi29gaFQ@mail.gmail.com>
	<A34B6713-5C40-42C2-9DF4-0CB695AF8D8F@oracle.com>
	<CA+3eh136Hc2k=DXnwHAv5M=Ysd=ntV4_450qNnDy+bBCN1N=RA@mail.gmail.com>
Message-ID: <DBB2C7E5-57A8-436E-A8E3-3BF805FB7F1A@oracle.com>


On 20 maj 2014, at 10:34, Volker Simonis <volker.simonis at gmail.com> wrote:

> Hi everybody,
> 
> I've analyzed this issue on AIX (and HPUX) and came to the conclusion
> that it is not a problem on these platforms.
> 
> Just to make sure I got everything right, I'll summarize my
> understanding of the problem here:
> 
> On MacOS, setjmp() saves the signal mask of the current thread BUT
> restores the signal mask of the whole process after the corresponding
> longjmp(). This obviously changes the signal mask of all threads which
> had a different signal mask than the initial thread who called
> setjmp(). I could easily reproduce this by loading a class which
> provokes a verification exception in the un-fixed libverify.so.
> Afterwards, the VM-thread won't listen to SIGQUIT anymore because it
> now masks this signal in the same way like the Java thread which had
> the verification exception.
> 
> On AIX/HPUX setjmp()/longjmp() is defined in the same way like on
> MacOS in that it saves and restores the signal mask (and both
> platforms provide _setjmp()/_longjmp() versions as well which do not
> manipulate the signal mask). But while it is not clear from the
> documentation, all my tests showed that longjmp() only restores the
> signal mask of the current thread, which should be OK (i.e. I couldn't
> see a blocked VM thread which doesn't react on SIQUIT anymore).
> 
> So to cut a long story short - no action seems to be required to fix
> this issue on AIX:
> 
> As a side note I wonder why we didn't use sigsetjmp()/siglongjmp()
> with a zero 'savemask' argument to fix this problem? It is
> standardized by POSIX and would avoid the usage of "#ifdef __APPLE?.

It?s not clear to me if sigsetjmp()/siglongjmp() sets the signal mask on the process or on the pthread. The problem on OS X was that the VM sets up the sigprocmask on the pthreads (using pthread_sigmask()), but longjmp() restores the mask for the process (using sigprocmask()).


/Staffan


> 
> Thank you and best regards,
> Volker
> 
> 
> On Fri, May 16, 2014 at 6:04 PM, David DeHaven <david.dehaven at oracle.com> wrote:
>> 
>> I'd thought about that, since Apple borrowed most of it's underpinnings from BSD, but had no evidence to suggest it was necessary.
>> 
>> Anyways, at least you've identified and can rectify the issue :)
>> 
>> -DrD-
>> 
>>> Wow, sometimes it really makes sense to read apparently unrelated
>>> email-threads on Friday afternoon:)
>>> 
>>> It seems that AIX/HPUX have exactly the same problem like MacOS X.
>>> From the AIX setjmp man-page:
>>> 
>>> "The setjmp and longjmp subroutines save and restore the signal mask
>>> sigmask (2), while _setjmp and _longjmp manipulate only the stack
>>> context."
>>> 
>>> From the HPUXM setjmp man-page:
>>> 
>>> "setjmp(), longjmp()         These always save and restore the signal mask.
>>> _setjmp(), _longjmp()        These never manipulate the signal mask."
>>> 
>>> I think it doesn't make sense for you to wait pushing this until I
>>> provide the corresponding AIX patches because anyway I'll have to
>>> provide a fix not only for this issue but also for the other bugs you
>>> mentioned (i.e. 8023786 and 8023720). So I'll better create a new bug
>>> for AIX.
>>> 
>>> Thank you and best regards,
>>> Volker
>>> 
>>> On Fri, May 16, 2014 at 5:38 PM, David DeHaven <david.dehaven at oracle.com> wrote:
>>>> 
>>>> Thanks!
>>>> 
>>>> -DrD-
>>>> 
>>>>> The splashscreen changes look fine to me. Approved.
>>>>> 
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>> 
>>>>> On 5/16/2014 7:18 PM, David DeHaven wrote:
>>>>>> 
>>>>>> Could someone on AWT team approve the splashscreen changes?
>>>>>> 
>>>>>> -DrD-
>>>>>> 
>>>>>>> Approved.
>>>>>>> 
>>>>>>> -phil.
>>>>>>> 
>>>>>>> On 5/15/2014 9:31 AM, David DeHaven wrote:
>>>>>>>> Ping!
>>>>>>>> 
>>>>>>>> Does this look OK?
>>>>>>>> 
>>>>>>>> I've also filed an issue against JavaFX:
>>>>>>>> https://javafx-jira.kenai.com/browse/RT-37125
>>>>>>>> 
>>>>>>>> -DrD-
>>>>>>>> 
>>>>>>>>>>>> I tried not modifying libpng but still ended up with lingering references to longjmp in pngread.o, despite libpng having png_ptr->longjmp_fn (bug in libpng?). pngread.c calls setjmp to set a default location to jump to in case the caller doesn't call setjmp, so if we continue down this path something in libpng must be modified. The only other option is to create our own setjmp.h and order it before /usr/include/setjmp.h, which seems dubious at best.
>>>>>>>>>>>> 
>>>>>>>>>>>> I'm curious if the libpng changes are even needed since it's only used for splashscreen, which happens very early in the launch process. Also note that we didn't originally even call png_set_longjmp_fn, so any error should have resulted in an abort() instead of a call to longjmp... it appears we could retain the functionality we have today and #undef PNG_SETJMP_SUPPORTED (pngconf.h?). That would put the onus on developers to make sure their pngs don't have errors in them, or libsplashscreen will abort()...
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> That's an interesting question and the answer might extend to the splashscreen changes too.
>>>>>>>>>>> Its platform specific code and on MAC, the thread is created using pthreads directly and that
>>>>>>>>>>> thread goes away once splashscreen is done. But its running at the same time as the VM
>>>>>>>>>>> is booting up and creating threads and setting their signal masks. So I don't think you can
>>>>>>>>>>> guarantee that it won't mess up the masks on the JRE threads if the PNG is bad. And I'm
>>>>>>>>>>> also not sure you want to remove error handling from the library either.
>>>>>>>>>>> So a HIGHLY VISIBLE DO NOT REMOVE comment might be the best you can do here.
>>>>>>>>>> I have a better idea:
>>>>>>>>>> 
>>>>>>>>>> png_default_error is the only place where png_longjmp is called. We could call png_set_error_fn to set up our own error handler (for Mac only), compile with PNG_SETJMP_SUPPORTED unset so it doesn't pull in setjmp/longjmp and our own implementation of the error handler would call _longjmp, which would jump back to where we call setjmp currently.
>>>>>>>>> Ok, I figured out what's going on. It's not quite intuitive...
>>>>>>>>> 
>>>>>>>>> png_jmpbuf is a macro defined in png.h, this calls png_set_longjmp_fn with longjmp, which is why I was seeing references to longjmp in the object file. That's what was throwing me off as it seems like it should only be getting the jmp_buf ptr stored in the png_ptr. I guess the intention was that setjmp/longjmp was optional, if you don't call setjmp then it just abort()s.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I changed splashscreen_png.c to:
>>>>>>>>> #ifdef __APPLE__
>>>>>>>>>  if (_setjmp(png_set_longjmp_fn(png_ptr, _longjmp, sizeof(jmp_buf)))) {
>>>>>>>>> #else
>>>>>>>>>  if (setjmp(png_jmpbuf(png_ptr))) {
>>>>>>>>> #endif
>>>>>>>>> 
>>>>>>>>> and it calls _longjmp instead. I verified this works by changing the macro to set png_longjmp to exit() and without the above change it does indeed exit prematurely with a bad png, with the change it reports the error but continues to load the application as would be expected.
>>>>>>>>> 
>>>>>>>>> pngread.o still has a symbol table entry for _longjmp instead of __longjmp, but it's benign since we're ultimately forcing it to use the correct function. So I've left libpng completely unchanged.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> With the change and using a bad png for splashscreen, I was able to get a stack trace once the application was running. Without the change to splashscreen_png.c, jstack was unable to connect to the process. So splashscreen absolutely can interfere with the signal handling.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Updated webrev:
>>>>>>>>> http://cr.openjdk.java.net/~ddehaven/8026385/jdk.1/
>>>>>>>>> 
>>>>>>>>> I can look into writing a regression test for this. It might not be trivial though since we're dealing with signal handlers, and if timing is a factor the test may not be reliable.
>>>>>>>>> 
>>>>>>>>> -DrD-
>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 



From philip.race at oracle.com  Tue May 20 16:52:34 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 20 May 2014 09:52:34 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8041644 [OGL] clip is
 ignored during surface->sw blit
In-Reply-To: <537B8605.9010204@oracle.com>
References: <537B8605.9010204@oracle.com>
Message-ID: <537B8852.90407@oracle.com>

So my first question here was. So what does D3D do ? We should just copy 
that code.
Then I read the bug report and it says D3D has the same bug
I don't get why you'd fix it for OGL but not for D3D which seems like the
way more important case.
So when you check this in we'll just get one more failing regression test.

-phil.


On 5/20/2014 9:42 AM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 9, which is also targeted for jdk 8u20.
> Description:
>     Our implementation of opengl surface-> sw blit does not take into 
> account the clipped area.
> Suggested fix:
>    I intersect a clip and a coordinates of destination, and if the 
> resulted region is rectangle I use the usual blit, but if the region 
> is complex I use intermediate buffer(like OGLAnyCompositeBlit.Blit() 
> or OGLGeneralBlit.Blit()).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8041644
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8041644/webrev.00
>



From Sergey.Bylokhov at oracle.com  Tue May 20 17:03:37 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 20 May 2014 21:03:37 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8041644 [OGL] clip is
 ignored during surface->sw blit
In-Reply-To: <537B8852.90407@oracle.com>
References: <537B8605.9010204@oracle.com> <537B8852.90407@oracle.com>
Message-ID: <537B8AE9.4010105@oracle.com>

On 5/20/14 8:52 PM, Phil Race wrote:
> So my first question here was. So what does D3D do ? We should just 
> copy that code.
D3D doesn't work as well.
> Then I read the bug report and it says D3D has the same bug
> I don't get why you'd fix it for OGL but not for D3D which seems like the
> way more important case.
OGL is important too, because it is default pipeline on osx. I plan to 
fix D3D case later.
Actually I am not familiar with d3d code and right now I focused on 
hidpi support in SwingNode on OSX.
> So when you check this in we'll just get one more failing regression 
> test.
Yes. It will be bound to the separate CR.
>
> -phil.
>
>
> On 5/20/2014 9:42 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk 9, which is also targeted for jdk 8u20.
>> Description:
>>     Our implementation of opengl surface-> sw blit does not take into 
>> account the clipped area.
>> Suggested fix:
>>    I intersect a clip and a coordinates of destination, and if the 
>> resulted region is rectangle I use the usual blit, but if the region 
>> is complex I use intermediate buffer(like OGLAnyCompositeBlit.Blit() 
>> or OGLGeneralBlit.Blit()).
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041644
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8041644/webrev.00
>>
>


-- 
Best regards, Sergey.



From omajid at redhat.com  Tue May 20 17:11:20 2014
From: omajid at redhat.com (Omair Majid)
Date: Tue, 20 May 2014 13:11:20 -0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: Allow using the system libjpeg
In-Reply-To: <537A509E.2090504@oracle.com>
References: <20140517004529.GD4370@redhat.com>
 <537A509E.2090504@oracle.com>
Message-ID: <20140520171120.GD2672@redhat.com>

Hi,

Updated webrevs:
http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01/
http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01.jdk/

* Anthony Petrov <anthony.petrov at oracle.com> [2014-05-19 14:42]:
> make/lib/Awt2dLibraries.gmk
> >1236     LIBJPEG_CFLAGS := $(JDK_TOPDIR)/src/share/native/sun/awt/image/jpeg
> 
> Since these are compiler flags, I suppose this should read "-I<path>", not
> just "<path>".

Yes, it should. I wonder how my compiler accepted that.

> Did you build with --with-jpeg=bundled ? Can the resulting JDK read jpeg
> files?

I did. I tested both combinations and made sure both the splash screen
and javax.swing.ImageIcon could display jpegs files with the first
webrev I posted.

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681


From anthony.petrov at oracle.com  Tue May 20 17:15:11 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 20 May 2014 21:15:11 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: Allow using the system libjpeg
In-Reply-To: <20140520171120.GD2672@redhat.com>
References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com>
	<20140520171120.GD2672@redhat.com>
Message-ID: <537B8D9F.5000007@oracle.com>

Thanks for the update, Omair. The fix looks good to me now.

--
best regards,
Anthony

On 5/20/2014 9:11 PM, Omair Majid wrote:
> Hi,
>
> Updated webrevs:
> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01/
> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01.jdk/
>
> * Anthony Petrov <anthony.petrov at oracle.com> [2014-05-19 14:42]:
>> make/lib/Awt2dLibraries.gmk
>>> 1236     LIBJPEG_CFLAGS := $(JDK_TOPDIR)/src/share/native/sun/awt/image/jpeg
>>
>> Since these are compiler flags, I suppose this should read "-I<path>", not
>> just "<path>".
>
> Yes, it should. I wonder how my compiler accepted that.
>
>> Did you build with --with-jpeg=bundled ? Can the resulting JDK read jpeg
>> files?
>
> I did. I tested both combinations and made sure both the splash screen
> and javax.swing.ImageIcon could display jpegs files with the first
> webrev I posted.
>
> Thanks,
> Omair
>


From philip.race at oracle.com  Tue May 20 17:17:41 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 20 May 2014 10:17:41 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8041644 [OGL] clip is
 ignored during surface->sw blit
In-Reply-To: <537B8AE9.4010105@oracle.com>
References: <537B8605.9010204@oracle.com> <537B8852.90407@oracle.com>
	<537B8AE9.4010105@oracle.com>
Message-ID: <537B8E35.30108@oracle.com>

On 5/20/2014 10:03 AM, Sergey Bylokhov wrote:
> On 5/20/14 8:52 PM, Phil Race wrote:
>> So my first question here was. So what does D3D do ? We should just 
>> copy that code.
> D3D doesn't work as well.
>> Then I read the bug report and it says D3D has the same bug
>> I don't get why you'd fix it for OGL but not for D3D which seems like 
>> the
>> way more important case.
> OGL is important too, because it is default pipeline on osx. I plan to 
> fix D3D case later.

And D3D is the default pipeline on Windows !  I submit that there are 
(many) more people
world-wide using that than OS X.

> Actually I am not familiar with d3d code and right now I focused on 
> hidpi support in SwingNode on OSX.
>> So when you check this in we'll just get one more failing regression 
>> test.
> Yes. It will be bound to the separate CR.

At a minimum the test should only run on OS X or should specify 
-Dsun.java2d.d3d=false
until Windows is resolved.

But I really think this should all be checked in as one fix.


-phil.

>>
>> -phil.
>>
>>
>> On 5/20/2014 9:42 AM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk 9, which is also targeted for jdk 8u20.
>>> Description:
>>>     Our implementation of opengl surface-> sw blit does not take 
>>> into account the clipped area.
>>> Suggested fix:
>>>    I intersect a clip and a coordinates of destination, and if the 
>>> resulted region is rectangle I use the usual blit, but if the region 
>>> is complex I use intermediate buffer(like OGLAnyCompositeBlit.Blit() 
>>> or OGLGeneralBlit.Blit()).
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041644
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8041644/webrev.00
>>>
>>
>
>



From philip.race at oracle.com  Tue May 20 17:18:44 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 20 May 2014 10:18:44 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: Allow using the system libjpeg
In-Reply-To: <537B8D9F.5000007@oracle.com>
References: <20140517004529.GD4370@redhat.com>
	<537A509E.2090504@oracle.com>	<20140520171120.GD2672@redhat.com>
	<537B8D9F.5000007@oracle.com>
Message-ID: <537B8E74.9050306@oracle.com>

I'm going to apply the patch and run it through open + closed builds 
cross-platforms ..

-phil..

On 5/20/2014 10:15 AM, Anthony Petrov wrote:
> Thanks for the update, Omair. The fix looks good to me now.
>
> -- 
> best regards,
> Anthony
>
> On 5/20/2014 9:11 PM, Omair Majid wrote:
>> Hi,
>>
>> Updated webrevs:
>> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01/
>> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01.jdk/
>>
>> * Anthony Petrov <anthony.petrov at oracle.com> [2014-05-19 14:42]:
>>> make/lib/Awt2dLibraries.gmk
>>>> 1236     LIBJPEG_CFLAGS := 
>>>> $(JDK_TOPDIR)/src/share/native/sun/awt/image/jpeg
>>>
>>> Since these are compiler flags, I suppose this should read 
>>> "-I<path>", not
>>> just "<path>".
>>
>> Yes, it should. I wonder how my compiler accepted that.
>>
>>> Did you build with --with-jpeg=bundled ? Can the resulting JDK read 
>>> jpeg
>>> files?
>>
>> I did. I tested both combinations and made sure both the splash screen
>> and javax.swing.ImageIcon could display jpegs files with the first
>> webrev I posted.
>>
>> Thanks,
>> Omair
>>



From Sergey.Bylokhov at oracle.com  Tue May 20 17:31:29 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 20 May 2014 21:31:29 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8041644 [OGL] clip is
 ignored during surface->sw blit
In-Reply-To: <537B8E35.30108@oracle.com>
References: <537B8605.9010204@oracle.com> <537B8852.90407@oracle.com>
	<537B8AE9.4010105@oracle.com> <537B8E35.30108@oracle.com>
Message-ID: <537B9171.6000806@oracle.com>

On 5/20/14 9:17 PM, Phil Race wrote:
> On 5/20/2014 10:03 AM, Sergey Bylokhov wrote:
>> On 5/20/14 8:52 PM, Phil Race wrote:
>>> So my first question here was. So what does D3D do ? We should just 
>>> copy that code.
>> D3D doesn't work as well.
>>> Then I read the bug report and it says D3D has the same bug
>>> I don't get why you'd fix it for OGL but not for D3D which seems 
>>> like the
>>> way more important case.
>> OGL is important too, because it is default pipeline on osx. I plan 
>> to fix D3D case later.
>
> And D3D is the default pipeline on Windows !  I submit that there are 
> (many) more people
> world-wide using that than OS X.
I agree but right now I have no tested version of the fix for d3d.
>
>> Actually I am not familiar with d3d code and right now I focused on 
>> hidpi support in SwingNode on OSX.
>>> So when you check this in we'll just get one more failing regression 
>>> test.
>> Yes. It will be bound to the separate CR.
>
> At a minimum the test should only run on OS X or should specify 
> -Dsun.java2d.d3d=false
> until Windows is resolved.
Ok. I will add this option to the test before the push.
>
> But I really think this should all be checked in as one fix.
>
>
> -phil.
>
>>>
>>> -phil.
>>>
>>>
>>> On 5/20/2014 9:42 AM, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review the fix for jdk 9, which is also targeted for jdk 8u20.
>>>> Description:
>>>>     Our implementation of opengl surface-> sw blit does not take 
>>>> into account the clipped area.
>>>> Suggested fix:
>>>>    I intersect a clip and a coordinates of destination, and if the 
>>>> resulted region is rectangle I use the usual blit, but if the 
>>>> region is complex I use intermediate buffer(like 
>>>> OGLAnyCompositeBlit.Blit() or OGLGeneralBlit.Blit()).
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041644
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/8041644/webrev.00
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.



From philip.race at oracle.com  Tue May 20 22:33:40 2014
From: philip.race at oracle.com (Phil Race)
Date: Tue, 20 May 2014 15:33:40 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: Allow using the system libjpeg
In-Reply-To: <537B8E74.9050306@oracle.com>
References: <20140517004529.GD4370@redhat.com>
	<537A509E.2090504@oracle.com>	<20140520171120.GD2672@redhat.com>
	<537B8D9F.5000007@oracle.com> <537B8E74.9050306@oracle.com>
Message-ID: <537BD844.7060109@oracle.com>

I only tried the default (not specifying the system libjpeg) but my builds
all succeeded and SwingSet & Java2D demo ran fine on Mac & Windows
with the closed builds (after generating a closed generated-configure.sh)
so this all looks good to push.

I will need to push that closed generated-configure.sh afterwards however
so that closed builds don't break.

-phil.

On 05/20/2014 10:18 AM, Phil Race wrote:
> I'm going to apply the patch and run it through open + closed builds 
> cross-platforms ..
>
> -phil..
>
> On 5/20/2014 10:15 AM, Anthony Petrov wrote:
>> Thanks for the update, Omair. The fix looks good to me now.
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 5/20/2014 9:11 PM, Omair Majid wrote:
>>> Hi,
>>>
>>> Updated webrevs:
>>> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01/
>>> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01.jdk/
>>>
>>> * Anthony Petrov <anthony.petrov at oracle.com> [2014-05-19 14:42]:
>>>> make/lib/Awt2dLibraries.gmk
>>>>> 1236     LIBJPEG_CFLAGS := 
>>>>> $(JDK_TOPDIR)/src/share/native/sun/awt/image/jpeg
>>>>
>>>> Since these are compiler flags, I suppose this should read 
>>>> "-I<path>", not
>>>> just "<path>".
>>>
>>> Yes, it should. I wonder how my compiler accepted that.
>>>
>>>> Did you build with --with-jpeg=bundled ? Can the resulting JDK read 
>>>> jpeg
>>>> files?
>>>
>>> I did. I tested both combinations and made sure both the splash screen
>>> and javax.swing.ImageIcon could display jpegs files with the first
>>> webrev I posted.
>>>
>>> Thanks,
>>> Omair
>>>
>



From omajid at redhat.com  Wed May 21 15:06:04 2014
From: omajid at redhat.com (Omair Majid)
Date: Wed, 21 May 2014 11:06:04 -0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: Allow using the system libjpeg
In-Reply-To: <537BD844.7060109@oracle.com>
References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com>
	<20140520171120.GD2672@redhat.com> <537B8D9F.5000007@oracle.com>
	<537B8E74.9050306@oracle.com> <537BD844.7060109@oracle.com>
Message-ID: <20140521150604.GB3957@redhat.com>

Hi,

* Phil Race <philip.race at oracle.com> [2014-05-20 18:34]:
> I only tried the default (not specifying the system libjpeg) but my builds
> all succeeded and SwingSet & Java2D demo ran fine on Mac & Windows
> with the closed builds (after generating a closed generated-configure.sh)
> so this all looks good to push.

Thanks for testing!

> I will need to push that closed generated-configure.sh afterwards however
> so that closed builds don't break.

Anything I need to do to ensure the pushes are co-ordinated correctly?

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681


From Sergey.Bylokhov at oracle.com  Wed May 21 15:46:31 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 21 May 2014 19:46:31 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <53725695.40209@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A7A319.80001@oracle.com>
	<52A82DE8.4070707@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com>
	<52B0F447.2020207@oracle.com> <52DE761E.2000201@oracle.com>
	<52E192F0.7010107@oracle.com> <52E27CDA.40703@oracle.com>
	<52E31866.3010508@oracle.com> <52E7CE5B.4070101@oracle.com>
	<52EAD304.2090809@oracle.com> <52EBB516.70906@oracle.com>
	<52EC4F5E.7060906@oracle.com> <52EFA980.6000404@oracle.com>
	<52F580C1.3020906@oracle.com> <52F8DE2A.4080304@oracle.com>
	<52F962CD.2050301@oracle.com> <52F96AE2.10106@oracle.com>
	<52FA67A8.1010600@oracle.com> <52FA7DCD.80405@oracle.com>
	<52FCC28D.5010007@oracle.com> <52FD4CB6.2090805@oracle.com>
	<52FDC1D1.8050907@oracle.com> <52FEBC4E.9010202@oracle.com>
	<5302182D.3070600@oracle.com> <53068600.80501@oracle.com>
	<53725695.40209@oracle.com>
Message-ID: <537CCA57.4050200@oracle.com>

Hello, Everybody.
Please review an updated version of this fix. This is a minimum possible 
fix. changes in shared code of jdk are minimized and can be enhanced in 
the future.
The fix is covering hdpi support in SwingNode on osx + system look and 
feel(Aqua).

http://cr.openjdk.java.net/~serb/8029455/webrev.01

Notes:
  - This fix depends from two other fixes: JDK- 8041129 and JDK-8041644. 
Both are under review on 2d alias.

On 5/13/14 9:29 PM, Anthony Petrov wrote:
> Hi Jim, Sergey, and Anton,
>
> I'd like to revive this old thread and finally push this fix, which 
> has been reviewed and approved on this mailing list back in February. 
> The only additional change that I want to introduce, is the addition 
> of default implementations for the 
> LightweightContent.imageBufferReset() methods. This allows clients of 
> the API (namely, JavaFX) to run with both the old and the new JDK w/o 
> any changes or side-effects. Here's the updated webrev:
>
> http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/
>
> It literally only adds the default methods and doesn't make any other 
> changes to the rest of the already reviewed code. I've tested this on 
> both hiDPI and loDPI displays, with both old and hiDPI-aware JavaFX 
> builds, and it works fine in all the cases.
>
> The current plan is to push this fix to JDK 9, and then back-port the 
> changes to 8u20.
>
> -- 
> best regards,
> Anthony
>
> On 2/21/2014 2:47 AM, Jim Graham wrote:
>> Yes, approved.
>>
>>          ...jim
>>
>> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>>> Jim, so this is ready for a push then.
>>>
>>> Thanks!
>>> Anton.
>>>
>>> On 15.02.2014 5:01, Jim Graham wrote:
>>>> I don't need to see an update for that.  I didn't read the entire
>>>> webrev, but I looked at this one piece of code and if that was the
>>>> only thing changed then I think that dealt with the outstanding
>>>> issues...
>>>>
>>>>         ...jim
>>>>
>>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>>
>>>>>>
>>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>>> Hi Jim,
>>>>>>>
>>>>>>> Please, look at the update:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
>>>>>>>
>>>>>>> Here I'm correcting the rect after the transform in SG2D:
>>>>>>>
>>>>>>> 2123         // In case of negative scale transform, reflect the 
>>>>>>> rect
>>>>>>> coords.
>>>>>>> 2124         if (w < 0) {
>>>>>>> 2125             w *= -1;
>>>>>>> 2126             x -= w;
>>>>>>> 2127         }
>>>>>>> 2128         if (h < 0) {
>>>>>>> 2129             h *= -1;
>>>>>>> 2130             y -= h;
>>>>>>> 2131         }
>>>>>>>
>>>>>>>
>>>>>>> The blit direction (dx, dy) remains transformed. Is this the right
>>>>>>> behavior from your perspective?
>>>>>>
>>>>>> Yes, that looks good.  I wonder if the "w *= -1" results in a 
>>>>>> multiply
>>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>>
>>>>>>             ...jim
>>>>>
>>>>> Jim,
>>>>>
>>>>> Yes, this indeed results in different byte code instructions (imult &
>>>>> ineg). Just for curiosity I did some measuring which showed
>>>>> negatioation
>>>>> worked 10% faster :)
>>>>> Well, I'll fix it but let me please not send an update...
>>>>>
>>>>> Thanks!
>>>>> Anton.
>>>>>
>>>


-- 
Best regards, Sergey.



From gnu.andrew at redhat.com  Wed May 21 16:21:39 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 21 May 2014 12:21:39 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: Allow using the system libjpeg
In-Reply-To: <20140520171120.GD2672@redhat.com>
References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com>
	<20140520171120.GD2672@redhat.com>
Message-ID: <113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com>

----- Original Message -----
> Hi,
> 
> Updated webrevs:
> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01/
> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01.jdk/
> 
> * Anthony Petrov <anthony.petrov at oracle.com> [2014-05-19 14:42]:
> > make/lib/Awt2dLibraries.gmk
> > >1236     LIBJPEG_CFLAGS :=
> > >$(JDK_TOPDIR)/src/share/native/sun/awt/image/jpeg
> > 
> > Since these are compiler flags, I suppose this should read "-I<path>", not
> > just "<path>".
> 
> Yes, it should. I wonder how my compiler accepted that.
> 
> > Did you build with --with-jpeg=bundled ? Can the resulting JDK read jpeg
> > files?
> 
> I did. I tested both combinations and made sure both the splash screen
> and javax.swing.ImageIcon could display jpegs files with the first
> webrev I posted.
> 
> Thanks,
> Omair
> 
> --
> PGP Key: 66484681 (http://pgp.mit.edu/)
> Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
> 

I'm not keen on the hardcoding of '-ljpeg'

+  LIBJPEG_LIBS := -ljpeg

Could this not at least be conditionally assigned? (?=)
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From anthony.petrov at oracle.com  Wed May 21 18:13:08 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 21 May 2014 22:13:08 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <537CCA57.4050200@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A82DE8.4070707@oracle.com>
	<52A840AE.2010000@oracle.com> <52A9D341.2070008@oracle.com>
	<52AA0C32.504@oracle.com> <52AA0E11.3060706@oracle.com>
	<52AA39A2.4060503@oracle.com> <52AA3E92.7040302@oracle.com>
	<52B09644.6050201@oracle.com> <52B0F447.2020207@oracle.com>
	<52DE761E.2000201@oracle.com> <52E192F0.7010107@oracle.com>
	<52E27CDA.40703@oracle.com> <52E31866.3010508@oracle.com>
	<52E7CE5B.4070101@oracle.com> <52EAD304.2090809@oracle.com>
	<52EBB516.70906@oracle.com> <52EC4F5E.7060906@oracle.com>
	<52EFA980.6000404@oracle.com> <52F580C1.3020906@oracle.com>
	<52F8DE2A.4080304@oracle.com> <52F962CD.2050301@oracle.com>
	<52F96AE2.10106@oracle.com> <52FA67A8.1010600@oracle.com>
	<52FA7DCD.80405@oracle.com> <52FCC28D.5010007@oracle.com>
	<52FD4CB6.2090805@oracle.com> <52FDC1D1.8050907@oracle.com>
	<52FEBC4E.9010202@oracle.com> <5302182D.3070600@oracle.com>
	<53068600.80501@oracle.com> <53725695.40209@oracle.com>
	<537CCA57.4050200@oracle.com>
Message-ID: <537CECB4.7080706@oracle.com>

Hi Sergey,

The original fix provides some updates and clarifications to the javadoc 
for the LightweightContent.imageBufferReset() method, but they are 
missing from your fix. Is this intentional?

BTW, I've applied your fix and tested it with the latest version of FX 
changes, and everything works smoothly on my Mac, including the display 
change listener.

--
best regards,
Anthony

On 5/21/2014 7:46 PM, Sergey Bylokhov wrote:
> Hello, Everybody.
> Please review an updated version of this fix. This is a minimum possible
> fix. changes in shared code of jdk are minimized and can be enhanced in
> the future.
> The fix is covering hdpi support in SwingNode on osx + system look and
> feel(Aqua).
>
> http://cr.openjdk.java.net/~serb/8029455/webrev.01
>
> Notes:
>   - This fix depends from two other fixes: JDK- 8041129 and JDK-8041644.
> Both are under review on 2d alias.
>
> On 5/13/14 9:29 PM, Anthony Petrov wrote:
>> Hi Jim, Sergey, and Anton,
>>
>> I'd like to revive this old thread and finally push this fix, which
>> has been reviewed and approved on this mailing list back in February.
>> The only additional change that I want to introduce, is the addition
>> of default implementations for the
>> LightweightContent.imageBufferReset() methods. This allows clients of
>> the API (namely, JavaFX) to run with both the old and the new JDK w/o
>> any changes or side-effects. Here's the updated webrev:
>>
>> http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/
>>
>> It literally only adds the default methods and doesn't make any other
>> changes to the rest of the already reviewed code. I've tested this on
>> both hiDPI and loDPI displays, with both old and hiDPI-aware JavaFX
>> builds, and it works fine in all the cases.
>>
>> The current plan is to push this fix to JDK 9, and then back-port the
>> changes to 8u20.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 2/21/2014 2:47 AM, Jim Graham wrote:
>>> Yes, approved.
>>>
>>>          ...jim
>>>
>>> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>>>> Jim, so this is ready for a push then.
>>>>
>>>> Thanks!
>>>> Anton.
>>>>
>>>> On 15.02.2014 5:01, Jim Graham wrote:
>>>>> I don't need to see an update for that.  I didn't read the entire
>>>>> webrev, but I looked at this one piece of code and if that was the
>>>>> only thing changed then I think that dealt with the outstanding
>>>>> issues...
>>>>>
>>>>>         ...jim
>>>>>
>>>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>>>> Hi Jim,
>>>>>>>>
>>>>>>>> Please, look at the update:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
>>>>>>>>
>>>>>>>> Here I'm correcting the rect after the transform in SG2D:
>>>>>>>>
>>>>>>>> 2123         // In case of negative scale transform, reflect the
>>>>>>>> rect
>>>>>>>> coords.
>>>>>>>> 2124         if (w < 0) {
>>>>>>>> 2125             w *= -1;
>>>>>>>> 2126             x -= w;
>>>>>>>> 2127         }
>>>>>>>> 2128         if (h < 0) {
>>>>>>>> 2129             h *= -1;
>>>>>>>> 2130             y -= h;
>>>>>>>> 2131         }
>>>>>>>>
>>>>>>>>
>>>>>>>> The blit direction (dx, dy) remains transformed. Is this the right
>>>>>>>> behavior from your perspective?
>>>>>>>
>>>>>>> Yes, that looks good.  I wonder if the "w *= -1" results in a
>>>>>>> multiply
>>>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>>>
>>>>>>>             ...jim
>>>>>>
>>>>>> Jim,
>>>>>>
>>>>>> Yes, this indeed results in different byte code instructions (imult &
>>>>>> ineg). Just for curiosity I did some measuring which showed
>>>>>> negatioation
>>>>>> worked 10% faster :)
>>>>>> Well, I'll fix it but let me please not send an update...
>>>>>>
>>>>>> Thanks!
>>>>>> Anton.
>>>>>>
>>>>
>
>


From philip.race at oracle.com  Wed May 21 18:29:17 2014
From: philip.race at oracle.com (Phil Race)
Date: Wed, 21 May 2014 11:29:17 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: Allow using the system libjpeg
In-Reply-To: <20140521150604.GB3957@redhat.com>
References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com>
	<20140520171120.GD2672@redhat.com>
	<537B8D9F.5000007@oracle.com> <537B8E74.9050306@oracle.com>
	<537BD844.7060109@oracle.com> <20140521150604.GB3957@redhat.com>
Message-ID: <537CF07D.6050801@oracle.com>

On 05/21/2014 08:06 AM, Omair Majid wrote:
>
> I will need to push that closed generated-configure.sh afterwards however
> so that closed builds don't break.
> Anything I need to do to ensure the pushes are co-ordinated correctly?

Just make sure I notice the push and I'll fix ASAP ..

-phil.



From omajid at redhat.com  Wed May 21 20:59:35 2014
From: omajid at redhat.com (Omair Majid)
Date: Wed, 21 May 2014 16:59:35 -0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: Allow using the system libjpeg
In-Reply-To: <113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com>
References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com>
	<20140520171120.GD2672@redhat.com>
	<113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com>
Message-ID: <20140521205934.GE3957@redhat.com>

* Andrew Hughes <gnu.andrew at redhat.com> [2014-05-21 12:22]:
> I'm not keen on the hardcoding of '-ljpeg'
> 
> +  LIBJPEG_LIBS := -ljpeg

There's no pkg-config files for it. Any suggestions on how to get
something generic?

> Could this not at least be conditionally assigned? (?=)

It can still be overridden on the make command line:

make LIBJPEG_LIBS=foo

Is this not sufficient?

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681


From Sergey.Bylokhov at oracle.com  Wed May 21 21:44:28 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 22 May 2014 01:44:28 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <537CECB4.7080706@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A840AE.2010000@oracle.com>
	<52A9D341.2070008@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com>
	<52B0F447.2020207@oracle.com> <52DE761E.2000201@oracle.com>
	<52E192F0.7010107@oracle.com> <52E27CDA.40703@oracle.com>
	<52E31866.3010508@oracle.com> <52E7CE5B.4070101@oracle.com>
	<52EAD304.2090809@oracle.com> <52EBB516.70906@oracle.com>
	<52EC4F5E.7060906@oracle.com> <52EFA980.6000404@oracle.com>
	<52F580C1.3020906@oracle.com> <52F8DE2A.4080304@oracle.com>
	<52F962CD.2050301@oracle.com> <52F96AE2.10106@oracle.com>
	<52FA67A8.1010600@oracle.com> <52FA7DCD.80405@oracle.com>
	<52FCC28D.5010007@oracle.com> <52FD4CB6.2090805@oracle.com>
	<52FDC1D1.8050907@oracle.com> <52FEBC4E.9010202@oracle.com>
	<5302182D.3070600@oracle.com> <53068600.80501@oracle.com>
	<53725695.40209@oracle.com> <537CCA57.4050200@oracle.com>
	<537CECB4.7080706@oracle.com>
Message-ID: <537D1E3C.9090309@oracle.com>

On 5/21/14 10:13 PM, Anthony Petrov wrote:
> Hi Sergey,
>
> The original fix provides some updates and clarifications to the 
> javadoc for the LightweightContent.imageBufferReset() method, but they 
> are missing from your fix. Is this intentional?
Nope. I just missed this update. I looked at this method closely and got 
a question: do we need this scale parameter? Why we cannot use w,h + 
scanstride here an skip all clarification about logical coordinates?
>
> BTW, I've applied your fix and tested it with the latest version of FX 
> changes, and everything works smoothly on my Mac, including the 
> display change listener.
>
> -- 
> best regards,
> Anthony
>
> On 5/21/2014 7:46 PM, Sergey Bylokhov wrote:
>> Hello, Everybody.
>> Please review an updated version of this fix. This is a minimum possible
>> fix. changes in shared code of jdk are minimized and can be enhanced in
>> the future.
>> The fix is covering hdpi support in SwingNode on osx + system look and
>> feel(Aqua).
>>
>> http://cr.openjdk.java.net/~serb/8029455/webrev.01
>>
>> Notes:
>>   - This fix depends from two other fixes: JDK- 8041129 and JDK-8041644.
>> Both are under review on 2d alias.
>>
>> On 5/13/14 9:29 PM, Anthony Petrov wrote:
>>> Hi Jim, Sergey, and Anton,
>>>
>>> I'd like to revive this old thread and finally push this fix, which
>>> has been reviewed and approved on this mailing list back in February.
>>> The only additional change that I want to introduce, is the addition
>>> of default implementations for the
>>> LightweightContent.imageBufferReset() methods. This allows clients of
>>> the API (namely, JavaFX) to run with both the old and the new JDK w/o
>>> any changes or side-effects. Here's the updated webrev:
>>>
>>> http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/
>>>
>>> It literally only adds the default methods and doesn't make any other
>>> changes to the rest of the already reviewed code. I've tested this on
>>> both hiDPI and loDPI displays, with both old and hiDPI-aware JavaFX
>>> builds, and it works fine in all the cases.
>>>
>>> The current plan is to push this fix to JDK 9, and then back-port the
>>> changes to 8u20.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 2/21/2014 2:47 AM, Jim Graham wrote:
>>>> Yes, approved.
>>>>
>>>>          ...jim
>>>>
>>>> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>>>>> Jim, so this is ready for a push then.
>>>>>
>>>>> Thanks!
>>>>> Anton.
>>>>>
>>>>> On 15.02.2014 5:01, Jim Graham wrote:
>>>>>> I don't need to see an update for that.  I didn't read the entire
>>>>>> webrev, but I looked at this one piece of code and if that was the
>>>>>> only thing changed then I think that dealt with the outstanding
>>>>>> issues...
>>>>>>
>>>>>>         ...jim
>>>>>>
>>>>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>>>>> Hi Jim,
>>>>>>>>>
>>>>>>>>> Please, look at the update:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
>>>>>>>>>
>>>>>>>>> Here I'm correcting the rect after the transform in SG2D:
>>>>>>>>>
>>>>>>>>> 2123         // In case of negative scale transform, reflect the
>>>>>>>>> rect
>>>>>>>>> coords.
>>>>>>>>> 2124         if (w < 0) {
>>>>>>>>> 2125             w *= -1;
>>>>>>>>> 2126             x -= w;
>>>>>>>>> 2127         }
>>>>>>>>> 2128         if (h < 0) {
>>>>>>>>> 2129             h *= -1;
>>>>>>>>> 2130             y -= h;
>>>>>>>>> 2131         }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The blit direction (dx, dy) remains transformed. Is this the 
>>>>>>>>> right
>>>>>>>>> behavior from your perspective?
>>>>>>>>
>>>>>>>> Yes, that looks good.  I wonder if the "w *= -1" results in a
>>>>>>>> multiply
>>>>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>>>>
>>>>>>>>             ...jim
>>>>>>>
>>>>>>> Jim,
>>>>>>>
>>>>>>> Yes, this indeed results in different byte code instructions 
>>>>>>> (imult &
>>>>>>> ineg). Just for curiosity I did some measuring which showed
>>>>>>> negatioation
>>>>>>> worked 10% faster :)
>>>>>>> Well, I'll fix it but let me please not send an update...
>>>>>>>
>>>>>>> Thanks!
>>>>>>> Anton.
>>>>>>>
>>>>>
>>
>>


-- 
Best regards, Sergey.



From gnu.andrew at redhat.com  Thu May 22 00:23:23 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 21 May 2014 20:23:23 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: Allow using the system libjpeg
In-Reply-To: <20140521205934.GE3957@redhat.com>
References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com>
	<20140520171120.GD2672@redhat.com>
	<113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com>
	<20140521205934.GE3957@redhat.com>
Message-ID: <1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com>

----- Original Message -----
> * Andrew Hughes <gnu.andrew at redhat.com> [2014-05-21 12:22]:
> > I'm not keen on the hardcoding of '-ljpeg'
> > 
> > +  LIBJPEG_LIBS := -ljpeg
> 
> There's no pkg-config files for it. Any suggestions on how to get
> something generic?
> 

I know there isn't at present. I still think it's better to be consistent
and set the values in configure, even if at present they have to be hardcoded
defaults.

> > Could this not at least be conditionally assigned? (?=)
> 
> It can still be overridden on the make command line:
> 
> make LIBJPEG_LIBS=foo
> 
> Is this not sufficient?
> 

The make documentation is a little unclear here, and makes it sound like it
will always be set if := or = is used.

> Thanks,
> Omair
> 
> --
> PGP Key: 66484681 (http://pgp.mit.edu/)
> Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From omajid at redhat.com  Thu May 22 00:49:31 2014
From: omajid at redhat.com (Omair Majid)
Date: Wed, 21 May 2014 20:49:31 -0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: Allow using the system libjpeg
In-Reply-To: <1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com>
References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com>
	<20140520171120.GD2672@redhat.com>
	<113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com>
	<20140521205934.GE3957@redhat.com>
	<1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com>
Message-ID: <20140522004931.GG3957@redhat.com>

* Andrew Hughes <gnu.andrew at redhat.com> [2014-05-21 20:23]:
> ----- Original Message -----
> > * Andrew Hughes <gnu.andrew at redhat.com> [2014-05-21 12:22]:
> > > I'm not keen on the hardcoding of '-ljpeg'
> > > 
> > > +  LIBJPEG_LIBS := -ljpeg
> > 
> > There's no pkg-config files for it. Any suggestions on how to get
> > something generic?
> > 
> 
> I know there isn't at present. I still think it's better to be consistent
> and set the values in configure, even if at present they have to be hardcoded
> defaults.

Would you mind if I did this as a separate patch? I will need to fix
other libraries too (libzip, and libgif).

> The make documentation is a little unclear here, and makes it sound like it
> will always be set if := or = is used.

Indeed, it is unclear. But I discovered through trial and error that
given a Makefile like:

FOO=-v
all:
	gcc ${FOO}

these two forms are different:

$ FOO=bar make

$ make FOO=bar

The first one sets the environment variable FOO, and the Makefile
overrides it (it runs `gcc -v`). The second passes a command line
argument that overrides the value in the Makefile (it runs `gcc foo`).

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681


From anton.tarasov at oracle.com  Thu May 22 07:47:12 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 22 May 2014 11:47:12 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <537D1E3C.9090309@oracle.com>
References: <52A723B8.7090705@oracle.com> <52A9D341.2070008@oracle.com>
	<52AA0C32.504@oracle.com> <52AA0E11.3060706@oracle.com>
	<52AA39A2.4060503@oracle.com> <52AA3E92.7040302@oracle.com>
	<52B09644.6050201@oracle.com> <52B0F447.2020207@oracle.com>
	<52DE761E.2000201@oracle.com> <52E192F0.7010107@oracle.com>
	<52E27CDA.40703@oracle.com> <52E31866.3010508@oracle.com>
	<52E7CE5B.4070101@oracle.com> <52EAD304.2090809@oracle.com>
	<52EBB516.70906@oracle.com> <52EC4F5E.7060906@oracle.com>
	<52EFA980.6000404@oracle.com> <52F580C1.3020906@oracle.com>
	<52F8DE2A.4080304@oracle.com> <52F962CD.2050301@oracle.com>
	<52F96AE2.10106@oracle.com> <52FA67A8.1010600@oracle.com>
	<52FA7DCD.80405@oracle.com> <52FCC28D.5010007@oracle.com>
	<52FD4CB6.2090805@oracle.com> <52FDC1D1.8050907@oracle.com>
	<52FEBC4E.9010202@oracle.com> <5302182D.3070600@oracle.com>
	<53068600.80501@oracle.com> <53725695.40209@oracle.com>
	<537CCA57.4050200@oracle.com> <537CECB4.7080706@oracle.com>
	<537D1E3C.9090309@oracle.com>
Message-ID: <537DAB80.1090106@oracle.com>

Hi Sergey,

On 22.05.2014 1:44, Sergey Bylokhov wrote:
> On 5/21/14 10:13 PM, Anthony Petrov wrote:
>> Hi Sergey,
>>
>> The original fix provides some updates and clarifications to the javadoc for the 
>> LightweightContent.imageBufferReset() method, but they are missing from your fix. Is this 
>> intentional?
> Nope. I just missed this update. I looked at this method closely and got a question: do we need 
> this scale parameter? Why we cannot use w,h + scanstride here an skip all clarification about 
> logical coordinates?

Originally, Jim suggested to generalize the API:

<<Rather than imply any parameters, I think specifying a very exact set of parameters gives the most 
flexibility.  Even if the relationships you characterize above are true, xywh,scan or off,wh,scan 
both provide the flexibility to supply the data in those formats without the client having to guess 
dimensions or scan size. Any API that specifies an array containing data should always provide the 
flexibility of specifying an offset (and x,y is a way of specifying an offset for rectangular data 
and using a nio Buffer can implicitly imply an offset based on its position) and when that data is a 
rectangle of data then it should also supply independent w,h and scan strides.  If the offset is 
always 0, and if the scanstride is always w in the implementation's that choose the data storage 
then it may seem like overkill, but it provides the flexibility of switching to a more sophisticated 
buffer re-use strategy later without having to track down every client and update them... >>

and so we provide all the coordinates.

Thanks,
Anton.

>
>>
>> BTW, I've applied your fix and tested it with the latest version of FX changes, and everything 
>> works smoothly on my Mac, including the display change listener.
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 5/21/2014 7:46 PM, Sergey Bylokhov wrote:
>>> Hello, Everybody.
>>> Please review an updated version of this fix. This is a minimum possible
>>> fix. changes in shared code of jdk are minimized and can be enhanced in
>>> the future.
>>> The fix is covering hdpi support in SwingNode on osx + system look and
>>> feel(Aqua).
>>>
>>> http://cr.openjdk.java.net/~serb/8029455/webrev.01
>>>
>>> Notes:
>>>   - This fix depends from two other fixes: JDK- 8041129 and JDK-8041644.
>>> Both are under review on 2d alias.
>>>
>>> On 5/13/14 9:29 PM, Anthony Petrov wrote:
>>>> Hi Jim, Sergey, and Anton,
>>>>
>>>> I'd like to revive this old thread and finally push this fix, which
>>>> has been reviewed and approved on this mailing list back in February.
>>>> The only additional change that I want to introduce, is the addition
>>>> of default implementations for the
>>>> LightweightContent.imageBufferReset() methods. This allows clients of
>>>> the API (namely, JavaFX) to run with both the old and the new JDK w/o
>>>> any changes or side-effects. Here's the updated webrev:
>>>>
>>>> http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/
>>>>
>>>> It literally only adds the default methods and doesn't make any other
>>>> changes to the rest of the already reviewed code. I've tested this on
>>>> both hiDPI and loDPI displays, with both old and hiDPI-aware JavaFX
>>>> builds, and it works fine in all the cases.
>>>>
>>>> The current plan is to push this fix to JDK 9, and then back-port the
>>>> changes to 8u20.
>>>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 2/21/2014 2:47 AM, Jim Graham wrote:
>>>>> Yes, approved.
>>>>>
>>>>>          ...jim
>>>>>
>>>>> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>>>>>> Jim, so this is ready for a push then.
>>>>>>
>>>>>> Thanks!
>>>>>> Anton.
>>>>>>
>>>>>> On 15.02.2014 5:01, Jim Graham wrote:
>>>>>>> I don't need to see an update for that.  I didn't read the entire
>>>>>>> webrev, but I looked at this one piece of code and if that was the
>>>>>>> only thing changed then I think that dealt with the outstanding
>>>>>>> issues...
>>>>>>>
>>>>>>>         ...jim
>>>>>>>
>>>>>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>>>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>>>>>> Hi Jim,
>>>>>>>>>>
>>>>>>>>>> Please, look at the update:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
>>>>>>>>>>
>>>>>>>>>> Here I'm correcting the rect after the transform in SG2D:
>>>>>>>>>>
>>>>>>>>>> 2123         // In case of negative scale transform, reflect the
>>>>>>>>>> rect
>>>>>>>>>> coords.
>>>>>>>>>> 2124         if (w < 0) {
>>>>>>>>>> 2125             w *= -1;
>>>>>>>>>> 2126             x -= w;
>>>>>>>>>> 2127         }
>>>>>>>>>> 2128         if (h < 0) {
>>>>>>>>>> 2129             h *= -1;
>>>>>>>>>> 2130             y -= h;
>>>>>>>>>> 2131         }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The blit direction (dx, dy) remains transformed. Is this the right
>>>>>>>>>> behavior from your perspective?
>>>>>>>>>
>>>>>>>>> Yes, that looks good.  I wonder if the "w *= -1" results in a
>>>>>>>>> multiply
>>>>>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>>>>>
>>>>>>>>>             ...jim
>>>>>>>>
>>>>>>>> Jim,
>>>>>>>>
>>>>>>>> Yes, this indeed results in different byte code instructions (imult &
>>>>>>>> ineg). Just for curiosity I did some measuring which showed
>>>>>>>> negatioation
>>>>>>>> worked 10% faster :)
>>>>>>>> Well, I'll fix it but let me please not send an update...
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> Anton.
>>>>>>>>
>>>>>>
>>>
>>>
>
>



From erik.joelsson at oracle.com  Thu May 22 09:02:04 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 22 May 2014 11:02:04 +0200
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: Allow using the system libjpeg
In-Reply-To: <20140522004931.GG3957@redhat.com>
References: <20140517004529.GD4370@redhat.com>
	<537A509E.2090504@oracle.com>	<20140520171120.GD2672@redhat.com>	<113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com>	<20140521205934.GE3957@redhat.com>	<1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com>
	<20140522004931.GG3957@redhat.com>
Message-ID: <537DBD0C.2010809@oracle.com>


On 2014-05-22 02:49, Omair Majid wrote:
> * Andrew Hughes <gnu.andrew at redhat.com> [2014-05-21 20:23]:
>> ----- Original Message -----
>>> * Andrew Hughes <gnu.andrew at redhat.com> [2014-05-21 12:22]:
>>>> I'm not keen on the hardcoding of '-ljpeg'
>>>>
>>>> +  LIBJPEG_LIBS := -ljpeg
>>> There's no pkg-config files for it. Any suggestions on how to get
>>> something generic?
>>>
>> I know there isn't at present. I still think it's better to be consistent
>> and set the values in configure, even if at present they have to be hardcoded
>> defaults.
> Would you mind if I did this as a separate patch? I will need to fix
> other libraries too (libzip, and libgif).
>
>> The make documentation is a little unclear here, and makes it sound like it
>> will always be set if := or = is used.
> Indeed, it is unclear. But I discovered through trial and error that
> given a Makefile like:
>
> FOO=-v
> all:
> 	gcc ${FOO}
>
> these two forms are different:
>
> $ FOO=bar make
>
> $ make FOO=bar
>
> The first one sets the environment variable FOO, and the Makefile
> overrides it (it runs `gcc -v`). The second passes a command line
> argument that overrides the value in the Makefile (it runs `gcc foo`).
This is my experience too. There is the "override" keyword that you can 
use to not allow command line overrides:

override FOO=-v

The above would make both forms behave the same.

/Erik
> Thanks,
> Omair
>



From Sergey.Bylokhov at oracle.com  Thu May 22 11:36:47 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 22 May 2014 15:36:47 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <537DAB80.1090106@oracle.com>
References: <52A723B8.7090705@oracle.com> <52AA0C32.504@oracle.com>
	<52AA0E11.3060706@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com>
	<52B0F447.2020207@oracle.com> <52DE761E.2000201@oracle.com>
	<52E192F0.7010107@oracle.com> <52E27CDA.40703@oracle.com>
	<52E31866.3010508@oracle.com> <52E7CE5B.4070101@oracle.com>
	<52EAD304.2090809@oracle.com> <52EBB516.70906@oracle.com>
	<52EC4F5E.7060906@oracle.com> <52EFA980.6000404@oracle.com>
	<52F580C1.3020906@oracle.com> <52F8DE2A.4080304@oracle.com>
	<52F962CD.2050301@oracle.com> <52F96AE2.10106@oracle.com>
	<52FA67A8.1010600@oracle.com> <52FA7DCD.80405@oracle.com>
	<52FCC28D.5010007@oracle.com> <52FD4CB6.2090805@oracle.com>
	<52FDC1D1.8050907@oracle.com> <52FEBC4E.9010202@oracle.com>
	<5302182D.3070600@oracle.com> <53068600.80501@oracle.com>
	<53725695.40209@oracle.com> <537CCA57.4050200@oracle.com>
	<537CECB4.7080706@oracle.com> <537D1E3C.9090309@oracle.com>
	<537DAB80.1090106@oracle.com>
Message-ID: <537DE14F.4070603@oracle.com>

On 5/22/14 11:47 AM, Anton V. Tarasov wrote:
> Hi Sergey,
>
> On 22.05.2014 1:44, Sergey Bylokhov wrote:
>> On 5/21/14 10:13 PM, Anthony Petrov wrote:
>>> Hi Sergey,
>>>
>>> The original fix provides some updates and clarifications to the 
>>> javadoc for the LightweightContent.imageBufferReset() method, but 
>>> they are missing from your fix. Is this intentional?
>> Nope. I just missed this update. I looked at this method closely and 
>> got a question: do we need this scale parameter? Why we cannot use 
>> w,h + scanstride here an skip all clarification about logical 
>> coordinates?
>
> Originally, Jim suggested to generalize the API:
>
> <<Rather than imply any parameters, I think specifying a very exact 
> set of parameters gives the most flexibility.  Even if the 
> relationships you characterize above are true, xywh,scan or 
> off,wh,scan both provide the flexibility to supply the data in those 
> formats without the client having to guess dimensions or scan size. 
> Any API that specifies an array containing data should always provide 
> the flexibility of specifying an offset (and x,y is a way of 
> specifying an offset for rectangular data and using a nio Buffer can 
> implicitly imply an offset based on its position) and when that data 
> is a rectangle of data then it should also supply independent w,h and 
> scan strides.  If the offset is always 0, and if the scanstride is 
> always w in the implementation's that choose the data storage then it 
> may seem like overkill, but it provides the flexibility of switching 
> to a more sophisticated buffer re-use strategy later without having to 
> track down every client and update them... >>
>
> and so we provide all the coordinates.
I understand why we need x/y/w/h/scanstride but why we need scale, 
because our buffer is pixel based anyway? In this case we have to 
convert w/h/x/y/scanstride from logical to pixels and back.

>
> Thanks,
> Anton.
>
>>
>>>
>>> BTW, I've applied your fix and tested it with the latest version of 
>>> FX changes, and everything works smoothly on my Mac, including the 
>>> display change listener.
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 5/21/2014 7:46 PM, Sergey Bylokhov wrote:
>>>> Hello, Everybody.
>>>> Please review an updated version of this fix. This is a minimum 
>>>> possible
>>>> fix. changes in shared code of jdk are minimized and can be 
>>>> enhanced in
>>>> the future.
>>>> The fix is covering hdpi support in SwingNode on osx + system look and
>>>> feel(Aqua).
>>>>
>>>> http://cr.openjdk.java.net/~serb/8029455/webrev.01
>>>>
>>>> Notes:
>>>>   - This fix depends from two other fixes: JDK- 8041129 and 
>>>> JDK-8041644.
>>>> Both are under review on 2d alias.
>>>>
>>>> On 5/13/14 9:29 PM, Anthony Petrov wrote:
>>>>> Hi Jim, Sergey, and Anton,
>>>>>
>>>>> I'd like to revive this old thread and finally push this fix, which
>>>>> has been reviewed and approved on this mailing list back in February.
>>>>> The only additional change that I want to introduce, is the addition
>>>>> of default implementations for the
>>>>> LightweightContent.imageBufferReset() methods. This allows clients of
>>>>> the API (namely, JavaFX) to run with both the old and the new JDK w/o
>>>>> any changes or side-effects. Here's the updated webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/
>>>>>
>>>>> It literally only adds the default methods and doesn't make any other
>>>>> changes to the rest of the already reviewed code. I've tested this on
>>>>> both hiDPI and loDPI displays, with both old and hiDPI-aware JavaFX
>>>>> builds, and it works fine in all the cases.
>>>>>
>>>>> The current plan is to push this fix to JDK 9, and then back-port the
>>>>> changes to 8u20.
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 2/21/2014 2:47 AM, Jim Graham wrote:
>>>>>> Yes, approved.
>>>>>>
>>>>>>          ...jim
>>>>>>
>>>>>> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>>>>>>> Jim, so this is ready for a push then.
>>>>>>>
>>>>>>> Thanks!
>>>>>>> Anton.
>>>>>>>
>>>>>>> On 15.02.2014 5:01, Jim Graham wrote:
>>>>>>>> I don't need to see an update for that.  I didn't read the entire
>>>>>>>> webrev, but I looked at this one piece of code and if that was the
>>>>>>>> only thing changed then I think that dealt with the outstanding
>>>>>>>> issues...
>>>>>>>>
>>>>>>>>         ...jim
>>>>>>>>
>>>>>>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>>>>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>>>>>>> Hi Jim,
>>>>>>>>>>>
>>>>>>>>>>> Please, look at the update:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
>>>>>>>>>>>
>>>>>>>>>>> Here I'm correcting the rect after the transform in SG2D:
>>>>>>>>>>>
>>>>>>>>>>> 2123         // In case of negative scale transform, reflect 
>>>>>>>>>>> the
>>>>>>>>>>> rect
>>>>>>>>>>> coords.
>>>>>>>>>>> 2124         if (w < 0) {
>>>>>>>>>>> 2125             w *= -1;
>>>>>>>>>>> 2126             x -= w;
>>>>>>>>>>> 2127         }
>>>>>>>>>>> 2128         if (h < 0) {
>>>>>>>>>>> 2129             h *= -1;
>>>>>>>>>>> 2130             y -= h;
>>>>>>>>>>> 2131         }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The blit direction (dx, dy) remains transformed. Is this the 
>>>>>>>>>>> right
>>>>>>>>>>> behavior from your perspective?
>>>>>>>>>>
>>>>>>>>>> Yes, that looks good.  I wonder if the "w *= -1" results in a
>>>>>>>>>> multiply
>>>>>>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>>>>>>
>>>>>>>>>>             ...jim
>>>>>>>>>
>>>>>>>>> Jim,
>>>>>>>>>
>>>>>>>>> Yes, this indeed results in different byte code instructions 
>>>>>>>>> (imult &
>>>>>>>>> ineg). Just for curiosity I did some measuring which showed
>>>>>>>>> negatioation
>>>>>>>>> worked 10% faster :)
>>>>>>>>> Well, I'll fix it but let me please not send an update...
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> Anton.
>>>>>>>>>
>>>>>>>
>>>>
>>>>
>>
>>
>


-- 
Best regards, Sergey.



From anton.tarasov at oracle.com  Thu May 22 13:58:57 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 22 May 2014 17:58:57 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <537DE14F.4070603@oracle.com>
References: <52A723B8.7090705@oracle.com> <52AA0E11.3060706@oracle.com>
	<52AA39A2.4060503@oracle.com> <52AA3E92.7040302@oracle.com>
	<52B09644.6050201@oracle.com> <52B0F447.2020207@oracle.com>
	<52DE761E.2000201@oracle.com> <52E192F0.7010107@oracle.com>
	<52E27CDA.40703@oracle.com> <52E31866.3010508@oracle.com>
	<52E7CE5B.4070101@oracle.com> <52EAD304.2090809@oracle.com>
	<52EBB516.70906@oracle.com> <52EC4F5E.7060906@oracle.com>
	<52EFA980.6000404@oracle.com> <52F580C1.3020906@oracle.com>
	<52F8DE2A.4080304@oracle.com> <52F962CD.2050301@oracle.com>
	<52F96AE2.10106@oracle.com> <52FA67A8.1010600@oracle.com>
	<52FA7DCD.80405@oracle.com> <52FCC28D.5010007@oracle.com>
	<52FD4CB6.2090805@oracle.com> <52FDC1D1.8050907@oracle.com>
	<52FEBC4E.9010202@oracle.com> <5302182D.3070600@oracle.com>
	<53068600.80501@oracle.com> <53725695.40209@oracle.com>
	<537CCA57.4050200@oracle.com> <537CECB4.7080706@oracle.com>
	<537D1E3C.9090309@oracle.com> <537DAB80.1090106@oracle.com>
	<537DE14F.4070603@oracle.com>
Message-ID: <537E02A1.3050303@oracle.com>

On 22.05.2014 15:36, Sergey Bylokhov wrote:
> On 5/22/14 11:47 AM, Anton V. Tarasov wrote:
>> Hi Sergey,
>>
>> On 22.05.2014 1:44, Sergey Bylokhov wrote:
>>> On 5/21/14 10:13 PM, Anthony Petrov wrote:
>>>> Hi Sergey,
>>>>
>>>> The original fix provides some updates and clarifications to the javadoc for the 
>>>> LightweightContent.imageBufferReset() method, but they are missing from your fix. Is this 
>>>> intentional?
>>> Nope. I just missed this update. I looked at this method closely and got a question: do we need 
>>> this scale parameter? Why we cannot use w,h + scanstride here an skip all clarification about 
>>> logical coordinates?
>>
>> Originally, Jim suggested to generalize the API:
>>
>> <<Rather than imply any parameters, I think specifying a very exact set of parameters gives the 
>> most flexibility.  Even if the relationships you characterize above are true, xywh,scan or 
>> off,wh,scan both provide the flexibility to supply the data in those formats without the client 
>> having to guess dimensions or scan size. Any API that specifies an array containing data should 
>> always provide the flexibility of specifying an offset (and x,y is a way of specifying an offset 
>> for rectangular data and using a nio Buffer can implicitly imply an offset based on its position) 
>> and when that data is a rectangle of data then it should also supply independent w,h and scan 
>> strides.  If the offset is always 0, and if the scanstride is always w in the implementation's 
>> that choose the data storage then it may seem like overkill, but it provides the flexibility of 
>> switching to a more sophisticated buffer re-use strategy later without having to track down every 
>> client and update them... >>
>>
>> and so we provide all the coordinates.
> I understand why we need x/y/w/h/scanstride but why we need scale, because our buffer is pixel 
> based anyway? In this case we have to convert w/h/x/y/scanstride from logical to pixels and back.

The reasoning for that if the following. On the client side (SwingNode), during the rendering of the 
image, there's a need to have logical bounds of the image. So, this would require conversion 
(devision)  for what the client would need to know the scale factor for what it would need to ask 
for it, separately. This would bring another code path & dependencies (for instance, b/w SwingNode 
and its prism peer). Currently, there's only one parameter of a method for that purpose.

Thanks,
Anton.

>
>>
>> Thanks,
>> Anton.
>>
>>>
>>>>
>>>> BTW, I've applied your fix and tested it with the latest version of FX changes, and everything 
>>>> works smoothly on my Mac, including the display change listener.
>>>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 5/21/2014 7:46 PM, Sergey Bylokhov wrote:
>>>>> Hello, Everybody.
>>>>> Please review an updated version of this fix. This is a minimum possible
>>>>> fix. changes in shared code of jdk are minimized and can be enhanced in
>>>>> the future.
>>>>> The fix is covering hdpi support in SwingNode on osx + system look and
>>>>> feel(Aqua).
>>>>>
>>>>> http://cr.openjdk.java.net/~serb/8029455/webrev.01
>>>>>
>>>>> Notes:
>>>>>   - This fix depends from two other fixes: JDK- 8041129 and JDK-8041644.
>>>>> Both are under review on 2d alias.
>>>>>
>>>>> On 5/13/14 9:29 PM, Anthony Petrov wrote:
>>>>>> Hi Jim, Sergey, and Anton,
>>>>>>
>>>>>> I'd like to revive this old thread and finally push this fix, which
>>>>>> has been reviewed and approved on this mailing list back in February.
>>>>>> The only additional change that I want to introduce, is the addition
>>>>>> of default implementations for the
>>>>>> LightweightContent.imageBufferReset() methods. This allows clients of
>>>>>> the API (namely, JavaFX) to run with both the old and the new JDK w/o
>>>>>> any changes or side-effects. Here's the updated webrev:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/
>>>>>>
>>>>>> It literally only adds the default methods and doesn't make any other
>>>>>> changes to the rest of the already reviewed code. I've tested this on
>>>>>> both hiDPI and loDPI displays, with both old and hiDPI-aware JavaFX
>>>>>> builds, and it works fine in all the cases.
>>>>>>
>>>>>> The current plan is to push this fix to JDK 9, and then back-port the
>>>>>> changes to 8u20.
>>>>>>
>>>>>> -- 
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 2/21/2014 2:47 AM, Jim Graham wrote:
>>>>>>> Yes, approved.
>>>>>>>
>>>>>>>          ...jim
>>>>>>>
>>>>>>> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>>>>>>>> Jim, so this is ready for a push then.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> Anton.
>>>>>>>>
>>>>>>>> On 15.02.2014 5:01, Jim Graham wrote:
>>>>>>>>> I don't need to see an update for that.  I didn't read the entire
>>>>>>>>> webrev, but I looked at this one piece of code and if that was the
>>>>>>>>> only thing changed then I think that dealt with the outstanding
>>>>>>>>> issues...
>>>>>>>>>
>>>>>>>>>         ...jim
>>>>>>>>>
>>>>>>>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>>>>>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>>>>>>>> Hi Jim,
>>>>>>>>>>>>
>>>>>>>>>>>> Please, look at the update:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
>>>>>>>>>>>>
>>>>>>>>>>>> Here I'm correcting the rect after the transform in SG2D:
>>>>>>>>>>>>
>>>>>>>>>>>> 2123         // In case of negative scale transform, reflect the
>>>>>>>>>>>> rect
>>>>>>>>>>>> coords.
>>>>>>>>>>>> 2124         if (w < 0) {
>>>>>>>>>>>> 2125             w *= -1;
>>>>>>>>>>>> 2126             x -= w;
>>>>>>>>>>>> 2127         }
>>>>>>>>>>>> 2128         if (h < 0) {
>>>>>>>>>>>> 2129             h *= -1;
>>>>>>>>>>>> 2130             y -= h;
>>>>>>>>>>>> 2131         }
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The blit direction (dx, dy) remains transformed. Is this the right
>>>>>>>>>>>> behavior from your perspective?
>>>>>>>>>>>
>>>>>>>>>>> Yes, that looks good.  I wonder if the "w *= -1" results in a
>>>>>>>>>>> multiply
>>>>>>>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>>>>>>>
>>>>>>>>>>>             ...jim
>>>>>>>>>>
>>>>>>>>>> Jim,
>>>>>>>>>>
>>>>>>>>>> Yes, this indeed results in different byte code instructions (imult &
>>>>>>>>>> ineg). Just for curiosity I did some measuring which showed
>>>>>>>>>> negatioation
>>>>>>>>>> worked 10% faster :)
>>>>>>>>>> Well, I'll fix it but let me please not send an update...
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>> Anton.
>>>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>



From Sergey.Bylokhov at oracle.com  Thu May 22 18:05:38 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 22 May 2014 22:05:38 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <537E02A1.3050303@oracle.com>
References: <52A723B8.7090705@oracle.com> <52AA39A2.4060503@oracle.com>
	<52AA3E92.7040302@oracle.com> <52B09644.6050201@oracle.com>
	<52B0F447.2020207@oracle.com> <52DE761E.2000201@oracle.com>
	<52E192F0.7010107@oracle.com> <52E27CDA.40703@oracle.com>
	<52E31866.3010508@oracle.com> <52E7CE5B.4070101@oracle.com>
	<52EAD304.2090809@oracle.com> <52EBB516.70906@oracle.com>
	<52EC4F5E.7060906@oracle.com> <52EFA980.6000404@oracle.com>
	<52F580C1.3020906@oracle.com> <52F8DE2A.4080304@oracle.com>
	<52F962CD.2050301@oracle.com> <52F96AE2.10106@oracle.com>
	<52FA67A8.1010600@oracle.com> <52FA7DCD.80405@oracle.com>
	<52FCC28D.5010007@oracle.com> <52FD4CB6.2090805@oracle.com>
	<52FDC1D1.8050907@oracle.com> <52FEBC4E.9010202@oracle.com>
	<5302182D.3070600@oracle.com> <53068600.80501@oracle.com>
	<53725695.40209@oracle.com> <537CCA57.4050200@oracle.com>
	<537CECB4.7080706@oracle.com> <537D1E3C.9090309@oracle.com>
	<537DAB80.1090106@oracle.com> <537DE14F.4070603@oracle.com>
	<537E02A1.3050303@oracle.com>
Message-ID: <537E3C72.3010607@oracle.com>

On 5/22/14 5:58 PM, Anton V. Tarasov wrote:
> On 22.05.2014 15:36, Sergey Bylokhov wrote:
>> On 5/22/14 11:47 AM, Anton V. Tarasov wrote:
>>> Hi Sergey,
>>>
>>> On 22.05.2014 1:44, Sergey Bylokhov wrote:
>>>> On 5/21/14 10:13 PM, Anthony Petrov wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> The original fix provides some updates and clarifications to the 
>>>>> javadoc for the LightweightContent.imageBufferReset() method, but 
>>>>> they are missing from your fix. Is this intentional?
>>>> Nope. I just missed this update. I looked at this method closely 
>>>> and got a question: do we need this scale parameter? Why we cannot 
>>>> use w,h + scanstride here an skip all clarification about logical 
>>>> coordinates?
>>>
>>> Originally, Jim suggested to generalize the API:
>>>
>>> <<Rather than imply any parameters, I think specifying a very exact 
>>> set of parameters gives the most flexibility.  Even if the 
>>> relationships you characterize above are true, xywh,scan or 
>>> off,wh,scan both provide the flexibility to supply the data in those 
>>> formats without the client having to guess dimensions or scan size. 
>>> Any API that specifies an array containing data should always 
>>> provide the flexibility of specifying an offset (and x,y is a way of 
>>> specifying an offset for rectangular data and using a nio Buffer can 
>>> implicitly imply an offset based on its position) and when that data 
>>> is a rectangle of data then it should also supply independent w,h 
>>> and scan strides.  If the offset is always 0, and if the scanstride 
>>> is always w in the implementation's that choose the data storage 
>>> then it may seem like overkill, but it provides the flexibility of 
>>> switching to a more sophisticated buffer re-use strategy later 
>>> without having to track down every client and update them... >>
>>>
>>> and so we provide all the coordinates.
>> I understand why we need x/y/w/h/scanstride but why we need scale, 
>> because our buffer is pixel based anyway? In this case we have to 
>> convert w/h/x/y/scanstride from logical to pixels and back.
>
> The reasoning for that if the following. On the client side 
> (SwingNode), during the rendering of the image, there's a need to have 
> logical bounds of the image. So, this would require conversion 
> (devision)  for what the client would need to know the scale factor 
> for what it would need to ask for it, separately. This would bring 
> another code path & dependencies (for instance, b/w SwingNode and its 
> prism peer). Currently, there's only one parameter of a method for 
> that purpose.
Ok. Here is an updated version:
http://cr.openjdk.java.net/~serb/8029455/webrev.02
>
> Thanks,
> Anton.
>
>>
>>>
>>> Thanks,
>>> Anton.
>>>
>>>>
>>>>>
>>>>> BTW, I've applied your fix and tested it with the latest version 
>>>>> of FX changes, and everything works smoothly on my Mac, including 
>>>>> the display change listener.
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 5/21/2014 7:46 PM, Sergey Bylokhov wrote:
>>>>>> Hello, Everybody.
>>>>>> Please review an updated version of this fix. This is a minimum 
>>>>>> possible
>>>>>> fix. changes in shared code of jdk are minimized and can be 
>>>>>> enhanced in
>>>>>> the future.
>>>>>> The fix is covering hdpi support in SwingNode on osx + system 
>>>>>> look and
>>>>>> feel(Aqua).
>>>>>>
>>>>>> http://cr.openjdk.java.net/~serb/8029455/webrev.01
>>>>>>
>>>>>> Notes:
>>>>>>   - This fix depends from two other fixes: JDK- 8041129 and 
>>>>>> JDK-8041644.
>>>>>> Both are under review on 2d alias.
>>>>>>
>>>>>> On 5/13/14 9:29 PM, Anthony Petrov wrote:
>>>>>>> Hi Jim, Sergey, and Anton,
>>>>>>>
>>>>>>> I'd like to revive this old thread and finally push this fix, which
>>>>>>> has been reviewed and approved on this mailing list back in 
>>>>>>> February.
>>>>>>> The only additional change that I want to introduce, is the 
>>>>>>> addition
>>>>>>> of default implementations for the
>>>>>>> LightweightContent.imageBufferReset() methods. This allows 
>>>>>>> clients of
>>>>>>> the API (namely, JavaFX) to run with both the old and the new 
>>>>>>> JDK w/o
>>>>>>> any changes or side-effects. Here's the updated webrev:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/
>>>>>>>
>>>>>>> It literally only adds the default methods and doesn't make any 
>>>>>>> other
>>>>>>> changes to the rest of the already reviewed code. I've tested 
>>>>>>> this on
>>>>>>> both hiDPI and loDPI displays, with both old and hiDPI-aware JavaFX
>>>>>>> builds, and it works fine in all the cases.
>>>>>>>
>>>>>>> The current plan is to push this fix to JDK 9, and then 
>>>>>>> back-port the
>>>>>>> changes to 8u20.
>>>>>>>
>>>>>>> -- 
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>>
>>>>>>> On 2/21/2014 2:47 AM, Jim Graham wrote:
>>>>>>>> Yes, approved.
>>>>>>>>
>>>>>>>>          ...jim
>>>>>>>>
>>>>>>>> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>>>>>>>>> Jim, so this is ready for a push then.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> Anton.
>>>>>>>>>
>>>>>>>>> On 15.02.2014 5:01, Jim Graham wrote:
>>>>>>>>>> I don't need to see an update for that.  I didn't read the 
>>>>>>>>>> entire
>>>>>>>>>> webrev, but I looked at this one piece of code and if that 
>>>>>>>>>> was the
>>>>>>>>>> only thing changed then I think that dealt with the outstanding
>>>>>>>>>> issues...
>>>>>>>>>>
>>>>>>>>>>         ...jim
>>>>>>>>>>
>>>>>>>>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>>>>>>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>>>>>>>>> Hi Jim,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please, look at the update:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here I'm correcting the rect after the transform in SG2D:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2123         // In case of negative scale transform, 
>>>>>>>>>>>>> reflect the
>>>>>>>>>>>>> rect
>>>>>>>>>>>>> coords.
>>>>>>>>>>>>> 2124         if (w < 0) {
>>>>>>>>>>>>> 2125             w *= -1;
>>>>>>>>>>>>> 2126             x -= w;
>>>>>>>>>>>>> 2127         }
>>>>>>>>>>>>> 2128         if (h < 0) {
>>>>>>>>>>>>> 2129             h *= -1;
>>>>>>>>>>>>> 2130             y -= h;
>>>>>>>>>>>>> 2131         }
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The blit direction (dx, dy) remains transformed. Is this 
>>>>>>>>>>>>> the right
>>>>>>>>>>>>> behavior from your perspective?
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, that looks good.  I wonder if the "w *= -1" results in a
>>>>>>>>>>>> multiply
>>>>>>>>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>>>>>>>>
>>>>>>>>>>>>             ...jim
>>>>>>>>>>>
>>>>>>>>>>> Jim,
>>>>>>>>>>>
>>>>>>>>>>> Yes, this indeed results in different byte code instructions 
>>>>>>>>>>> (imult &
>>>>>>>>>>> ineg). Just for curiosity I did some measuring which showed
>>>>>>>>>>> negatioation
>>>>>>>>>>> worked 10% faster :)
>>>>>>>>>>> Well, I'll fix it but let me please not send an update...
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>> Anton.
>>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.



From philip.race at oracle.com  Thu May 22 20:02:04 2014
From: philip.race at oracle.com (Phil Race)
Date: Thu, 22 May 2014 13:02:04 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: Allow using the system libjpeg
In-Reply-To: <20140522004931.GG3957@redhat.com>
References: <20140517004529.GD4370@redhat.com>
	<537A509E.2090504@oracle.com>	<20140520171120.GD2672@redhat.com>	<113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com>	<20140521205934.GE3957@redhat.com>	<1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com>
	<20140522004931.GG3957@redhat.com>
Message-ID: <537E57BC.2010400@oracle.com>

BTW .. I just realised I haven't seen a bug ID in this thread.
Does one already exist ?

-phil.

On 5/21/14 5:49 PM, Omair Majid wrote:
> * Andrew Hughes <gnu.andrew at redhat.com> [2014-05-21 20:23]:
>> ----- Original Message -----
>>> * Andrew Hughes <gnu.andrew at redhat.com> [2014-05-21 12:22]:
>>>> I'm not keen on the hardcoding of '-ljpeg'
>>>>
>>>> +  LIBJPEG_LIBS := -ljpeg
>>> There's no pkg-config files for it. Any suggestions on how to get
>>> something generic?
>>>
>> I know there isn't at present. I still think it's better to be consistent
>> and set the values in configure, even if at present they have to be hardcoded
>> defaults.
> Would you mind if I did this as a separate patch? I will need to fix
> other libraries too (libzip, and libgif).
>
>> The make documentation is a little unclear here, and makes it sound like it
>> will always be set if := or = is used.
> Indeed, it is unclear. But I discovered through trial and error that
> given a Makefile like:
>
> FOO=-v
> all:
> 	gcc ${FOO}
>
> these two forms are different:
>
> $ FOO=bar make
>
> $ make FOO=bar
>
> The first one sets the environment variable FOO, and the Makefile
> overrides it (it runs `gcc -v`). The second passes a command line
> argument that overrides the value in the Makefile (it runs `gcc foo`).
>
> Thanks,
> Omair
>



From gnu.andrew at redhat.com  Thu May 22 20:10:30 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 22 May 2014 16:10:30 -0400 (EDT)
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: Allow using the system libjpeg
In-Reply-To: <537DBD0C.2010809@oracle.com>
References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com>
	<20140520171120.GD2672@redhat.com>
	<113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com>
	<20140521205934.GE3957@redhat.com>
	<1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com>
	<20140522004931.GG3957@redhat.com> <537DBD0C.2010809@oracle.com>
Message-ID: <1569662464.10171034.1400789430009.JavaMail.zimbra@redhat.com>



----- Original Message -----
> 
> On 2014-05-22 02:49, Omair Majid wrote:
> > * Andrew Hughes <gnu.andrew at redhat.com> [2014-05-21 20:23]:
> >> ----- Original Message -----
> >>> * Andrew Hughes <gnu.andrew at redhat.com> [2014-05-21 12:22]:
> >>>> I'm not keen on the hardcoding of '-ljpeg'
> >>>>
> >>>> +  LIBJPEG_LIBS := -ljpeg
> >>> There's no pkg-config files for it. Any suggestions on how to get
> >>> something generic?
> >>>
> >> I know there isn't at present. I still think it's better to be consistent
> >> and set the values in configure, even if at present they have to be
> >> hardcoded
> >> defaults.
> > Would you mind if I did this as a separate patch? I will need to fix
> > other libraries too (libzip, and libgif).
> >

Ok, I thought the other ones were already in this form. In that case, leave it
to me and I'll go through them as a whole. I want to look at the option formatting
anyway.

> >> The make documentation is a little unclear here, and makes it sound like
> >> it
> >> will always be set if := or = is used.
> > Indeed, it is unclear. But I discovered through trial and error that
> > given a Makefile like:
> >
> > FOO=-v
> > all:
> > 	gcc ${FOO}
> >
> > these two forms are different:
> >
> > $ FOO=bar make
> >
> > $ make FOO=bar
> >
> > The first one sets the environment variable FOO, and the Makefile
> > overrides it (it runs `gcc -v`). The second passes a command line
> > argument that overrides the value in the Makefile (it runs `gcc foo`).
> This is my experience too. There is the "override" keyword that you can
> use to not allow command line overrides:
> 
> override FOO=-v
> 
> The above would make both forms behave the same.
> 

Yeah, I was about to mention this. It's described on the next page of the
make manual. So I guess := and ?= are only different if you have the
variable being set elsewhere in the Makefiles.

> /Erik
> > Thanks,
> > Omair
> >
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From omajid at redhat.com  Thu May 22 20:28:08 2014
From: omajid at redhat.com (Omair Majid)
Date: Thu, 22 May 2014 16:28:08 -0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: Allow using the system libjpeg
In-Reply-To: <537E57BC.2010400@oracle.com>
References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com>
	<20140520171120.GD2672@redhat.com>
	<113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com>
	<20140521205934.GE3957@redhat.com>
	<1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com>
	<20140522004931.GG3957@redhat.com> <537E57BC.2010400@oracle.com>
Message-ID: <20140522202808.GJ2825@redhat.com>

* Phil Race <philip.race at oracle.com> [2014-05-22 16:02]:
> BTW .. I just realised I haven't seen a bug ID in this thread.
> Does one already exist ?

No. I was going to create one before I push.

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681


From anthony.petrov at oracle.com  Thu May 22 20:45:09 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 23 May 2014 00:45:09 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <537E3C72.3010607@oracle.com>
References: <52A723B8.7090705@oracle.com> <52AA3E92.7040302@oracle.com>
	<52B09644.6050201@oracle.com> <52B0F447.2020207@oracle.com>
	<52DE761E.2000201@oracle.com> <52E192F0.7010107@oracle.com>
	<52E27CDA.40703@oracle.com> <52E31866.3010508@oracle.com>
	<52E7CE5B.4070101@oracle.com> <52EAD304.2090809@oracle.com>
	<52EBB516.70906@oracle.com> <52EC4F5E.7060906@oracle.com>
	<52EFA980.6000404@oracle.com> <52F580C1.3020906@oracle.com>
	<52F8DE2A.4080304@oracle.com> <52F962CD.2050301@oracle.com>
	<52F96AE2.10106@oracle.com> <52FA67A8.1010600@oracle.com>
	<52FA7DCD.80405@oracle.com> <52FCC28D.5010007@oracle.com>
	<52FD4CB6.2090805@oracle.com> <52FDC1D1.8050907@oracle.com>
	<52FEBC4E.9010202@oracle.com> <5302182D.3070600@oracle.com>
	<53068600.80501@oracle.com> <53725695.40209@oracle.com>
	<537CCA57.4050200@oracle.com> <537CECB4.7080706@oracle.com>
	<537D1E3C.9090309@oracle.com> <537DAB80.1090106@oracle.com>
	<537DE14F.4070603@oracle.com> <537E02A1.3050303@oracle.com>
	<537E3C72.3010607@oracle.com>
Message-ID: <537E61D5.30301@oracle.com>

Hi Sergey,

> http://cr.openjdk.java.net/~serb/8029455/webrev.02

The fix looks fine to me.

--
best regards,
Anthony

On 5/22/2014 10:05 PM, Sergey Bylokhov wrote:
> On 5/22/14 5:58 PM, Anton V. Tarasov wrote:
>> On 22.05.2014 15:36, Sergey Bylokhov wrote:
>>> On 5/22/14 11:47 AM, Anton V. Tarasov wrote:
>>>> Hi Sergey,
>>>>
>>>> On 22.05.2014 1:44, Sergey Bylokhov wrote:
>>>>> On 5/21/14 10:13 PM, Anthony Petrov wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> The original fix provides some updates and clarifications to the
>>>>>> javadoc for the LightweightContent.imageBufferReset() method, but
>>>>>> they are missing from your fix. Is this intentional?
>>>>> Nope. I just missed this update. I looked at this method closely
>>>>> and got a question: do we need this scale parameter? Why we cannot
>>>>> use w,h + scanstride here an skip all clarification about logical
>>>>> coordinates?
>>>>
>>>> Originally, Jim suggested to generalize the API:
>>>>
>>>> <<Rather than imply any parameters, I think specifying a very exact
>>>> set of parameters gives the most flexibility.  Even if the
>>>> relationships you characterize above are true, xywh,scan or
>>>> off,wh,scan both provide the flexibility to supply the data in those
>>>> formats without the client having to guess dimensions or scan size.
>>>> Any API that specifies an array containing data should always
>>>> provide the flexibility of specifying an offset (and x,y is a way of
>>>> specifying an offset for rectangular data and using a nio Buffer can
>>>> implicitly imply an offset based on its position) and when that data
>>>> is a rectangle of data then it should also supply independent w,h
>>>> and scan strides.  If the offset is always 0, and if the scanstride
>>>> is always w in the implementation's that choose the data storage
>>>> then it may seem like overkill, but it provides the flexibility of
>>>> switching to a more sophisticated buffer re-use strategy later
>>>> without having to track down every client and update them... >>
>>>>
>>>> and so we provide all the coordinates.
>>> I understand why we need x/y/w/h/scanstride but why we need scale,
>>> because our buffer is pixel based anyway? In this case we have to
>>> convert w/h/x/y/scanstride from logical to pixels and back.
>>
>> The reasoning for that if the following. On the client side
>> (SwingNode), during the rendering of the image, there's a need to have
>> logical bounds of the image. So, this would require conversion
>> (devision)  for what the client would need to know the scale factor
>> for what it would need to ask for it, separately. This would bring
>> another code path & dependencies (for instance, b/w SwingNode and its
>> prism peer). Currently, there's only one parameter of a method for
>> that purpose.
> Ok. Here is an updated version:
> http://cr.openjdk.java.net/~serb/8029455/webrev.02
>>
>> Thanks,
>> Anton.
>>
>>>
>>>>
>>>> Thanks,
>>>> Anton.
>>>>
>>>>>
>>>>>>
>>>>>> BTW, I've applied your fix and tested it with the latest version
>>>>>> of FX changes, and everything works smoothly on my Mac, including
>>>>>> the display change listener.
>>>>>>
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 5/21/2014 7:46 PM, Sergey Bylokhov wrote:
>>>>>>> Hello, Everybody.
>>>>>>> Please review an updated version of this fix. This is a minimum
>>>>>>> possible
>>>>>>> fix. changes in shared code of jdk are minimized and can be
>>>>>>> enhanced in
>>>>>>> the future.
>>>>>>> The fix is covering hdpi support in SwingNode on osx + system
>>>>>>> look and
>>>>>>> feel(Aqua).
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~serb/8029455/webrev.01
>>>>>>>
>>>>>>> Notes:
>>>>>>>   - This fix depends from two other fixes: JDK- 8041129 and
>>>>>>> JDK-8041644.
>>>>>>> Both are under review on 2d alias.
>>>>>>>
>>>>>>> On 5/13/14 9:29 PM, Anthony Petrov wrote:
>>>>>>>> Hi Jim, Sergey, and Anton,
>>>>>>>>
>>>>>>>> I'd like to revive this old thread and finally push this fix, which
>>>>>>>> has been reviewed and approved on this mailing list back in
>>>>>>>> February.
>>>>>>>> The only additional change that I want to introduce, is the
>>>>>>>> addition
>>>>>>>> of default implementations for the
>>>>>>>> LightweightContent.imageBufferReset() methods. This allows
>>>>>>>> clients of
>>>>>>>> the API (namely, JavaFX) to run with both the old and the new
>>>>>>>> JDK w/o
>>>>>>>> any changes or side-effects. Here's the updated webrev:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/
>>>>>>>>
>>>>>>>> It literally only adds the default methods and doesn't make any
>>>>>>>> other
>>>>>>>> changes to the rest of the already reviewed code. I've tested
>>>>>>>> this on
>>>>>>>> both hiDPI and loDPI displays, with both old and hiDPI-aware JavaFX
>>>>>>>> builds, and it works fine in all the cases.
>>>>>>>>
>>>>>>>> The current plan is to push this fix to JDK 9, and then
>>>>>>>> back-port the
>>>>>>>> changes to 8u20.
>>>>>>>>
>>>>>>>> --
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>>
>>>>>>>> On 2/21/2014 2:47 AM, Jim Graham wrote:
>>>>>>>>> Yes, approved.
>>>>>>>>>
>>>>>>>>>          ...jim
>>>>>>>>>
>>>>>>>>> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>>>>>>>>>> Jim, so this is ready for a push then.
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>> Anton.
>>>>>>>>>>
>>>>>>>>>> On 15.02.2014 5:01, Jim Graham wrote:
>>>>>>>>>>> I don't need to see an update for that.  I didn't read the
>>>>>>>>>>> entire
>>>>>>>>>>> webrev, but I looked at this one piece of code and if that
>>>>>>>>>>> was the
>>>>>>>>>>> only thing changed then I think that dealt with the outstanding
>>>>>>>>>>> issues...
>>>>>>>>>>>
>>>>>>>>>>>         ...jim
>>>>>>>>>>>
>>>>>>>>>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>>>>>>>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>>>>>>>>>> Hi Jim,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please, look at the update:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here I'm correcting the rect after the transform in SG2D:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2123         // In case of negative scale transform,
>>>>>>>>>>>>>> reflect the
>>>>>>>>>>>>>> rect
>>>>>>>>>>>>>> coords.
>>>>>>>>>>>>>> 2124         if (w < 0) {
>>>>>>>>>>>>>> 2125             w *= -1;
>>>>>>>>>>>>>> 2126             x -= w;
>>>>>>>>>>>>>> 2127         }
>>>>>>>>>>>>>> 2128         if (h < 0) {
>>>>>>>>>>>>>> 2129             h *= -1;
>>>>>>>>>>>>>> 2130             y -= h;
>>>>>>>>>>>>>> 2131         }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The blit direction (dx, dy) remains transformed. Is this
>>>>>>>>>>>>>> the right
>>>>>>>>>>>>>> behavior from your perspective?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, that looks good.  I wonder if the "w *= -1" results in a
>>>>>>>>>>>>> multiply
>>>>>>>>>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>>>>>>>>>
>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>
>>>>>>>>>>>> Jim,
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, this indeed results in different byte code instructions
>>>>>>>>>>>> (imult &
>>>>>>>>>>>> ineg). Just for curiosity I did some measuring which showed
>>>>>>>>>>>> negatioation
>>>>>>>>>>>> worked 10% faster :)
>>>>>>>>>>>> Well, I'll fix it but let me please not send an update...
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>> Anton.
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From anthony.petrov at oracle.com  Thu May 22 20:48:14 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 23 May 2014 00:48:14 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: Allow using the system libjpeg
In-Reply-To: <20140522202808.GJ2825@redhat.com>
References: <20140517004529.GD4370@redhat.com>
	<537A509E.2090504@oracle.com>	<20140520171120.GD2672@redhat.com>	<113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com>	<20140521205934.GE3957@redhat.com>	<1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com>	<20140522004931.GG3957@redhat.com>
	<537E57BC.2010400@oracle.com> <20140522202808.GJ2825@redhat.com>
Message-ID: <537E628E.7070900@oracle.com>

I think that it would be useful to have a bug id prior to sending a 
review request, so that a review thread for the bug can be easily found 
in the mailing archive. In the future, please do file a bug first and 
put its id in the subject line of your review requests.

--
best regards,
Anthony

On 5/23/2014 12:28 AM, Omair Majid wrote:
> * Phil Race <philip.race at oracle.com> [2014-05-22 16:02]:
>> BTW .. I just realised I haven't seen a bug ID in this thread.
>> Does one already exist ?
>
> No. I was going to create one before I push.
>
> Thanks,
> Omair
>


From omajid at redhat.com  Thu May 22 21:01:28 2014
From: omajid at redhat.com (Omair Majid)
Date: Thu, 22 May 2014 17:01:28 -0400
Subject: [OpenJDK 2D-Dev] RFR: 8043805: Allow using a system-installed
	libjpeg
In-Reply-To: <537E628E.7070900@oracle.com>
References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com>
	<20140520171120.GD2672@redhat.com>
	<113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com>
	<20140521205934.GE3957@redhat.com>
	<1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com>
	<20140522004931.GG3957@redhat.com> <537E57BC.2010400@oracle.com>
	<20140522202808.GJ2825@redhat.com> <537E628E.7070900@oracle.com>
Message-ID: <20140522210127.GK2825@redhat.com>

* Anthony Petrov <anthony.petrov at oracle.com> [2014-05-22 16:48]:
> I think that it would be useful to have a bug id prior to sending a review
> request, so that a review thread for the bug can be easily found in the
> mailing archive. In the future, please do file a bug first and put its id in
> the subject line of your review requests.

Apologies.

I have filed https://bugs.openjdk.java.net/browse/JDK-8043805 and
updated the subject of the thread.

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681


From anthony.petrov at oracle.com  Thu May 22 21:27:56 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 23 May 2014 01:27:56 +0400
Subject: [OpenJDK 2D-Dev] RFR: 8043805: Allow using a system-installed
	libjpeg
In-Reply-To: <20140522210127.GK2825@redhat.com>
References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com>
	<20140520171120.GD2672@redhat.com>
	<113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com>
	<20140521205934.GE3957@redhat.com>
	<1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com>
	<20140522004931.GG3957@redhat.com> <537E57BC.2010400@oracle.com>
	<20140522202808.GJ2825@redhat.com> <537E628E.7070900@oracle.com>
	<20140522210127.GK2825@redhat.com>
Message-ID: <537E6BDC.3020301@oracle.com>

Thanks, Omair.

--
best regards,
Anthony

On 5/23/2014 1:01 AM, Omair Majid wrote:
> * Anthony Petrov <anthony.petrov at oracle.com> [2014-05-22 16:48]:
>> I think that it would be useful to have a bug id prior to sending a review
>> request, so that a review thread for the bug can be easily found in the
>> mailing archive. In the future, please do file a bug first and put its id in
>> the subject line of your review requests.
>
> Apologies.
>
> I have filed https://bugs.openjdk.java.net/browse/JDK-8043805 and
> updated the subject of the thread.
>
> Thanks,
> Omair
>


From philip.race at oracle.com  Thu May 22 21:39:20 2014
From: philip.race at oracle.com (Phil Race)
Date: Thu, 22 May 2014 14:39:20 -0700
Subject: [OpenJDK 2D-Dev] Please check these two 8u20 backports for 2 ICU
 fixes 8042850 and 8042855
Message-ID: <537E6E88.6040901@oracle.com>

JDK 9 changeset : 
http://hg.openjdk.java.net/jdk9/client/jdk/rev/006f772bbc7e
Identical JDK 8 backport: http://cr.openjdk.java.net/~prr/8042850
JDK 9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/006f772bbc7e
Identical JDK 8 backport: http://cr.openjdk.java.net/~prr/8042855

-phil.


From philip.race at oracle.com  Thu May 22 21:45:50 2014
From: philip.race at oracle.com (Phil Race)
Date: Thu, 22 May 2014 14:45:50 -0700
Subject: [OpenJDK 2D-Dev] Please check these two 8u20 backports for 2
 ICU fixes 8042850 and 8042855
In-Reply-To: <537E6E88.6040901@oracle.com>
References: <537E6E88.6040901@oracle.com>
Message-ID: <537E700E.3040003@oracle.com>

On 5/22/14 2:39 PM, Phil Race wrote:
> JDK 9 changeset : 
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/006f772bbc7e

Sorry copy paste problems that should have been
http://hg.openjdk.java.net/jdk9/client/jdk/rev/be332c33c5a0
> Identical JDK 8 backport: http://cr.openjdk.java.net/~prr/8042850
> JDK 9 changeset: 
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/006f772bbc7e
> Identical JDK 8 backport: http://cr.openjdk.java.net/~prr/8042855
>
> -phil.



From jennifer.godinez at oracle.com  Thu May 22 22:55:23 2014
From: jennifer.godinez at oracle.com (Jennifer Godinez)
Date: Thu, 22 May 2014 15:55:23 -0700
Subject: [OpenJDK 2D-Dev] Please check these two 8u20 backports for 2
 ICU fixes 8042850 and 8042855
In-Reply-To: <537E700E.3040003@oracle.com>
References: <537E6E88.6040901@oracle.com> <537E700E.3040003@oracle.com>
Message-ID: <537E805B.5040307@oracle.com>

Checked.  They are identical.
- Jennifer
On 5/22/2014 2:45 PM, Phil Race wrote:
> On 5/22/14 2:39 PM, Phil Race wrote:
>> JDK 9 changeset : 
>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/006f772bbc7e
>
> Sorry copy paste problems that should have been
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/be332c33c5a0
>> Identical JDK 8 backport: http://cr.openjdk.java.net/~prr/8042850
>> JDK 9 changeset: 
>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/006f772bbc7e
>> Identical JDK 8 backport: http://cr.openjdk.java.net/~prr/8042855
>>
>> -phil.
>



From anton.tarasov at oracle.com  Fri May 23 10:11:49 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Fri, 23 May 2014 14:11:49 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <537E3C72.3010607@oracle.com>
References: <52A723B8.7090705@oracle.com> <52AA3E92.7040302@oracle.com>
	<52B09644.6050201@oracle.com> <52B0F447.2020207@oracle.com>
	<52DE761E.2000201@oracle.com> <52E192F0.7010107@oracle.com>
	<52E27CDA.40703@oracle.com> <52E31866.3010508@oracle.com>
	<52E7CE5B.4070101@oracle.com> <52EAD304.2090809@oracle.com>
	<52EBB516.70906@oracle.com> <52EC4F5E.7060906@oracle.com>
	<52EFA980.6000404@oracle.com> <52F580C1.3020906@oracle.com>
	<52F8DE2A.4080304@oracle.com> <52F962CD.2050301@oracle.com>
	<52F96AE2.10106@oracle.com> <52FA67A8.1010600@oracle.com>
	<52FA7DCD.80405@oracle.com> <52FCC28D.5010007@oracle.com>
	<52FD4CB6.2090805@oracle.com> <52FDC1D1.8050907@oracle.com>
	<52FEBC4E.9010202@oracle.com> <5302182D.3070600@oracle.com>
	<53068600.80501@oracle.com> <53725695.40209@oracle.com>
	<537CCA57.4050200@oracle.com> <537CECB4.7080706@oracle.com>
	<537D1E3C.9090309@oracle.com> <537DAB80.1090106@oracle.com>
	<537DE14F.4070603@oracle.com> <537E02A1.3050303@oracle.com>
	<537E3C72.3010607@oracle.com>
Message-ID: <537F1EE5.5070002@oracle.com>

Hi Sergey,

Thanks for the update. I'm fine with the fix, except one thing. (I'm sorry that I didn't say that 
earlier).

My concern is that we have the LightweightContent iface which is used to communicate to the client 
app. And so the method

LightweightFrame.getHostBounds()

is better to be a method of that iface which the client (SwingNode) will implement on its side. In 
that case we won't need the LightweightFrame.setHostBounds() method.

This would look consistent from my perspective.

Thanks,
Anton.

On 22.05.2014 22:05, Sergey Bylokhov wrote:
> On 5/22/14 5:58 PM, Anton V. Tarasov wrote:
>> On 22.05.2014 15:36, Sergey Bylokhov wrote:
>>> On 5/22/14 11:47 AM, Anton V. Tarasov wrote:
>>>> Hi Sergey,
>>>>
>>>> On 22.05.2014 1:44, Sergey Bylokhov wrote:
>>>>> On 5/21/14 10:13 PM, Anthony Petrov wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> The original fix provides some updates and clarifications to the javadoc for the 
>>>>>> LightweightContent.imageBufferReset() method, but they are missing from your fix. Is this 
>>>>>> intentional?
>>>>> Nope. I just missed this update. I looked at this method closely and got a question: do we 
>>>>> need this scale parameter? Why we cannot use w,h + scanstride here an skip all clarification 
>>>>> about logical coordinates?
>>>>
>>>> Originally, Jim suggested to generalize the API:
>>>>
>>>> <<Rather than imply any parameters, I think specifying a very exact set of parameters gives the 
>>>> most flexibility. Even if the relationships you characterize above are true, xywh,scan or 
>>>> off,wh,scan both provide the flexibility to supply the data in those formats without the client 
>>>> having to guess dimensions or scan size. Any API that specifies an array containing data should 
>>>> always provide the flexibility of specifying an offset (and x,y is a way of specifying an 
>>>> offset for rectangular data and using a nio Buffer can implicitly imply an offset based on its 
>>>> position) and when that data is a rectangle of data then it should also supply independent w,h 
>>>> and scan strides.  If the offset is always 0, and if the scanstride is always w in the 
>>>> implementation's that choose the data storage then it may seem like overkill, but it provides 
>>>> the flexibility of switching to a more sophisticated buffer re-use strategy later without 
>>>> having to track down every client and update them... >>
>>>>
>>>> and so we provide all the coordinates.
>>> I understand why we need x/y/w/h/scanstride but why we need scale, because our buffer is pixel 
>>> based anyway? In this case we have to convert w/h/x/y/scanstride from logical to pixels and back.
>>
>> The reasoning for that if the following. On the client side (SwingNode), during the rendering of 
>> the image, there's a need to have logical bounds of the image. So, this would require conversion 
>> (devision)  for what the client would need to know the scale factor for what it would need to ask 
>> for it, separately. This would bring another code path & dependencies (for instance, b/w 
>> SwingNode and its prism peer). Currently, there's only one parameter of a method for that purpose.
> Ok. Here is an updated version:
> http://cr.openjdk.java.net/~serb/8029455/webrev.02
>>
>> Thanks,
>> Anton.
>>
>>>
>>>>
>>>> Thanks,
>>>> Anton.
>>>>
>>>>>
>>>>>>
>>>>>> BTW, I've applied your fix and tested it with the latest version of FX changes, and 
>>>>>> everything works smoothly on my Mac, including the display change listener.
>>>>>>
>>>>>> -- 
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 5/21/2014 7:46 PM, Sergey Bylokhov wrote:
>>>>>>> Hello, Everybody.
>>>>>>> Please review an updated version of this fix. This is a minimum possible
>>>>>>> fix. changes in shared code of jdk are minimized and can be enhanced in
>>>>>>> the future.
>>>>>>> The fix is covering hdpi support in SwingNode on osx + system look and
>>>>>>> feel(Aqua).
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~serb/8029455/webrev.01
>>>>>>>
>>>>>>> Notes:
>>>>>>>   - This fix depends from two other fixes: JDK- 8041129 and JDK-8041644.
>>>>>>> Both are under review on 2d alias.
>>>>>>>
>>>>>>> On 5/13/14 9:29 PM, Anthony Petrov wrote:
>>>>>>>> Hi Jim, Sergey, and Anton,
>>>>>>>>
>>>>>>>> I'd like to revive this old thread and finally push this fix, which
>>>>>>>> has been reviewed and approved on this mailing list back in February.
>>>>>>>> The only additional change that I want to introduce, is the addition
>>>>>>>> of default implementations for the
>>>>>>>> LightweightContent.imageBufferReset() methods. This allows clients of
>>>>>>>> the API (namely, JavaFX) to run with both the old and the new JDK w/o
>>>>>>>> any changes or side-effects. Here's the updated webrev:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/
>>>>>>>>
>>>>>>>> It literally only adds the default methods and doesn't make any other
>>>>>>>> changes to the rest of the already reviewed code. I've tested this on
>>>>>>>> both hiDPI and loDPI displays, with both old and hiDPI-aware JavaFX
>>>>>>>> builds, and it works fine in all the cases.
>>>>>>>>
>>>>>>>> The current plan is to push this fix to JDK 9, and then back-port the
>>>>>>>> changes to 8u20.
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>>
>>>>>>>> On 2/21/2014 2:47 AM, Jim Graham wrote:
>>>>>>>>> Yes, approved.
>>>>>>>>>
>>>>>>>>>          ...jim
>>>>>>>>>
>>>>>>>>> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>>>>>>>>>> Jim, so this is ready for a push then.
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>> Anton.
>>>>>>>>>>
>>>>>>>>>> On 15.02.2014 5:01, Jim Graham wrote:
>>>>>>>>>>> I don't need to see an update for that.  I didn't read the entire
>>>>>>>>>>> webrev, but I looked at this one piece of code and if that was the
>>>>>>>>>>> only thing changed then I think that dealt with the outstanding
>>>>>>>>>>> issues...
>>>>>>>>>>>
>>>>>>>>>>>         ...jim
>>>>>>>>>>>
>>>>>>>>>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>>>>>>>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>>>>>>>>>> Hi Jim,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please, look at the update:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here I'm correcting the rect after the transform in SG2D:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2123         // In case of negative scale transform, reflect the
>>>>>>>>>>>>>> rect
>>>>>>>>>>>>>> coords.
>>>>>>>>>>>>>> 2124         if (w < 0) {
>>>>>>>>>>>>>> 2125             w *= -1;
>>>>>>>>>>>>>> 2126             x -= w;
>>>>>>>>>>>>>> 2127         }
>>>>>>>>>>>>>> 2128         if (h < 0) {
>>>>>>>>>>>>>> 2129             h *= -1;
>>>>>>>>>>>>>> 2130             y -= h;
>>>>>>>>>>>>>> 2131         }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The blit direction (dx, dy) remains transformed. Is this the right
>>>>>>>>>>>>>> behavior from your perspective?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, that looks good.  I wonder if the "w *= -1" results in a
>>>>>>>>>>>>> multiply
>>>>>>>>>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>>>>>>>>>
>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>
>>>>>>>>>>>> Jim,
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, this indeed results in different byte code instructions (imult &
>>>>>>>>>>>> ineg). Just for curiosity I did some measuring which showed
>>>>>>>>>>>> negatioation
>>>>>>>>>>>> worked 10% faster :)
>>>>>>>>>>>> Well, I'll fix it but let me please not send an update...
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>> Anton.
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>



From anthony.petrov at oracle.com  Fri May 23 10:47:29 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 23 May 2014 14:47:29 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <537F1EE5.5070002@oracle.com>
References: <52A723B8.7090705@oracle.com> <52B09644.6050201@oracle.com>
	<52B0F447.2020207@oracle.com> <52DE761E.2000201@oracle.com>
	<52E192F0.7010107@oracle.com> <52E27CDA.40703@oracle.com>
	<52E31866.3010508@oracle.com> <52E7CE5B.4070101@oracle.com>
	<52EAD304.2090809@oracle.com> <52EBB516.70906@oracle.com>
	<52EC4F5E.7060906@oracle.com> <52EFA980.6000404@oracle.com>
	<52F580C1.3020906@oracle.com> <52F8DE2A.4080304@oracle.com>
	<52F962CD.2050301@oracle.com> <52F96AE2.10106@oracle.com>
	<52FA67A8.1010600@oracle.com> <52FA7DCD.80405@oracle.com>
	<52FCC28D.5010007@oracle.com> <52FD4CB6.2090805@oracle.com>
	<52FDC1D1.8050907@oracle.com> <52FEBC4E.9010202@oracle.com>
	<5302182D.3070600@oracle.com> <53068600.80501@oracle.com>
	<53725695.40209@oracle.com> <537CCA57.4050200@oracle.com>
	<537CECB4.7080706@oracle.com> <537D1E3C.9090309@oracle.com>
	<537DAB80.1090106@oracle.com> <537DE14F.4070603@oracle.com>
	<537E02A1.3050303@oracle.com> <537E3C72.3010607@oracle.com>
	<537F1EE5.5070002@oracle.com>
Message-ID: <537F2741.2090609@oracle.com>

Hi Anton,

I disagree, and here's my arguments:

1. The host bounds are not related to the /content/. Hence, adding this 
method to the LightweightContent interface would look inconsistent from 
API perspective.

2. Given the requirement to keep backward compatibility, the default 
implementation of the method would return 'null', so the calling code 
would have to check the return value and fall back to calling 
LF.getBounds() manually. Currently this logic is encapsulated in the 
LightweightFrame class itself, which looks reasonable to me.

3. SwingNode already calls other APIs on LF, such as 
notifyDisplayChanged() (and again, this particular notification is 
unrelated to the /content/ itself.) So adding the setHostBounds() to LF 
looks consistent from this perspective, too.

4. The current implementation of the getHostBounds() method simply 
returns a new rectangles using cached values. If we implement your 
suggestion, then every call to CPLWW.getGraphicsDevice() would involve 
an additional call to the SwingNode code, which may impact the 
performance slightly.

5. I was almost ready to push the FX part of the fix today, and let's 
admit it, this fix is very well overdue. I'd prefer if we don't modify 
the interface anymore.

--
best regards,
Anthony

On 5/23/2014 2:11 PM, Anton V. Tarasov wrote:
> Hi Sergey,
>
> Thanks for the update. I'm fine with the fix, except one thing. (I'm
> sorry that I didn't say that earlier).
>
> My concern is that we have the LightweightContent iface which is used to
> communicate to the client app. And so the method
>
> LightweightFrame.getHostBounds()
>
> is better to be a method of that iface which the client (SwingNode) will
> implement on its side. In that case we won't need the
> LightweightFrame.setHostBounds() method.
>
> This would look consistent from my perspective.
>
> Thanks,
> Anton.
>
> On 22.05.2014 22:05, Sergey Bylokhov wrote:
>> On 5/22/14 5:58 PM, Anton V. Tarasov wrote:
>>> On 22.05.2014 15:36, Sergey Bylokhov wrote:
>>>> On 5/22/14 11:47 AM, Anton V. Tarasov wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> On 22.05.2014 1:44, Sergey Bylokhov wrote:
>>>>>> On 5/21/14 10:13 PM, Anthony Petrov wrote:
>>>>>>> Hi Sergey,
>>>>>>>
>>>>>>> The original fix provides some updates and clarifications to the
>>>>>>> javadoc for the LightweightContent.imageBufferReset() method, but
>>>>>>> they are missing from your fix. Is this intentional?
>>>>>> Nope. I just missed this update. I looked at this method closely
>>>>>> and got a question: do we need this scale parameter? Why we cannot
>>>>>> use w,h + scanstride here an skip all clarification about logical
>>>>>> coordinates?
>>>>>
>>>>> Originally, Jim suggested to generalize the API:
>>>>>
>>>>> <<Rather than imply any parameters, I think specifying a very exact
>>>>> set of parameters gives the most flexibility. Even if the
>>>>> relationships you characterize above are true, xywh,scan or
>>>>> off,wh,scan both provide the flexibility to supply the data in
>>>>> those formats without the client having to guess dimensions or scan
>>>>> size. Any API that specifies an array containing data should always
>>>>> provide the flexibility of specifying an offset (and x,y is a way
>>>>> of specifying an offset for rectangular data and using a nio Buffer
>>>>> can implicitly imply an offset based on its position) and when that
>>>>> data is a rectangle of data then it should also supply independent
>>>>> w,h and scan strides.  If the offset is always 0, and if the
>>>>> scanstride is always w in the implementation's that choose the data
>>>>> storage then it may seem like overkill, but it provides the
>>>>> flexibility of switching to a more sophisticated buffer re-use
>>>>> strategy later without having to track down every client and update
>>>>> them... >>
>>>>>
>>>>> and so we provide all the coordinates.
>>>> I understand why we need x/y/w/h/scanstride but why we need scale,
>>>> because our buffer is pixel based anyway? In this case we have to
>>>> convert w/h/x/y/scanstride from logical to pixels and back.
>>>
>>> The reasoning for that if the following. On the client side
>>> (SwingNode), during the rendering of the image, there's a need to
>>> have logical bounds of the image. So, this would require conversion
>>> (devision)  for what the client would need to know the scale factor
>>> for what it would need to ask for it, separately. This would bring
>>> another code path & dependencies (for instance, b/w SwingNode and its
>>> prism peer). Currently, there's only one parameter of a method for
>>> that purpose.
>> Ok. Here is an updated version:
>> http://cr.openjdk.java.net/~serb/8029455/webrev.02
>>>
>>> Thanks,
>>> Anton.
>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Anton.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> BTW, I've applied your fix and tested it with the latest version
>>>>>>> of FX changes, and everything works smoothly on my Mac, including
>>>>>>> the display change listener.
>>>>>>>
>>>>>>> --
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>>
>>>>>>> On 5/21/2014 7:46 PM, Sergey Bylokhov wrote:
>>>>>>>> Hello, Everybody.
>>>>>>>> Please review an updated version of this fix. This is a minimum
>>>>>>>> possible
>>>>>>>> fix. changes in shared code of jdk are minimized and can be
>>>>>>>> enhanced in
>>>>>>>> the future.
>>>>>>>> The fix is covering hdpi support in SwingNode on osx + system
>>>>>>>> look and
>>>>>>>> feel(Aqua).
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~serb/8029455/webrev.01
>>>>>>>>
>>>>>>>> Notes:
>>>>>>>>   - This fix depends from two other fixes: JDK- 8041129 and
>>>>>>>> JDK-8041644.
>>>>>>>> Both are under review on 2d alias.
>>>>>>>>
>>>>>>>> On 5/13/14 9:29 PM, Anthony Petrov wrote:
>>>>>>>>> Hi Jim, Sergey, and Anton,
>>>>>>>>>
>>>>>>>>> I'd like to revive this old thread and finally push this fix,
>>>>>>>>> which
>>>>>>>>> has been reviewed and approved on this mailing list back in
>>>>>>>>> February.
>>>>>>>>> The only additional change that I want to introduce, is the
>>>>>>>>> addition
>>>>>>>>> of default implementations for the
>>>>>>>>> LightweightContent.imageBufferReset() methods. This allows
>>>>>>>>> clients of
>>>>>>>>> the API (namely, JavaFX) to run with both the old and the new
>>>>>>>>> JDK w/o
>>>>>>>>> any changes or side-effects. Here's the updated webrev:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/
>>>>>>>>>
>>>>>>>>> It literally only adds the default methods and doesn't make any
>>>>>>>>> other
>>>>>>>>> changes to the rest of the already reviewed code. I've tested
>>>>>>>>> this on
>>>>>>>>> both hiDPI and loDPI displays, with both old and hiDPI-aware
>>>>>>>>> JavaFX
>>>>>>>>> builds, and it works fine in all the cases.
>>>>>>>>>
>>>>>>>>> The current plan is to push this fix to JDK 9, and then
>>>>>>>>> back-port the
>>>>>>>>> changes to 8u20.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> best regards,
>>>>>>>>> Anthony
>>>>>>>>>
>>>>>>>>> On 2/21/2014 2:47 AM, Jim Graham wrote:
>>>>>>>>>> Yes, approved.
>>>>>>>>>>
>>>>>>>>>>          ...jim
>>>>>>>>>>
>>>>>>>>>> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>>>>>>>>>>> Jim, so this is ready for a push then.
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>> Anton.
>>>>>>>>>>>
>>>>>>>>>>> On 15.02.2014 5:01, Jim Graham wrote:
>>>>>>>>>>>> I don't need to see an update for that.  I didn't read the
>>>>>>>>>>>> entire
>>>>>>>>>>>> webrev, but I looked at this one piece of code and if that
>>>>>>>>>>>> was the
>>>>>>>>>>>> only thing changed then I think that dealt with the outstanding
>>>>>>>>>>>> issues...
>>>>>>>>>>>>
>>>>>>>>>>>>         ...jim
>>>>>>>>>>>>
>>>>>>>>>>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>>>>>>>>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>>>>>>>>>>> Hi Jim,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please, look at the update:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here I'm correcting the rect after the transform in SG2D:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2123         // In case of negative scale transform,
>>>>>>>>>>>>>>> reflect the
>>>>>>>>>>>>>>> rect
>>>>>>>>>>>>>>> coords.
>>>>>>>>>>>>>>> 2124         if (w < 0) {
>>>>>>>>>>>>>>> 2125             w *= -1;
>>>>>>>>>>>>>>> 2126             x -= w;
>>>>>>>>>>>>>>> 2127         }
>>>>>>>>>>>>>>> 2128         if (h < 0) {
>>>>>>>>>>>>>>> 2129             h *= -1;
>>>>>>>>>>>>>>> 2130             y -= h;
>>>>>>>>>>>>>>> 2131         }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The blit direction (dx, dy) remains transformed. Is this
>>>>>>>>>>>>>>> the right
>>>>>>>>>>>>>>> behavior from your perspective?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, that looks good.  I wonder if the "w *= -1" results in a
>>>>>>>>>>>>>> multiply
>>>>>>>>>>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jim,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, this indeed results in different byte code
>>>>>>>>>>>>> instructions (imult &
>>>>>>>>>>>>> ineg). Just for curiosity I did some measuring which showed
>>>>>>>>>>>>> negatioation
>>>>>>>>>>>>> worked 10% faster :)
>>>>>>>>>>>>> Well, I'll fix it but let me please not send an update...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>> Anton.
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


From anton.tarasov at oracle.com  Fri May 23 11:12:02 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Fri, 23 May 2014 15:12:02 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <537F2741.2090609@oracle.com>
References: <52A723B8.7090705@oracle.com> <52B0F447.2020207@oracle.com>
	<52DE761E.2000201@oracle.com> <52E192F0.7010107@oracle.com>
	<52E27CDA.40703@oracle.com> <52E31866.3010508@oracle.com>
	<52E7CE5B.4070101@oracle.com> <52EAD304.2090809@oracle.com>
	<52EBB516.70906@oracle.com> <52EC4F5E.7060906@oracle.com>
	<52EFA980.6000404@oracle.com> <52F580C1.3020906@oracle.com>
	<52F8DE2A.4080304@oracle.com> <52F962CD.2050301@oracle.com>
	<52F96AE2.10106@oracle.com> <52FA67A8.1010600@oracle.com>
	<52FA7DCD.80405@oracle.com> <52FCC28D.5010007@oracle.com>
	<52FD4CB6.2090805@oracle.com> <52FDC1D1.8050907@oracle.com>
	<52FEBC4E.9010202@oracle.com> <5302182D.3070600@oracle.com>
	<53068600.80501@oracle.com> <53725695.40209@oracle.com>
	<537CCA57.4050200@oracle.com> <537CECB4.7080706@oracle.com>
	<537D1E3C.9090309@oracle.com> <537DAB80.1090106@oracle.com>
	<537DE14F.4070603@oracle.com> <537E02A1.3050303@oracle.com>
	<537E3C72.3010607@oracle.com> <537F1EE5.5070002@oracle.com>
	<537F2741.2090609@oracle.com>
Message-ID: <537F2D02.8020901@oracle.com>

On 23.05.2014 14:47, Anthony Petrov wrote:
> Hi Anton,
>
> I disagree, and here's my arguments:
>
> 1. The host bounds are not related to the /content/. Hence, adding this method to the 
> LightweightContent interface would look inconsistent from API perspective.

It's not strictly about content (the name of the interface is not good enough).

   32  * The interface by means of which the {@link JLightweightFrame} class
   33  * communicates to its client application.


>
> 2. Given the requirement to keep backward compatibility, the default implementation of the method 
> would return 'null', so the calling code would have to check the return value and fall back to 
> calling LF.getBounds() manually. Currently this logic is encapsulated in the LightweightFrame 
> class itself, which looks reasonable to me.
>
> 3. SwingNode already calls other APIs on LF, such as notifyDisplayChanged() (and again, this 
> particular notification is unrelated to the /content/ itself.) So adding the setHostBounds() to LF 
> looks consistent from this perspective, too.
>
> 4. The current implementation of the getHostBounds() method simply returns a new rectangles using 
> cached values. If we implement your suggestion, then every call to CPLWW.getGraphicsDevice() would 
> involve an additional call to the SwingNode code, which may impact the performance slightly.
>
> 5. I was almost ready to push the FX part of the fix today, and let's admit it, this fix is very 
> well overdue. I'd prefer if we don't modify the interface anymore.

Ok, this is about a matter of taste. The 5th point sounds strong enough for me, so I'm fine with the 
current version.

Thanks!
Anton.

>
> -- 
> best regards,
> Anthony
>
> On 5/23/2014 2:11 PM, Anton V. Tarasov wrote:
>> Hi Sergey,
>>
>> Thanks for the update. I'm fine with the fix, except one thing. (I'm
>> sorry that I didn't say that earlier).
>>
>> My concern is that we have the LightweightContent iface which is used to
>> communicate to the client app. And so the method
>>
>> LightweightFrame.getHostBounds()
>>
>> is better to be a method of that iface which the client (SwingNode) will
>> implement on its side. In that case we won't need the
>> LightweightFrame.setHostBounds() method.
>>
>> This would look consistent from my perspective.
>>
>> Thanks,
>> Anton.
>>
>> On 22.05.2014 22:05, Sergey Bylokhov wrote:
>>> On 5/22/14 5:58 PM, Anton V. Tarasov wrote:
>>>> On 22.05.2014 15:36, Sergey Bylokhov wrote:
>>>>> On 5/22/14 11:47 AM, Anton V. Tarasov wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> On 22.05.2014 1:44, Sergey Bylokhov wrote:
>>>>>>> On 5/21/14 10:13 PM, Anthony Petrov wrote:
>>>>>>>> Hi Sergey,
>>>>>>>>
>>>>>>>> The original fix provides some updates and clarifications to the
>>>>>>>> javadoc for the LightweightContent.imageBufferReset() method, but
>>>>>>>> they are missing from your fix. Is this intentional?
>>>>>>> Nope. I just missed this update. I looked at this method closely
>>>>>>> and got a question: do we need this scale parameter? Why we cannot
>>>>>>> use w,h + scanstride here an skip all clarification about logical
>>>>>>> coordinates?
>>>>>>
>>>>>> Originally, Jim suggested to generalize the API:
>>>>>>
>>>>>> <<Rather than imply any parameters, I think specifying a very exact
>>>>>> set of parameters gives the most flexibility. Even if the
>>>>>> relationships you characterize above are true, xywh,scan or
>>>>>> off,wh,scan both provide the flexibility to supply the data in
>>>>>> those formats without the client having to guess dimensions or scan
>>>>>> size. Any API that specifies an array containing data should always
>>>>>> provide the flexibility of specifying an offset (and x,y is a way
>>>>>> of specifying an offset for rectangular data and using a nio Buffer
>>>>>> can implicitly imply an offset based on its position) and when that
>>>>>> data is a rectangle of data then it should also supply independent
>>>>>> w,h and scan strides.  If the offset is always 0, and if the
>>>>>> scanstride is always w in the implementation's that choose the data
>>>>>> storage then it may seem like overkill, but it provides the
>>>>>> flexibility of switching to a more sophisticated buffer re-use
>>>>>> strategy later without having to track down every client and update
>>>>>> them... >>
>>>>>>
>>>>>> and so we provide all the coordinates.
>>>>> I understand why we need x/y/w/h/scanstride but why we need scale,
>>>>> because our buffer is pixel based anyway? In this case we have to
>>>>> convert w/h/x/y/scanstride from logical to pixels and back.
>>>>
>>>> The reasoning for that if the following. On the client side
>>>> (SwingNode), during the rendering of the image, there's a need to
>>>> have logical bounds of the image. So, this would require conversion
>>>> (devision)  for what the client would need to know the scale factor
>>>> for what it would need to ask for it, separately. This would bring
>>>> another code path & dependencies (for instance, b/w SwingNode and its
>>>> prism peer). Currently, there's only one parameter of a method for
>>>> that purpose.
>>> Ok. Here is an updated version:
>>> http://cr.openjdk.java.net/~serb/8029455/webrev.02
>>>>
>>>> Thanks,
>>>> Anton.
>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Anton.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> BTW, I've applied your fix and tested it with the latest version
>>>>>>>> of FX changes, and everything works smoothly on my Mac, including
>>>>>>>> the display change listener.
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>>
>>>>>>>> On 5/21/2014 7:46 PM, Sergey Bylokhov wrote:
>>>>>>>>> Hello, Everybody.
>>>>>>>>> Please review an updated version of this fix. This is a minimum
>>>>>>>>> possible
>>>>>>>>> fix. changes in shared code of jdk are minimized and can be
>>>>>>>>> enhanced in
>>>>>>>>> the future.
>>>>>>>>> The fix is covering hdpi support in SwingNode on osx + system
>>>>>>>>> look and
>>>>>>>>> feel(Aqua).
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~serb/8029455/webrev.01
>>>>>>>>>
>>>>>>>>> Notes:
>>>>>>>>>   - This fix depends from two other fixes: JDK- 8041129 and
>>>>>>>>> JDK-8041644.
>>>>>>>>> Both are under review on 2d alias.
>>>>>>>>>
>>>>>>>>> On 5/13/14 9:29 PM, Anthony Petrov wrote:
>>>>>>>>>> Hi Jim, Sergey, and Anton,
>>>>>>>>>>
>>>>>>>>>> I'd like to revive this old thread and finally push this fix,
>>>>>>>>>> which
>>>>>>>>>> has been reviewed and approved on this mailing list back in
>>>>>>>>>> February.
>>>>>>>>>> The only additional change that I want to introduce, is the
>>>>>>>>>> addition
>>>>>>>>>> of default implementations for the
>>>>>>>>>> LightweightContent.imageBufferReset() methods. This allows
>>>>>>>>>> clients of
>>>>>>>>>> the API (namely, JavaFX) to run with both the old and the new
>>>>>>>>>> JDK w/o
>>>>>>>>>> any changes or side-effects. Here's the updated webrev:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/
>>>>>>>>>>
>>>>>>>>>> It literally only adds the default methods and doesn't make any
>>>>>>>>>> other
>>>>>>>>>> changes to the rest of the already reviewed code. I've tested
>>>>>>>>>> this on
>>>>>>>>>> both hiDPI and loDPI displays, with both old and hiDPI-aware
>>>>>>>>>> JavaFX
>>>>>>>>>> builds, and it works fine in all the cases.
>>>>>>>>>>
>>>>>>>>>> The current plan is to push this fix to JDK 9, and then
>>>>>>>>>> back-port the
>>>>>>>>>> changes to 8u20.
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> best regards,
>>>>>>>>>> Anthony
>>>>>>>>>>
>>>>>>>>>> On 2/21/2014 2:47 AM, Jim Graham wrote:
>>>>>>>>>>> Yes, approved.
>>>>>>>>>>>
>>>>>>>>>>>          ...jim
>>>>>>>>>>>
>>>>>>>>>>> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>>>>>>>>>>>> Jim, so this is ready for a push then.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>> Anton.
>>>>>>>>>>>>
>>>>>>>>>>>> On 15.02.2014 5:01, Jim Graham wrote:
>>>>>>>>>>>>> I don't need to see an update for that.  I didn't read the
>>>>>>>>>>>>> entire
>>>>>>>>>>>>> webrev, but I looked at this one piece of code and if that
>>>>>>>>>>>>> was the
>>>>>>>>>>>>> only thing changed then I think that dealt with the outstanding
>>>>>>>>>>>>> issues...
>>>>>>>>>>>>>
>>>>>>>>>>>>>         ...jim
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>>>>>>>>>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>>>>>>>>>>>> Hi Jim,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please, look at the update:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Here I'm correcting the rect after the transform in SG2D:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2123         // In case of negative scale transform,
>>>>>>>>>>>>>>>> reflect the
>>>>>>>>>>>>>>>> rect
>>>>>>>>>>>>>>>> coords.
>>>>>>>>>>>>>>>> 2124         if (w < 0) {
>>>>>>>>>>>>>>>> 2125             w *= -1;
>>>>>>>>>>>>>>>> 2126             x -= w;
>>>>>>>>>>>>>>>> 2127         }
>>>>>>>>>>>>>>>> 2128         if (h < 0) {
>>>>>>>>>>>>>>>> 2129             h *= -1;
>>>>>>>>>>>>>>>> 2130             y -= h;
>>>>>>>>>>>>>>>> 2131         }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The blit direction (dx, dy) remains transformed. Is this
>>>>>>>>>>>>>>>> the right
>>>>>>>>>>>>>>>> behavior from your perspective?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes, that looks good.  I wonder if the "w *= -1" results in a
>>>>>>>>>>>>>>> multiply
>>>>>>>>>>>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jim,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, this indeed results in different byte code
>>>>>>>>>>>>>> instructions (imult &
>>>>>>>>>>>>>> ineg). Just for curiosity I did some measuring which showed
>>>>>>>>>>>>>> negatioation
>>>>>>>>>>>>>> worked 10% faster :)
>>>>>>>>>>>>>> Well, I'll fix it but let me please not send an update...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>> Anton.
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>



From anthony.petrov at oracle.com  Fri May 23 11:18:03 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 23 May 2014 15:18:03 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <537F2D02.8020901@oracle.com>
References: <52A723B8.7090705@oracle.com> <52DE761E.2000201@oracle.com>
	<52E192F0.7010107@oracle.com> <52E27CDA.40703@oracle.com>
	<52E31866.3010508@oracle.com> <52E7CE5B.4070101@oracle.com>
	<52EAD304.2090809@oracle.com> <52EBB516.70906@oracle.com>
	<52EC4F5E.7060906@oracle.com> <52EFA980.6000404@oracle.com>
	<52F580C1.3020906@oracle.com> <52F8DE2A.4080304@oracle.com>
	<52F962CD.2050301@oracle.com> <52F96AE2.10106@oracle.com>
	<52FA67A8.1010600@oracle.com> <52FA7DCD.80405@oracle.com>
	<52FCC28D.5010007@oracle.com> <52FD4CB6.2090805@oracle.com>
	<52FDC1D1.8050907@oracle.com> <52FEBC4E.9010202@oracle.com>
	<5302182D.3070600@oracle.com> <53068600.80501@oracle.com>
	<53725695.40209@oracle.com> <537CCA57.4050200@oracle.com>
	<537CECB4.7080706@oracle.com> <537D1E3C.9090309@oracle.com>
	<537DAB80.1090106@oracle.com> <537DE14F.4070603@oracle.com>
	<537E02A1.3050303@oracle.com> <537E3C72.3010607@oracle.com>
	<537F1EE5.5070002@oracle.com> <537F2741.2090609@oracle.com>
	<537F2D02.8020901@oracle.com>
Message-ID: <537F2E6B.3040309@oracle.com>

On 5/23/2014 3:12 PM, Anton V. Tarasov wrote:
> On 23.05.2014 14:47, Anthony Petrov wrote:
>> 1. The host bounds are not related to the /content/. Hence, adding
>> this method to the LightweightContent interface would look
>> inconsistent from API perspective.
>
> It's not strictly about content (the name of the interface is not good
> enough).
>
>    32  * The interface by means of which the {@link JLightweightFrame}
> class
>    33  * communicates to its client application.

Right. We might want to file a follow-up issue targeted for JDK/FX 9 and 
rename the interface/rearrange some APIs. However, personally, I don't 
feel this is strictly necessary at this time.

PS. I'll be pushing the FX part of the fix today. So we should consider 
the current interface frozen for now.

--
best regards,
Anthony

>
>
>>
>> 2. Given the requirement to keep backward compatibility, the default
>> implementation of the method would return 'null', so the calling code
>> would have to check the return value and fall back to calling
>> LF.getBounds() manually. Currently this logic is encapsulated in the
>> LightweightFrame class itself, which looks reasonable to me.
>>
>> 3. SwingNode already calls other APIs on LF, such as
>> notifyDisplayChanged() (and again, this particular notification is
>> unrelated to the /content/ itself.) So adding the setHostBounds() to
>> LF looks consistent from this perspective, too.
>>
>> 4. The current implementation of the getHostBounds() method simply
>> returns a new rectangles using cached values. If we implement your
>> suggestion, then every call to CPLWW.getGraphicsDevice() would involve
>> an additional call to the SwingNode code, which may impact the
>> performance slightly.
>>
>> 5. I was almost ready to push the FX part of the fix today, and let's
>> admit it, this fix is very well overdue. I'd prefer if we don't modify
>> the interface anymore.
>
> Ok, this is about a matter of taste. The 5th point sounds strong enough
> for me, so I'm fine with the current version.
>
> Thanks!
> Anton.
>
>>
>> --
>> best regards,
>> Anthony
>>
>> On 5/23/2014 2:11 PM, Anton V. Tarasov wrote:
>>> Hi Sergey,
>>>
>>> Thanks for the update. I'm fine with the fix, except one thing. (I'm
>>> sorry that I didn't say that earlier).
>>>
>>> My concern is that we have the LightweightContent iface which is used to
>>> communicate to the client app. And so the method
>>>
>>> LightweightFrame.getHostBounds()
>>>
>>> is better to be a method of that iface which the client (SwingNode) will
>>> implement on its side. In that case we won't need the
>>> LightweightFrame.setHostBounds() method.
>>>
>>> This would look consistent from my perspective.
>>>
>>> Thanks,
>>> Anton.
>>>
>>> On 22.05.2014 22:05, Sergey Bylokhov wrote:
>>>> On 5/22/14 5:58 PM, Anton V. Tarasov wrote:
>>>>> On 22.05.2014 15:36, Sergey Bylokhov wrote:
>>>>>> On 5/22/14 11:47 AM, Anton V. Tarasov wrote:
>>>>>>> Hi Sergey,
>>>>>>>
>>>>>>> On 22.05.2014 1:44, Sergey Bylokhov wrote:
>>>>>>>> On 5/21/14 10:13 PM, Anthony Petrov wrote:
>>>>>>>>> Hi Sergey,
>>>>>>>>>
>>>>>>>>> The original fix provides some updates and clarifications to the
>>>>>>>>> javadoc for the LightweightContent.imageBufferReset() method, but
>>>>>>>>> they are missing from your fix. Is this intentional?
>>>>>>>> Nope. I just missed this update. I looked at this method closely
>>>>>>>> and got a question: do we need this scale parameter? Why we cannot
>>>>>>>> use w,h + scanstride here an skip all clarification about logical
>>>>>>>> coordinates?
>>>>>>>
>>>>>>> Originally, Jim suggested to generalize the API:
>>>>>>>
>>>>>>> <<Rather than imply any parameters, I think specifying a very exact
>>>>>>> set of parameters gives the most flexibility. Even if the
>>>>>>> relationships you characterize above are true, xywh,scan or
>>>>>>> off,wh,scan both provide the flexibility to supply the data in
>>>>>>> those formats without the client having to guess dimensions or scan
>>>>>>> size. Any API that specifies an array containing data should always
>>>>>>> provide the flexibility of specifying an offset (and x,y is a way
>>>>>>> of specifying an offset for rectangular data and using a nio Buffer
>>>>>>> can implicitly imply an offset based on its position) and when that
>>>>>>> data is a rectangle of data then it should also supply independent
>>>>>>> w,h and scan strides.  If the offset is always 0, and if the
>>>>>>> scanstride is always w in the implementation's that choose the data
>>>>>>> storage then it may seem like overkill, but it provides the
>>>>>>> flexibility of switching to a more sophisticated buffer re-use
>>>>>>> strategy later without having to track down every client and update
>>>>>>> them... >>
>>>>>>>
>>>>>>> and so we provide all the coordinates.
>>>>>> I understand why we need x/y/w/h/scanstride but why we need scale,
>>>>>> because our buffer is pixel based anyway? In this case we have to
>>>>>> convert w/h/x/y/scanstride from logical to pixels and back.
>>>>>
>>>>> The reasoning for that if the following. On the client side
>>>>> (SwingNode), during the rendering of the image, there's a need to
>>>>> have logical bounds of the image. So, this would require conversion
>>>>> (devision)  for what the client would need to know the scale factor
>>>>> for what it would need to ask for it, separately. This would bring
>>>>> another code path & dependencies (for instance, b/w SwingNode and its
>>>>> prism peer). Currently, there's only one parameter of a method for
>>>>> that purpose.
>>>> Ok. Here is an updated version:
>>>> http://cr.openjdk.java.net/~serb/8029455/webrev.02
>>>>>
>>>>> Thanks,
>>>>> Anton.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Anton.
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> BTW, I've applied your fix and tested it with the latest version
>>>>>>>>> of FX changes, and everything works smoothly on my Mac, including
>>>>>>>>> the display change listener.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> best regards,
>>>>>>>>> Anthony
>>>>>>>>>
>>>>>>>>> On 5/21/2014 7:46 PM, Sergey Bylokhov wrote:
>>>>>>>>>> Hello, Everybody.
>>>>>>>>>> Please review an updated version of this fix. This is a minimum
>>>>>>>>>> possible
>>>>>>>>>> fix. changes in shared code of jdk are minimized and can be
>>>>>>>>>> enhanced in
>>>>>>>>>> the future.
>>>>>>>>>> The fix is covering hdpi support in SwingNode on osx + system
>>>>>>>>>> look and
>>>>>>>>>> feel(Aqua).
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~serb/8029455/webrev.01
>>>>>>>>>>
>>>>>>>>>> Notes:
>>>>>>>>>>   - This fix depends from two other fixes: JDK- 8041129 and
>>>>>>>>>> JDK-8041644.
>>>>>>>>>> Both are under review on 2d alias.
>>>>>>>>>>
>>>>>>>>>> On 5/13/14 9:29 PM, Anthony Petrov wrote:
>>>>>>>>>>> Hi Jim, Sergey, and Anton,
>>>>>>>>>>>
>>>>>>>>>>> I'd like to revive this old thread and finally push this fix,
>>>>>>>>>>> which
>>>>>>>>>>> has been reviewed and approved on this mailing list back in
>>>>>>>>>>> February.
>>>>>>>>>>> The only additional change that I want to introduce, is the
>>>>>>>>>>> addition
>>>>>>>>>>> of default implementations for the
>>>>>>>>>>> LightweightContent.imageBufferReset() methods. This allows
>>>>>>>>>>> clients of
>>>>>>>>>>> the API (namely, JavaFX) to run with both the old and the new
>>>>>>>>>>> JDK w/o
>>>>>>>>>>> any changes or side-effects. Here's the updated webrev:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It literally only adds the default methods and doesn't make any
>>>>>>>>>>> other
>>>>>>>>>>> changes to the rest of the already reviewed code. I've tested
>>>>>>>>>>> this on
>>>>>>>>>>> both hiDPI and loDPI displays, with both old and hiDPI-aware
>>>>>>>>>>> JavaFX
>>>>>>>>>>> builds, and it works fine in all the cases.
>>>>>>>>>>>
>>>>>>>>>>> The current plan is to push this fix to JDK 9, and then
>>>>>>>>>>> back-port the
>>>>>>>>>>> changes to 8u20.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> best regards,
>>>>>>>>>>> Anthony
>>>>>>>>>>>
>>>>>>>>>>> On 2/21/2014 2:47 AM, Jim Graham wrote:
>>>>>>>>>>>> Yes, approved.
>>>>>>>>>>>>
>>>>>>>>>>>>          ...jim
>>>>>>>>>>>>
>>>>>>>>>>>> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>>>>>>>>>>>>> Jim, so this is ready for a push then.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>> Anton.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 15.02.2014 5:01, Jim Graham wrote:
>>>>>>>>>>>>>> I don't need to see an update for that.  I didn't read the
>>>>>>>>>>>>>> entire
>>>>>>>>>>>>>> webrev, but I looked at this one piece of code and if that
>>>>>>>>>>>>>> was the
>>>>>>>>>>>>>> only thing changed then I think that dealt with the
>>>>>>>>>>>>>> outstanding
>>>>>>>>>>>>>> issues...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         ...jim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>>>>>>>>>>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>>>>>>>>>>>>> Hi Jim,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Please, look at the update:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Here I'm correcting the rect after the transform in SG2D:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2123         // In case of negative scale transform,
>>>>>>>>>>>>>>>>> reflect the
>>>>>>>>>>>>>>>>> rect
>>>>>>>>>>>>>>>>> coords.
>>>>>>>>>>>>>>>>> 2124         if (w < 0) {
>>>>>>>>>>>>>>>>> 2125             w *= -1;
>>>>>>>>>>>>>>>>> 2126             x -= w;
>>>>>>>>>>>>>>>>> 2127         }
>>>>>>>>>>>>>>>>> 2128         if (h < 0) {
>>>>>>>>>>>>>>>>> 2129             h *= -1;
>>>>>>>>>>>>>>>>> 2130             y -= h;
>>>>>>>>>>>>>>>>> 2131         }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The blit direction (dx, dy) remains transformed. Is this
>>>>>>>>>>>>>>>>> the right
>>>>>>>>>>>>>>>>> behavior from your perspective?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, that looks good.  I wonder if the "w *= -1" results
>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>> multiply
>>>>>>>>>>>>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jim,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes, this indeed results in different byte code
>>>>>>>>>>>>>>> instructions (imult &
>>>>>>>>>>>>>>> ineg). Just for curiosity I did some measuring which showed
>>>>>>>>>>>>>>> negatioation
>>>>>>>>>>>>>>> worked 10% faster :)
>>>>>>>>>>>>>>> Well, I'll fix it but let me please not send an update...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>> Anton.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>


From anton.tarasov at oracle.com  Fri May 23 11:21:59 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Fri, 23 May 2014 15:21:59 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <537F2E6B.3040309@oracle.com>
References: <52A723B8.7090705@oracle.com> <52E192F0.7010107@oracle.com>
	<52E27CDA.40703@oracle.com> <52E31866.3010508@oracle.com>
	<52E7CE5B.4070101@oracle.com> <52EAD304.2090809@oracle.com>
	<52EBB516.70906@oracle.com> <52EC4F5E.7060906@oracle.com>
	<52EFA980.6000404@oracle.com> <52F580C1.3020906@oracle.com>
	<52F8DE2A.4080304@oracle.com> <52F962CD.2050301@oracle.com>
	<52F96AE2.10106@oracle.com> <52FA67A8.1010600@oracle.com>
	<52FA7DCD.80405@oracle.com> <52FCC28D.5010007@oracle.com>
	<52FD4CB6.2090805@oracle.com> <52FDC1D1.8050907@oracle.com>
	<52FEBC4E.9010202@oracle.com> <5302182D.3070600@oracle.com>
	<53068600.80501@oracle.com> <53725695.40209@oracle.com>
	<537CCA57.4050200@oracle.com> <537CECB4.7080706@oracle.com>
	<537D1E3C.9090309@oracle.com> <537DAB80.1090106@oracle.com>
	<537DE14F.4070603@oracle.com> <537E02A1.3050303@oracle.com>
	<537E3C72.3010607@oracle.com> <537F1EE5.5070002@oracle.com>
	<537F2741.2090609@oracle.com> <537F2D02.8020901@oracle.com>
	<537F2E6B.3040309@oracle.com>
Message-ID: <537F2F57.4060604@oracle.com>

Ok, good!

Anton.

On 23.05.2014 15:18, Anthony Petrov wrote:
> On 5/23/2014 3:12 PM, Anton V. Tarasov wrote:
>> On 23.05.2014 14:47, Anthony Petrov wrote:
>>> 1. The host bounds are not related to the /content/. Hence, adding
>>> this method to the LightweightContent interface would look
>>> inconsistent from API perspective.
>>
>> It's not strictly about content (the name of the interface is not good
>> enough).
>>
>>    32  * The interface by means of which the {@link JLightweightFrame}
>> class
>>    33  * communicates to its client application.
>
> Right. We might want to file a follow-up issue targeted for JDK/FX 9 and rename the 
> interface/rearrange some APIs. However, personally, I don't feel this is strictly necessary at 
> this time.
>
> PS. I'll be pushing the FX part of the fix today. So we should consider the current interface 
> frozen for now.
>
> -- 
> best regards,
> Anthony
>
>>
>>
>>>
>>> 2. Given the requirement to keep backward compatibility, the default
>>> implementation of the method would return 'null', so the calling code
>>> would have to check the return value and fall back to calling
>>> LF.getBounds() manually. Currently this logic is encapsulated in the
>>> LightweightFrame class itself, which looks reasonable to me.
>>>
>>> 3. SwingNode already calls other APIs on LF, such as
>>> notifyDisplayChanged() (and again, this particular notification is
>>> unrelated to the /content/ itself.) So adding the setHostBounds() to
>>> LF looks consistent from this perspective, too.
>>>
>>> 4. The current implementation of the getHostBounds() method simply
>>> returns a new rectangles using cached values. If we implement your
>>> suggestion, then every call to CPLWW.getGraphicsDevice() would involve
>>> an additional call to the SwingNode code, which may impact the
>>> performance slightly.
>>>
>>> 5. I was almost ready to push the FX part of the fix today, and let's
>>> admit it, this fix is very well overdue. I'd prefer if we don't modify
>>> the interface anymore.
>>
>> Ok, this is about a matter of taste. The 5th point sounds strong enough
>> for me, so I'm fine with the current version.
>>
>> Thanks!
>> Anton.
>>
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 5/23/2014 2:11 PM, Anton V. Tarasov wrote:
>>>> Hi Sergey,
>>>>
>>>> Thanks for the update. I'm fine with the fix, except one thing. (I'm
>>>> sorry that I didn't say that earlier).
>>>>
>>>> My concern is that we have the LightweightContent iface which is used to
>>>> communicate to the client app. And so the method
>>>>
>>>> LightweightFrame.getHostBounds()
>>>>
>>>> is better to be a method of that iface which the client (SwingNode) will
>>>> implement on its side. In that case we won't need the
>>>> LightweightFrame.setHostBounds() method.
>>>>
>>>> This would look consistent from my perspective.
>>>>
>>>> Thanks,
>>>> Anton.
>>>>
>>>> On 22.05.2014 22:05, Sergey Bylokhov wrote:
>>>>> On 5/22/14 5:58 PM, Anton V. Tarasov wrote:
>>>>>> On 22.05.2014 15:36, Sergey Bylokhov wrote:
>>>>>>> On 5/22/14 11:47 AM, Anton V. Tarasov wrote:
>>>>>>>> Hi Sergey,
>>>>>>>>
>>>>>>>> On 22.05.2014 1:44, Sergey Bylokhov wrote:
>>>>>>>>> On 5/21/14 10:13 PM, Anthony Petrov wrote:
>>>>>>>>>> Hi Sergey,
>>>>>>>>>>
>>>>>>>>>> The original fix provides some updates and clarifications to the
>>>>>>>>>> javadoc for the LightweightContent.imageBufferReset() method, but
>>>>>>>>>> they are missing from your fix. Is this intentional?
>>>>>>>>> Nope. I just missed this update. I looked at this method closely
>>>>>>>>> and got a question: do we need this scale parameter? Why we cannot
>>>>>>>>> use w,h + scanstride here an skip all clarification about logical
>>>>>>>>> coordinates?
>>>>>>>>
>>>>>>>> Originally, Jim suggested to generalize the API:
>>>>>>>>
>>>>>>>> <<Rather than imply any parameters, I think specifying a very exact
>>>>>>>> set of parameters gives the most flexibility. Even if the
>>>>>>>> relationships you characterize above are true, xywh,scan or
>>>>>>>> off,wh,scan both provide the flexibility to supply the data in
>>>>>>>> those formats without the client having to guess dimensions or scan
>>>>>>>> size. Any API that specifies an array containing data should always
>>>>>>>> provide the flexibility of specifying an offset (and x,y is a way
>>>>>>>> of specifying an offset for rectangular data and using a nio Buffer
>>>>>>>> can implicitly imply an offset based on its position) and when that
>>>>>>>> data is a rectangle of data then it should also supply independent
>>>>>>>> w,h and scan strides.  If the offset is always 0, and if the
>>>>>>>> scanstride is always w in the implementation's that choose the data
>>>>>>>> storage then it may seem like overkill, but it provides the
>>>>>>>> flexibility of switching to a more sophisticated buffer re-use
>>>>>>>> strategy later without having to track down every client and update
>>>>>>>> them... >>
>>>>>>>>
>>>>>>>> and so we provide all the coordinates.
>>>>>>> I understand why we need x/y/w/h/scanstride but why we need scale,
>>>>>>> because our buffer is pixel based anyway? In this case we have to
>>>>>>> convert w/h/x/y/scanstride from logical to pixels and back.
>>>>>>
>>>>>> The reasoning for that if the following. On the client side
>>>>>> (SwingNode), during the rendering of the image, there's a need to
>>>>>> have logical bounds of the image. So, this would require conversion
>>>>>> (devision)  for what the client would need to know the scale factor
>>>>>> for what it would need to ask for it, separately. This would bring
>>>>>> another code path & dependencies (for instance, b/w SwingNode and its
>>>>>> prism peer). Currently, there's only one parameter of a method for
>>>>>> that purpose.
>>>>> Ok. Here is an updated version:
>>>>> http://cr.openjdk.java.net/~serb/8029455/webrev.02
>>>>>>
>>>>>> Thanks,
>>>>>> Anton.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Anton.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> BTW, I've applied your fix and tested it with the latest version
>>>>>>>>>> of FX changes, and everything works smoothly on my Mac, including
>>>>>>>>>> the display change listener.
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> best regards,
>>>>>>>>>> Anthony
>>>>>>>>>>
>>>>>>>>>> On 5/21/2014 7:46 PM, Sergey Bylokhov wrote:
>>>>>>>>>>> Hello, Everybody.
>>>>>>>>>>> Please review an updated version of this fix. This is a minimum
>>>>>>>>>>> possible
>>>>>>>>>>> fix. changes in shared code of jdk are minimized and can be
>>>>>>>>>>> enhanced in
>>>>>>>>>>> the future.
>>>>>>>>>>> The fix is covering hdpi support in SwingNode on osx + system
>>>>>>>>>>> look and
>>>>>>>>>>> feel(Aqua).
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8029455/webrev.01
>>>>>>>>>>>
>>>>>>>>>>> Notes:
>>>>>>>>>>>   - This fix depends from two other fixes: JDK- 8041129 and
>>>>>>>>>>> JDK-8041644.
>>>>>>>>>>> Both are under review on 2d alias.
>>>>>>>>>>>
>>>>>>>>>>> On 5/13/14 9:29 PM, Anthony Petrov wrote:
>>>>>>>>>>>> Hi Jim, Sergey, and Anton,
>>>>>>>>>>>>
>>>>>>>>>>>> I'd like to revive this old thread and finally push this fix,
>>>>>>>>>>>> which
>>>>>>>>>>>> has been reviewed and approved on this mailing list back in
>>>>>>>>>>>> February.
>>>>>>>>>>>> The only additional change that I want to introduce, is the
>>>>>>>>>>>> addition
>>>>>>>>>>>> of default implementations for the
>>>>>>>>>>>> LightweightContent.imageBufferReset() methods. This allows
>>>>>>>>>>>> clients of
>>>>>>>>>>>> the API (namely, JavaFX) to run with both the old and the new
>>>>>>>>>>>> JDK w/o
>>>>>>>>>>>> any changes or side-effects. Here's the updated webrev:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It literally only adds the default methods and doesn't make any
>>>>>>>>>>>> other
>>>>>>>>>>>> changes to the rest of the already reviewed code. I've tested
>>>>>>>>>>>> this on
>>>>>>>>>>>> both hiDPI and loDPI displays, with both old and hiDPI-aware
>>>>>>>>>>>> JavaFX
>>>>>>>>>>>> builds, and it works fine in all the cases.
>>>>>>>>>>>>
>>>>>>>>>>>> The current plan is to push this fix to JDK 9, and then
>>>>>>>>>>>> back-port the
>>>>>>>>>>>> changes to 8u20.
>>>>>>>>>>>>
>>>>>>>>>>>> -- 
>>>>>>>>>>>> best regards,
>>>>>>>>>>>> Anthony
>>>>>>>>>>>>
>>>>>>>>>>>> On 2/21/2014 2:47 AM, Jim Graham wrote:
>>>>>>>>>>>>> Yes, approved.
>>>>>>>>>>>>>
>>>>>>>>>>>>>          ...jim
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>>>>>>>>>>>>>> Jim, so this is ready for a push then.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>> Anton.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 15.02.2014 5:01, Jim Graham wrote:
>>>>>>>>>>>>>>> I don't need to see an update for that.  I didn't read the
>>>>>>>>>>>>>>> entire
>>>>>>>>>>>>>>> webrev, but I looked at this one piece of code and if that
>>>>>>>>>>>>>>> was the
>>>>>>>>>>>>>>> only thing changed then I think that dealt with the
>>>>>>>>>>>>>>> outstanding
>>>>>>>>>>>>>>> issues...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>         ...jim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>>>>>>>>>>>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>>>>>>>>>>>>>> Hi Jim,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Please, look at the update:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Here I'm correcting the rect after the transform in SG2D:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2123         // In case of negative scale transform,
>>>>>>>>>>>>>>>>>> reflect the
>>>>>>>>>>>>>>>>>> rect
>>>>>>>>>>>>>>>>>> coords.
>>>>>>>>>>>>>>>>>> 2124         if (w < 0) {
>>>>>>>>>>>>>>>>>> 2125             w *= -1;
>>>>>>>>>>>>>>>>>> 2126             x -= w;
>>>>>>>>>>>>>>>>>> 2127         }
>>>>>>>>>>>>>>>>>> 2128         if (h < 0) {
>>>>>>>>>>>>>>>>>> 2129             h *= -1;
>>>>>>>>>>>>>>>>>> 2130             y -= h;
>>>>>>>>>>>>>>>>>> 2131         }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The blit direction (dx, dy) remains transformed. Is this
>>>>>>>>>>>>>>>>>> the right
>>>>>>>>>>>>>>>>>> behavior from your perspective?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, that looks good.  I wonder if the "w *= -1" results
>>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>> multiply
>>>>>>>>>>>>>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jim,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, this indeed results in different byte code
>>>>>>>>>>>>>>>> instructions (imult &
>>>>>>>>>>>>>>>> ineg). Just for curiosity I did some measuring which showed
>>>>>>>>>>>>>>>> negatioation
>>>>>>>>>>>>>>>> worked 10% faster :)
>>>>>>>>>>>>>>>> Well, I'll fix it but let me please not send an update...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>> Anton.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>



From kevin.rushforth at oracle.com  Fri May 23 14:51:49 2014
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 23 May 2014 07:51:49 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <537F2E6B.3040309@oracle.com>
References: <52A723B8.7090705@oracle.com> <52E192F0.7010107@oracle.com>
	<52E27CDA.40703@oracle.com>	<52E31866.3010508@oracle.com>
	<52E7CE5B.4070101@oracle.com>	<52EAD304.2090809@oracle.com>
	<52EBB516.70906@oracle.com>	<52EC4F5E.7060906@oracle.com>
	<52EFA980.6000404@oracle.com>	<52F580C1.3020906@oracle.com>
	<52F8DE2A.4080304@oracle.com>	<52F962CD.2050301@oracle.com>
	<52F96AE2.10106@oracle.com>	<52FA67A8.1010600@oracle.com>
	<52FA7DCD.80405@oracle.com>	<52FCC28D.5010007@oracle.com>
	<52FD4CB6.2090805@oracle.com>	<52FDC1D1.8050907@oracle.com>
	<52FEBC4E.9010202@oracle.com>	<5302182D.3070600@oracle.com>
	<53068600.80501@oracle.com>	<53725695.40209@oracle.com>
	<537CCA57.4050200@oracle.com>	<537CECB4.7080706@oracle.com>
	<537D1E3C.9090309@oracle.com>	<537DAB80.1090106@oracle.com>
	<537DE14F.4070603@oracle.com>	<537E02A1.3050303@oracle.com>
	<537E3C72.3010607@oracle.com>	<537F1EE5.5070002@oracle.com>
	<537F2741.2090609@oracle.com>	<537F2D02.8020901@oracle.com>
	<537F2E6B.3040309@oracle.com>
Message-ID: <537F6085.4030504@oracle.com>


> PS. I'll be pushing the FX part of the fix today. So we should 
> consider the current interface frozen for now.

Yes, please!

-- Kevin


Anthony Petrov wrote:
> On 5/23/2014 3:12 PM, Anton V. Tarasov wrote:
>> On 23.05.2014 14:47, Anthony Petrov wrote:
>>> 1. The host bounds are not related to the /content/. Hence, adding
>>> this method to the LightweightContent interface would look
>>> inconsistent from API perspective.
>>
>> It's not strictly about content (the name of the interface is not good
>> enough).
>>
>>    32  * The interface by means of which the {@link JLightweightFrame}
>> class
>>    33  * communicates to its client application.
>
> Right. We might want to file a follow-up issue targeted for JDK/FX 9 
> and rename the interface/rearrange some APIs. However, personally, I 
> don't feel this is strictly necessary at this time.
>
> PS. I'll be pushing the FX part of the fix today. So we should 
> consider the current interface frozen for now.
>
> -- 
> best regards,
> Anthony
>
>>
>>
>>>
>>> 2. Given the requirement to keep backward compatibility, the default
>>> implementation of the method would return 'null', so the calling code
>>> would have to check the return value and fall back to calling
>>> LF.getBounds() manually. Currently this logic is encapsulated in the
>>> LightweightFrame class itself, which looks reasonable to me.
>>>
>>> 3. SwingNode already calls other APIs on LF, such as
>>> notifyDisplayChanged() (and again, this particular notification is
>>> unrelated to the /content/ itself.) So adding the setHostBounds() to
>>> LF looks consistent from this perspective, too.
>>>
>>> 4. The current implementation of the getHostBounds() method simply
>>> returns a new rectangles using cached values. If we implement your
>>> suggestion, then every call to CPLWW.getGraphicsDevice() would involve
>>> an additional call to the SwingNode code, which may impact the
>>> performance slightly.
>>>
>>> 5. I was almost ready to push the FX part of the fix today, and let's
>>> admit it, this fix is very well overdue. I'd prefer if we don't modify
>>> the interface anymore.
>>
>> Ok, this is about a matter of taste. The 5th point sounds strong enough
>> for me, so I'm fine with the current version.
>>
>> Thanks!
>> Anton.
>>
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 5/23/2014 2:11 PM, Anton V. Tarasov wrote:
>>>> Hi Sergey,
>>>>
>>>> Thanks for the update. I'm fine with the fix, except one thing. (I'm
>>>> sorry that I didn't say that earlier).
>>>>
>>>> My concern is that we have the LightweightContent iface which is 
>>>> used to
>>>> communicate to the client app. And so the method
>>>>
>>>> LightweightFrame.getHostBounds()
>>>>
>>>> is better to be a method of that iface which the client (SwingNode) 
>>>> will
>>>> implement on its side. In that case we won't need the
>>>> LightweightFrame.setHostBounds() method.
>>>>
>>>> This would look consistent from my perspective.
>>>>
>>>> Thanks,
>>>> Anton.
>>>>
>>>> On 22.05.2014 22:05, Sergey Bylokhov wrote:
>>>>> On 5/22/14 5:58 PM, Anton V. Tarasov wrote:
>>>>>> On 22.05.2014 15:36, Sergey Bylokhov wrote:
>>>>>>> On 5/22/14 11:47 AM, Anton V. Tarasov wrote:
>>>>>>>> Hi Sergey,
>>>>>>>>
>>>>>>>> On 22.05.2014 1:44, Sergey Bylokhov wrote:
>>>>>>>>> On 5/21/14 10:13 PM, Anthony Petrov wrote:
>>>>>>>>>> Hi Sergey,
>>>>>>>>>>
>>>>>>>>>> The original fix provides some updates and clarifications to the
>>>>>>>>>> javadoc for the LightweightContent.imageBufferReset() method, 
>>>>>>>>>> but
>>>>>>>>>> they are missing from your fix. Is this intentional?
>>>>>>>>> Nope. I just missed this update. I looked at this method closely
>>>>>>>>> and got a question: do we need this scale parameter? Why we 
>>>>>>>>> cannot
>>>>>>>>> use w,h + scanstride here an skip all clarification about logical
>>>>>>>>> coordinates?
>>>>>>>>
>>>>>>>> Originally, Jim suggested to generalize the API:
>>>>>>>>
>>>>>>>> <<Rather than imply any parameters, I think specifying a very 
>>>>>>>> exact
>>>>>>>> set of parameters gives the most flexibility. Even if the
>>>>>>>> relationships you characterize above are true, xywh,scan or
>>>>>>>> off,wh,scan both provide the flexibility to supply the data in
>>>>>>>> those formats without the client having to guess dimensions or 
>>>>>>>> scan
>>>>>>>> size. Any API that specifies an array containing data should 
>>>>>>>> always
>>>>>>>> provide the flexibility of specifying an offset (and x,y is a way
>>>>>>>> of specifying an offset for rectangular data and using a nio 
>>>>>>>> Buffer
>>>>>>>> can implicitly imply an offset based on its position) and when 
>>>>>>>> that
>>>>>>>> data is a rectangle of data then it should also supply independent
>>>>>>>> w,h and scan strides.  If the offset is always 0, and if the
>>>>>>>> scanstride is always w in the implementation's that choose the 
>>>>>>>> data
>>>>>>>> storage then it may seem like overkill, but it provides the
>>>>>>>> flexibility of switching to a more sophisticated buffer re-use
>>>>>>>> strategy later without having to track down every client and 
>>>>>>>> update
>>>>>>>> them... >>
>>>>>>>>
>>>>>>>> and so we provide all the coordinates.
>>>>>>> I understand why we need x/y/w/h/scanstride but why we need scale,
>>>>>>> because our buffer is pixel based anyway? In this case we have to
>>>>>>> convert w/h/x/y/scanstride from logical to pixels and back.
>>>>>>
>>>>>> The reasoning for that if the following. On the client side
>>>>>> (SwingNode), during the rendering of the image, there's a need to
>>>>>> have logical bounds of the image. So, this would require conversion
>>>>>> (devision)  for what the client would need to know the scale factor
>>>>>> for what it would need to ask for it, separately. This would bring
>>>>>> another code path & dependencies (for instance, b/w SwingNode and 
>>>>>> its
>>>>>> prism peer). Currently, there's only one parameter of a method for
>>>>>> that purpose.
>>>>> Ok. Here is an updated version:
>>>>> http://cr.openjdk.java.net/~serb/8029455/webrev.02
>>>>>>
>>>>>> Thanks,
>>>>>> Anton.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Anton.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> BTW, I've applied your fix and tested it with the latest version
>>>>>>>>>> of FX changes, and everything works smoothly on my Mac, 
>>>>>>>>>> including
>>>>>>>>>> the display change listener.
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> best regards,
>>>>>>>>>> Anthony
>>>>>>>>>>
>>>>>>>>>> On 5/21/2014 7:46 PM, Sergey Bylokhov wrote:
>>>>>>>>>>> Hello, Everybody.
>>>>>>>>>>> Please review an updated version of this fix. This is a minimum
>>>>>>>>>>> possible
>>>>>>>>>>> fix. changes in shared code of jdk are minimized and can be
>>>>>>>>>>> enhanced in
>>>>>>>>>>> the future.
>>>>>>>>>>> The fix is covering hdpi support in SwingNode on osx + system
>>>>>>>>>>> look and
>>>>>>>>>>> feel(Aqua).
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8029455/webrev.01
>>>>>>>>>>>
>>>>>>>>>>> Notes:
>>>>>>>>>>>   - This fix depends from two other fixes: JDK- 8041129 and
>>>>>>>>>>> JDK-8041644.
>>>>>>>>>>> Both are under review on 2d alias.
>>>>>>>>>>>
>>>>>>>>>>> On 5/13/14 9:29 PM, Anthony Petrov wrote:
>>>>>>>>>>>> Hi Jim, Sergey, and Anton,
>>>>>>>>>>>>
>>>>>>>>>>>> I'd like to revive this old thread and finally push this fix,
>>>>>>>>>>>> which
>>>>>>>>>>>> has been reviewed and approved on this mailing list back in
>>>>>>>>>>>> February.
>>>>>>>>>>>> The only additional change that I want to introduce, is the
>>>>>>>>>>>> addition
>>>>>>>>>>>> of default implementations for the
>>>>>>>>>>>> LightweightContent.imageBufferReset() methods. This allows
>>>>>>>>>>>> clients of
>>>>>>>>>>>> the API (namely, JavaFX) to run with both the old and the new
>>>>>>>>>>>> JDK w/o
>>>>>>>>>>>> any changes or side-effects. Here's the updated webrev:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/ 
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It literally only adds the default methods and doesn't make 
>>>>>>>>>>>> any
>>>>>>>>>>>> other
>>>>>>>>>>>> changes to the rest of the already reviewed code. I've tested
>>>>>>>>>>>> this on
>>>>>>>>>>>> both hiDPI and loDPI displays, with both old and hiDPI-aware
>>>>>>>>>>>> JavaFX
>>>>>>>>>>>> builds, and it works fine in all the cases.
>>>>>>>>>>>>
>>>>>>>>>>>> The current plan is to push this fix to JDK 9, and then
>>>>>>>>>>>> back-port the
>>>>>>>>>>>> changes to 8u20.
>>>>>>>>>>>>
>>>>>>>>>>>> -- 
>>>>>>>>>>>> best regards,
>>>>>>>>>>>> Anthony
>>>>>>>>>>>>
>>>>>>>>>>>> On 2/21/2014 2:47 AM, Jim Graham wrote:
>>>>>>>>>>>>> Yes, approved.
>>>>>>>>>>>>>
>>>>>>>>>>>>>          ...jim
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>>>>>>>>>>>>>> Jim, so this is ready for a push then.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>> Anton.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 15.02.2014 5:01, Jim Graham wrote:
>>>>>>>>>>>>>>> I don't need to see an update for that.  I didn't read the
>>>>>>>>>>>>>>> entire
>>>>>>>>>>>>>>> webrev, but I looked at this one piece of code and if that
>>>>>>>>>>>>>>> was the
>>>>>>>>>>>>>>> only thing changed then I think that dealt with the
>>>>>>>>>>>>>>> outstanding
>>>>>>>>>>>>>>> issues...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>         ...jim
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>>>>>>>>>>>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>>>>>>>>>>>>>> Hi Jim,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Please, look at the update:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Here I'm correcting the rect after the transform in 
>>>>>>>>>>>>>>>>>> SG2D:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2123         // In case of negative scale transform,
>>>>>>>>>>>>>>>>>> reflect the
>>>>>>>>>>>>>>>>>> rect
>>>>>>>>>>>>>>>>>> coords.
>>>>>>>>>>>>>>>>>> 2124         if (w < 0) {
>>>>>>>>>>>>>>>>>> 2125             w *= -1;
>>>>>>>>>>>>>>>>>> 2126             x -= w;
>>>>>>>>>>>>>>>>>> 2127         }
>>>>>>>>>>>>>>>>>> 2128         if (h < 0) {
>>>>>>>>>>>>>>>>>> 2129             h *= -1;
>>>>>>>>>>>>>>>>>> 2130             y -= h;
>>>>>>>>>>>>>>>>>> 2131         }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The blit direction (dx, dy) remains transformed. Is this
>>>>>>>>>>>>>>>>>> the right
>>>>>>>>>>>>>>>>>> behavior from your perspective?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, that looks good.  I wonder if the "w *= -1" results
>>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>> multiply
>>>>>>>>>>>>>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jim,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, this indeed results in different byte code
>>>>>>>>>>>>>>>> instructions (imult &
>>>>>>>>>>>>>>>> ineg). Just for curiosity I did some measuring which 
>>>>>>>>>>>>>>>> showed
>>>>>>>>>>>>>>>> negatioation
>>>>>>>>>>>>>>>> worked 10% faster :)
>>>>>>>>>>>>>>>> Well, I'll fix it but let me please not send an update...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>> Anton.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>


From omajid at redhat.com  Fri May 23 15:12:53 2014
From: omajid at redhat.com (Omair Majid)
Date: Fri, 23 May 2014 11:12:53 -0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: Allow using the system libjpeg
In-Reply-To: <1569662464.10171034.1400789430009.JavaMail.zimbra@redhat.com>
References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com>
	<20140520171120.GD2672@redhat.com>
	<113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com>
	<20140521205934.GE3957@redhat.com>
	<1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com>
	<20140522004931.GG3957@redhat.com> <537DBD0C.2010809@oracle.com>
	<1569662464.10171034.1400789430009.JavaMail.zimbra@redhat.com>
Message-ID: <20140523151252.GD2799@redhat.com>

* Andrew Hughes <gnu.andrew at redhat.com> [2014-05-22 16:10]:
> ----- Original Message -----
> > On 2014-05-22 02:49, Omair Majid wrote:
> > > Would you mind if I did this as a separate patch? I will need to fix
> > > other libraries too (libzip, and libgif).
> > >
> 
> Ok, I thought the other ones were already in this form. In that case, leave it
> to me and I'll go through them as a whole.

Thanks. The relevant bits are in spec.gmk.in:

565 USE_EXTERNAL_LIBJPEG:=@USE_EXTERNAL_LIBJPEG@
566 USE_EXTERNAL_LIBGIF:=@USE_EXTERNAL_LIBGIF@
567 USE_EXTERNAL_LIBZ:=@USE_EXTERNAL_LIBZ@

Further down in the file, other libraries have both CFLAGS and LIBS
defined:

655 USE_EXTERNAL_LCMS:=@USE_EXTERNAL_LCMS@
656 LCMS_CFLAGS:=@LCMS_CFLAGS@
657 LCMS_LIBS:=@LCMS_LIBS@
658 
659 USE_EXTERNAL_LIBPNG:=@USE_EXTERNAL_LIBPNG@
660 PNG_LIBS:=@PNG_LIBS@
661 PNG_CFLAGS:=@PNG_CFLAGS@

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681


From anthony.petrov at oracle.com  Fri May 23 15:22:03 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 23 May 2014 19:22:03 +0400
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: JDK-8029455
 JLightweightFrame: support scaled painting
In-Reply-To: <537F6085.4030504@oracle.com>
References: <52A723B8.7090705@oracle.com>
	<52E27CDA.40703@oracle.com>	<52E31866.3010508@oracle.com>
	<52E7CE5B.4070101@oracle.com>	<52EAD304.2090809@oracle.com>
	<52EBB516.70906@oracle.com>	<52EC4F5E.7060906@oracle.com>
	<52EFA980.6000404@oracle.com>	<52F580C1.3020906@oracle.com>
	<52F8DE2A.4080304@oracle.com>	<52F962CD.2050301@oracle.com>
	<52F96AE2.10106@oracle.com>	<52FA67A8.1010600@oracle.com>
	<52FA7DCD.80405@oracle.com>	<52FCC28D.5010007@oracle.com>
	<52FD4CB6.2090805@oracle.com>	<52FDC1D1.8050907@oracle.com>
	<52FEBC4E.9010202@oracle.com>	<5302182D.3070600@oracle.com>
	<53068600.80501@oracle.com>	<53725695.40209@oracle.com>
	<537CCA57.4050200@oracle.com>	<537CECB4.7080706@oracle.com>
	<537D1E3C.9090309@oracle.com>	<537DAB80.1090106@oracle.com>
	<537DE14F.4070603@oracle.com>	<537E02A1.3050303@oracle.com>
	<537E3C72.3010607@oracle.com>	<537F1EE5.5070002@oracle.com>
	<537F2741.2090609@oracle.com>	<537F2D02.8020901@oracle.com>
	<537F2E6B.3040309@oracle.com> <537F6085.4030504@oracle.com>
Message-ID: <537F679B.1090501@oracle.com>

On 5/23/2014 6:51 PM, Kevin Rushforth wrote:
>> PS. I'll be pushing the FX part of the fix today. So we should
>> consider the current interface frozen for now.
>
> Yes, please!

Here it is:

http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/9f221ab57e22

--
best regards,
Anthony

>
> -- Kevin
>
>
> Anthony Petrov wrote:
>> On 5/23/2014 3:12 PM, Anton V. Tarasov wrote:
>>> On 23.05.2014 14:47, Anthony Petrov wrote:
>>>> 1. The host bounds are not related to the /content/. Hence, adding
>>>> this method to the LightweightContent interface would look
>>>> inconsistent from API perspective.
>>>
>>> It's not strictly about content (the name of the interface is not good
>>> enough).
>>>
>>>    32  * The interface by means of which the {@link JLightweightFrame}
>>> class
>>>    33  * communicates to its client application.
>>
>> Right. We might want to file a follow-up issue targeted for JDK/FX 9
>> and rename the interface/rearrange some APIs. However, personally, I
>> don't feel this is strictly necessary at this time.
>>
>> PS. I'll be pushing the FX part of the fix today. So we should
>> consider the current interface frozen for now.
>>
>> --
>> best regards,
>> Anthony
>>
>>>
>>>
>>>>
>>>> 2. Given the requirement to keep backward compatibility, the default
>>>> implementation of the method would return 'null', so the calling code
>>>> would have to check the return value and fall back to calling
>>>> LF.getBounds() manually. Currently this logic is encapsulated in the
>>>> LightweightFrame class itself, which looks reasonable to me.
>>>>
>>>> 3. SwingNode already calls other APIs on LF, such as
>>>> notifyDisplayChanged() (and again, this particular notification is
>>>> unrelated to the /content/ itself.) So adding the setHostBounds() to
>>>> LF looks consistent from this perspective, too.
>>>>
>>>> 4. The current implementation of the getHostBounds() method simply
>>>> returns a new rectangles using cached values. If we implement your
>>>> suggestion, then every call to CPLWW.getGraphicsDevice() would involve
>>>> an additional call to the SwingNode code, which may impact the
>>>> performance slightly.
>>>>
>>>> 5. I was almost ready to push the FX part of the fix today, and let's
>>>> admit it, this fix is very well overdue. I'd prefer if we don't modify
>>>> the interface anymore.
>>>
>>> Ok, this is about a matter of taste. The 5th point sounds strong enough
>>> for me, so I'm fine with the current version.
>>>
>>> Thanks!
>>> Anton.
>>>
>>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 5/23/2014 2:11 PM, Anton V. Tarasov wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> Thanks for the update. I'm fine with the fix, except one thing. (I'm
>>>>> sorry that I didn't say that earlier).
>>>>>
>>>>> My concern is that we have the LightweightContent iface which is
>>>>> used to
>>>>> communicate to the client app. And so the method
>>>>>
>>>>> LightweightFrame.getHostBounds()
>>>>>
>>>>> is better to be a method of that iface which the client (SwingNode)
>>>>> will
>>>>> implement on its side. In that case we won't need the
>>>>> LightweightFrame.setHostBounds() method.
>>>>>
>>>>> This would look consistent from my perspective.
>>>>>
>>>>> Thanks,
>>>>> Anton.
>>>>>
>>>>> On 22.05.2014 22:05, Sergey Bylokhov wrote:
>>>>>> On 5/22/14 5:58 PM, Anton V. Tarasov wrote:
>>>>>>> On 22.05.2014 15:36, Sergey Bylokhov wrote:
>>>>>>>> On 5/22/14 11:47 AM, Anton V. Tarasov wrote:
>>>>>>>>> Hi Sergey,
>>>>>>>>>
>>>>>>>>> On 22.05.2014 1:44, Sergey Bylokhov wrote:
>>>>>>>>>> On 5/21/14 10:13 PM, Anthony Petrov wrote:
>>>>>>>>>>> Hi Sergey,
>>>>>>>>>>>
>>>>>>>>>>> The original fix provides some updates and clarifications to the
>>>>>>>>>>> javadoc for the LightweightContent.imageBufferReset() method,
>>>>>>>>>>> but
>>>>>>>>>>> they are missing from your fix. Is this intentional?
>>>>>>>>>> Nope. I just missed this update. I looked at this method closely
>>>>>>>>>> and got a question: do we need this scale parameter? Why we
>>>>>>>>>> cannot
>>>>>>>>>> use w,h + scanstride here an skip all clarification about logical
>>>>>>>>>> coordinates?
>>>>>>>>>
>>>>>>>>> Originally, Jim suggested to generalize the API:
>>>>>>>>>
>>>>>>>>> <<Rather than imply any parameters, I think specifying a very
>>>>>>>>> exact
>>>>>>>>> set of parameters gives the most flexibility. Even if the
>>>>>>>>> relationships you characterize above are true, xywh,scan or
>>>>>>>>> off,wh,scan both provide the flexibility to supply the data in
>>>>>>>>> those formats without the client having to guess dimensions or
>>>>>>>>> scan
>>>>>>>>> size. Any API that specifies an array containing data should
>>>>>>>>> always
>>>>>>>>> provide the flexibility of specifying an offset (and x,y is a way
>>>>>>>>> of specifying an offset for rectangular data and using a nio
>>>>>>>>> Buffer
>>>>>>>>> can implicitly imply an offset based on its position) and when
>>>>>>>>> that
>>>>>>>>> data is a rectangle of data then it should also supply independent
>>>>>>>>> w,h and scan strides.  If the offset is always 0, and if the
>>>>>>>>> scanstride is always w in the implementation's that choose the
>>>>>>>>> data
>>>>>>>>> storage then it may seem like overkill, but it provides the
>>>>>>>>> flexibility of switching to a more sophisticated buffer re-use
>>>>>>>>> strategy later without having to track down every client and
>>>>>>>>> update
>>>>>>>>> them... >>
>>>>>>>>>
>>>>>>>>> and so we provide all the coordinates.
>>>>>>>> I understand why we need x/y/w/h/scanstride but why we need scale,
>>>>>>>> because our buffer is pixel based anyway? In this case we have to
>>>>>>>> convert w/h/x/y/scanstride from logical to pixels and back.
>>>>>>>
>>>>>>> The reasoning for that if the following. On the client side
>>>>>>> (SwingNode), during the rendering of the image, there's a need to
>>>>>>> have logical bounds of the image. So, this would require conversion
>>>>>>> (devision)  for what the client would need to know the scale factor
>>>>>>> for what it would need to ask for it, separately. This would bring
>>>>>>> another code path & dependencies (for instance, b/w SwingNode and
>>>>>>> its
>>>>>>> prism peer). Currently, there's only one parameter of a method for
>>>>>>> that purpose.
>>>>>> Ok. Here is an updated version:
>>>>>> http://cr.openjdk.java.net/~serb/8029455/webrev.02
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Anton.
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Anton.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> BTW, I've applied your fix and tested it with the latest version
>>>>>>>>>>> of FX changes, and everything works smoothly on my Mac,
>>>>>>>>>>> including
>>>>>>>>>>> the display change listener.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> best regards,
>>>>>>>>>>> Anthony
>>>>>>>>>>>
>>>>>>>>>>> On 5/21/2014 7:46 PM, Sergey Bylokhov wrote:
>>>>>>>>>>>> Hello, Everybody.
>>>>>>>>>>>> Please review an updated version of this fix. This is a minimum
>>>>>>>>>>>> possible
>>>>>>>>>>>> fix. changes in shared code of jdk are minimized and can be
>>>>>>>>>>>> enhanced in
>>>>>>>>>>>> the future.
>>>>>>>>>>>> The fix is covering hdpi support in SwingNode on osx + system
>>>>>>>>>>>> look and
>>>>>>>>>>>> feel(Aqua).
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~serb/8029455/webrev.01
>>>>>>>>>>>>
>>>>>>>>>>>> Notes:
>>>>>>>>>>>>   - This fix depends from two other fixes: JDK- 8041129 and
>>>>>>>>>>>> JDK-8041644.
>>>>>>>>>>>> Both are under review on 2d alias.
>>>>>>>>>>>>
>>>>>>>>>>>> On 5/13/14 9:29 PM, Anthony Petrov wrote:
>>>>>>>>>>>>> Hi Jim, Sergey, and Anton,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd like to revive this old thread and finally push this fix,
>>>>>>>>>>>>> which
>>>>>>>>>>>>> has been reviewed and approved on this mailing list back in
>>>>>>>>>>>>> February.
>>>>>>>>>>>>> The only additional change that I want to introduce, is the
>>>>>>>>>>>>> addition
>>>>>>>>>>>>> of default implementations for the
>>>>>>>>>>>>> LightweightContent.imageBufferReset() methods. This allows
>>>>>>>>>>>>> clients of
>>>>>>>>>>>>> the API (namely, JavaFX) to run with both the old and the new
>>>>>>>>>>>>> JDK w/o
>>>>>>>>>>>>> any changes or side-effects. Here's the updated webrev:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~anthony/9-2-hiDPISwingNode-8029455.0/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It literally only adds the default methods and doesn't make
>>>>>>>>>>>>> any
>>>>>>>>>>>>> other
>>>>>>>>>>>>> changes to the rest of the already reviewed code. I've tested
>>>>>>>>>>>>> this on
>>>>>>>>>>>>> both hiDPI and loDPI displays, with both old and hiDPI-aware
>>>>>>>>>>>>> JavaFX
>>>>>>>>>>>>> builds, and it works fine in all the cases.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The current plan is to push this fix to JDK 9, and then
>>>>>>>>>>>>> back-port the
>>>>>>>>>>>>> changes to 8u20.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2/21/2014 2:47 AM, Jim Graham wrote:
>>>>>>>>>>>>>> Yes, approved.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>          ...jim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
>>>>>>>>>>>>>>> Jim, so this is ready for a push then.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>> Anton.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 15.02.2014 5:01, Jim Graham wrote:
>>>>>>>>>>>>>>>> I don't need to see an update for that.  I didn't read the
>>>>>>>>>>>>>>>> entire
>>>>>>>>>>>>>>>> webrev, but I looked at this one piece of code and if that
>>>>>>>>>>>>>>>> was the
>>>>>>>>>>>>>>>> only thing changed then I think that dealt with the
>>>>>>>>>>>>>>>> outstanding
>>>>>>>>>>>>>>>> issues...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>         ...jim
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
>>>>>>>>>>>>>>>>> On 14.02.2014 2:52, Jim Graham wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
>>>>>>>>>>>>>>>>>>> Hi Jim,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Please, look at the update:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Here I'm correcting the rect after the transform in
>>>>>>>>>>>>>>>>>>> SG2D:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2123         // In case of negative scale transform,
>>>>>>>>>>>>>>>>>>> reflect the
>>>>>>>>>>>>>>>>>>> rect
>>>>>>>>>>>>>>>>>>> coords.
>>>>>>>>>>>>>>>>>>> 2124         if (w < 0) {
>>>>>>>>>>>>>>>>>>> 2125             w *= -1;
>>>>>>>>>>>>>>>>>>> 2126             x -= w;
>>>>>>>>>>>>>>>>>>> 2127         }
>>>>>>>>>>>>>>>>>>> 2128         if (h < 0) {
>>>>>>>>>>>>>>>>>>> 2129             h *= -1;
>>>>>>>>>>>>>>>>>>> 2130             y -= h;
>>>>>>>>>>>>>>>>>>> 2131         }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The blit direction (dx, dy) remains transformed. Is this
>>>>>>>>>>>>>>>>>>> the right
>>>>>>>>>>>>>>>>>>> behavior from your perspective?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yes, that looks good.  I wonder if the "w *= -1" results
>>>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>>> multiply
>>>>>>>>>>>>>>>>>> byte code whereas "w = -w" would avoid the multiply?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>             ...jim
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jim,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, this indeed results in different byte code
>>>>>>>>>>>>>>>>> instructions (imult &
>>>>>>>>>>>>>>>>> ineg). Just for curiosity I did some measuring which
>>>>>>>>>>>>>>>>> showed
>>>>>>>>>>>>>>>>> negatioation
>>>>>>>>>>>>>>>>> worked 10% faster :)
>>>>>>>>>>>>>>>>> Well, I'll fix it but let me please not send an update...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>> Anton.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>


From Sergey.Bylokhov at oracle.com  Fri May 23 18:34:26 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 23 May 2014 22:34:26 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8042103 Deserialization of
 empty java.awt.geom.Path2D will cause an exception
In-Reply-To: <53679274.5090304@oracle.com>
References: <53611C5A.8080303@oracle.com> <536198F6.1050109@oracle.com>
	<53679274.5090304@oracle.com>
Message-ID: <537F94B2.6040608@oracle.com>

Hello,
Any volunteers to review the fix?
On 5/5/14 5:30 PM, Sergey Bylokhov wrote:
> Hi, Jim.
> On 01.05.2014 4:44, Jim Graham wrote:
>> Hi Sergey,
>>
>> I think the bug is in the readObject routine.  It sets the initial 
>> size of the arrays based on if the number of segments/coords is "< 0" 
>> and it sets them to INIT_SIZE or INIT_SIZE*2 accordingly.  Those 
>> tests should be "< INIT_SIZE(*2)"...
>
> It was my first thought, but we have an API, which allows to set 
> starting value of capacity to 0.
> Copy from the bug description:
> 1.Path2D path = Path2D.Float(int rule, int initialCapacity); while 
> initialCapacity is 0
> 2.Path2D path = Path2D.Double(int rule, int initialCapacity);
> 3.Path2D path = Path2D.Float(Shape s); while s is empty Path2D
> 4.Path2D path = Path2D.Float(Shape s, AffineTransform at);
> 5.Path2D path = Path2D.Double(Shape s);
> 6.Path2D path = Path2D.Double(Shape s, AffineTransform at);
>
> based on these I assume that empty capacity is correct value, and 
> needRoom should be ready for that.
>
>>
>>             ...jim
>>
>> On 4/30/14 8:52 AM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk 9.
>>> needRoom() method does not take into account that current array of 
>>> types
>>> can be empty. In this case it fails to increase it.
>>> I handle this case and increase the size of the array by 1 instead of
>>> INIT_SIZE, because I assume that the user intentionally try to decrease
>>> memory usage.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042103
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8042103/webrev.00
>>>
>
>


-- 
Best regards, Sergey.



From philip.race at oracle.com  Fri May 23 21:50:12 2014
From: philip.race at oracle.com (Phil Race)
Date: Fri, 23 May 2014 14:50:12 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8035301: Eliminate dependency on sun.text
	from font code
Message-ID: <537FC294.9060403@oracle.com>

http://cr.openjdk.java.net/~prr/8035301/
https://bugs.openjdk.java.net/browse/JDK-8035301

Builds cleanly. Client tests run.

-phil.


From mandy.chung at oracle.com  Fri May 23 22:44:15 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 23 May 2014 15:44:15 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8035301: Eliminate dependency on sun.text
	from font code
In-Reply-To: <537FC294.9060403@oracle.com>
References: <537FC294.9060403@oracle.com>
Message-ID: <537FCF3F.8040409@oracle.com>

On 5/23/14 2:50 PM, Phil Race wrote:
> http://cr.openjdk.java.net/~prr/8035301/
> https://bugs.openjdk.java.net/browse/JDK-8035301
>
> Builds cleanly. Client tests run.

Looks good to me.    Thanks for doing another good cleanup for 
modularization.

Mandy



From andrew.brygin at oracle.com  Mon May 26 14:01:00 2014
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Mon, 26 May 2014 18:01:00 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8042103 Deserialization of
 empty java.awt.geom.Path2D will cause an exception
In-Reply-To: <537F94B2.6040608@oracle.com>
References: <53611C5A.8080303@oracle.com>
	<536198F6.1050109@oracle.com>	<53679274.5090304@oracle.com>
	<537F94B2.6040608@oracle.com>
Message-ID: <5383491C.7040007@oracle.com>

Hello Sergey,

  the fix looks good to me.

Thanks,
Andrew

On 5/23/2014 10:34 PM, Sergey Bylokhov wrote:
> Hello,
> Any volunteers to review the fix?
> On 5/5/14 5:30 PM, Sergey Bylokhov wrote:
>> Hi, Jim.
>> On 01.05.2014 4:44, Jim Graham wrote:
>>> Hi Sergey,
>>>
>>> I think the bug is in the readObject routine.  It sets the initial 
>>> size of the arrays based on if the number of segments/coords is "< 
>>> 0" and it sets them to INIT_SIZE or INIT_SIZE*2 accordingly.  Those 
>>> tests should be "< INIT_SIZE(*2)"...
>>
>> It was my first thought, but we have an API, which allows to set 
>> starting value of capacity to 0.
>> Copy from the bug description:
>> 1.Path2D path = Path2D.Float(int rule, int initialCapacity); while 
>> initialCapacity is 0
>> 2.Path2D path = Path2D.Double(int rule, int initialCapacity);
>> 3.Path2D path = Path2D.Float(Shape s); while s is empty Path2D
>> 4.Path2D path = Path2D.Float(Shape s, AffineTransform at);
>> 5.Path2D path = Path2D.Double(Shape s);
>> 6.Path2D path = Path2D.Double(Shape s, AffineTransform at);
>>
>> based on these I assume that empty capacity is correct value, and 
>> needRoom should be ready for that.
>>
>>>
>>>             ...jim
>>>
>>> On 4/30/14 8:52 AM, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review the fix for jdk 9.
>>>> needRoom() method does not take into account that current array of 
>>>> types
>>>> can be empty. In this case it fails to increase it.
>>>> I handle this case and increase the size of the array by 1 instead of
>>>> INIT_SIZE, because I assume that the user intentionally try to 
>>>> decrease
>>>> memory usage.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042103
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/8042103/webrev.00
>>>>
>>
>>
>
>



From jennifer.godinez at oracle.com  Tue May 27 19:41:31 2014
From: jennifer.godinez at oracle.com (Jennifer Godinez)
Date: Tue, 27 May 2014 12:41:31 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8035301: Eliminate dependency on sun.text
 from font code
In-Reply-To: <537FC294.9060403@oracle.com>
References: <537FC294.9060403@oracle.com>
Message-ID: <5384EA6B.7070707@oracle.com>

Looks good.

Jennifer
On 05/23/2014 02:50 PM, Phil Race wrote:
> http://cr.openjdk.java.net/~prr/8035301/
> https://bugs.openjdk.java.net/browse/JDK-8035301
>
> Builds cleanly. Client tests run.
>
> -phil.



From steve.sides at oracle.com  Wed May 28 17:39:43 2014
From: steve.sides at oracle.com (Steve Sides)
Date: Wed, 28 May 2014 10:39:43 -0700
Subject: [OpenJDK 2D-Dev] Review Request for 8032527 - fix a couple doclint
	errors in java/awt/geom/Path2D
Message-ID: <53861F5F.7060204@oracle.com>

Hello,

Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8032527
It is a just a couple @link fixes in Path2D.java which were previously 
blocked due to another bug.
Webrev  info:

Webrev corresponding:
http://cr.openjdk.java.net/~ssides/8032527/

commitComment:
jdk-8032527: fix a couple doclint errors in java/awt/geom/Path2D 
Summary: A couple @link tags could not be properly specified due to 
JDK-8031625.

webrevComment:
This change was previously blocked because of JDK-8031625 which has now 
been fixed.


thanks,

-steve


From philip.race at oracle.com  Wed May 28 17:51:51 2014
From: philip.race at oracle.com (Phil Race)
Date: Wed, 28 May 2014 10:51:51 -0700
Subject: [OpenJDK 2D-Dev] Review Request for 8032527 - fix a couple
 doclint errors in java/awt/geom/Path2D
In-Reply-To: <53861F5F.7060204@oracle.com>
References: <53861F5F.7060204@oracle.com>
Message-ID: <53862237.4000206@oracle.com>

Looks OK. I trust you actually generated the javadoc to prove its 
correct ...  ?

-phil.

On 5/28/2014 10:39 AM, Steve Sides wrote:
> Hello,
>
> Could you please review the fix for the following bug:
> https://bugs.openjdk.java.net/browse/JDK-8032527
> It is a just a couple @link fixes in Path2D.java which were previously 
> blocked due to another bug.
> Webrev  info:
>
> Webrev corresponding:
> http://cr.openjdk.java.net/~ssides/8032527/
>
> commitComment:
> jdk-8032527: fix a couple doclint errors in java/awt/geom/Path2D 
> Summary: A couple @link tags could not be properly specified due to 
> JDK-8031625.
>
> webrevComment:
> This change was previously blocked because of JDK-8031625 which has 
> now been fixed.
>
>
> thanks,
>
> -steve



From bourges.laurent at gmail.com  Wed May 28 18:08:28 2014
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Wed, 28 May 2014 14:08:28 -0400
Subject: [OpenJDK 2D-Dev] Merging marlin & pisces rendering engines
In-Reply-To: <CAKjRUT4WNgQMK78+MgGo7t=b_z8bw_iJqGWUL-2d946MubS=ug@mail.gmail.com>
References: <CAKjRUT5zkGvOadndQc+OFiqaJqtxx3GhA02BhF77OSQyrJdhXw@mail.gmail.com>
	<CAKjRUT4dsYFMneYvo1ZzPsatcsUr+cq58iYPT3Pwje5KWos-qA@mail.gmail.com>
	<CAKjRUT52scryCXDKf9PEguOO9JjbqJGn3XLyxCz_rJrhcAtMaQ@mail.gmail.com>
	<CAKjRUT4icTSFDek8aYi9daPovObbuTbNmnMDHCXeZ5nhc76HcQ@mail.gmail.com>
	<CAKjRUT4WNgQMK78+MgGo7t=b_z8bw_iJqGWUL-2d946MubS=ug@mail.gmail.com>
Message-ID: <CAKjRUT4Es-LHT2Rr6FgWaw7KLuqHY0yCmjUtRfxLOt7rZcoqGQ@mail.gmail.com>

Phil,

Do you some guys who could help me merging marlin with pisces in jdk9 ?

I need help creating small sequential patches as webrevs and also reviewers.

I made the MapDisplay tool to perform regression tests vs pisces:
https://github.com/bourgesl/mapbench

FYI I released marlin 0.4.4 which is now as fast as ductus according to my
benchmarks:
https://github.com/bourgesl/marlin-renderer/releases/latest

https://github.com/bourgesl/marlin-renderer/wiki/Benchmarks

https://bourgesl.github.io/marlin-0.5.4/default/compareResults_ductus_marlin0.4.x.htm#table11

PS: I want to improve rendering quality in next steps.

Regards,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140528/0a1b4180/attachment.html>

From linuxhippy at gmail.com  Thu May 29 09:22:29 2014
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Thu, 29 May 2014 11:22:29 +0200
Subject: [OpenJDK 2D-Dev] Merging marlin & pisces rendering engines
In-Reply-To: <CAKjRUT4Es-LHT2Rr6FgWaw7KLuqHY0yCmjUtRfxLOt7rZcoqGQ@mail.gmail.com>
References: <CAKjRUT5zkGvOadndQc+OFiqaJqtxx3GhA02BhF77OSQyrJdhXw@mail.gmail.com>
	<CAKjRUT4dsYFMneYvo1ZzPsatcsUr+cq58iYPT3Pwje5KWos-qA@mail.gmail.com>
	<CAKjRUT52scryCXDKf9PEguOO9JjbqJGn3XLyxCz_rJrhcAtMaQ@mail.gmail.com>
	<CAKjRUT4icTSFDek8aYi9daPovObbuTbNmnMDHCXeZ5nhc76HcQ@mail.gmail.com>
	<CAKjRUT4WNgQMK78+MgGo7t=b_z8bw_iJqGWUL-2d946MubS=ug@mail.gmail.com>
	<CAKjRUT4Es-LHT2Rr6FgWaw7KLuqHY0yCmjUtRfxLOt7rZcoqGQ@mail.gmail.com>
Message-ID: <CAFvQSYSFT8BHt=pZ3M0UAkySRXw54uAG8bb=fTs6Sg-kO2a9vg@mail.gmail.com>

Hi,

I would like to add that, beside higher performance for rasterization,
Marlin's capability to produce tiles larger than 32x32px also improves
the performance with the XRender pipeline f?r larger antialiased
shapes a lot.
For modern drivers uploading 32x32 small coverage masks is more
expensive than uploading the additional "empty" areas caused by larger
masks.

Marlin could help to improve the XRender pipeline's weakest spot - in
this case the results of the diagonal line (worst case for larger
coverage masks) test of J2Bench are shown:

graphics.opts.sizes=100:
mask256: 3202.226720 (var=33.64%) (100.0%)
mask32: 477.4535809 (var=3.01%) (14.91%)
stock: 479.0772966 (var=5.82%) (14.96%)

At least on this machine the optimal mask size is somewhere between
64^2 and 128^2 pixels.

Regards, Clemens


From mikhail.cherkasov at oracle.com  Thu May 29 11:35:00 2014
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Thu, 29 May 2014 15:35:00 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8041439: Clipping doesn't work
 on JPanel after setXORMode method call.
Message-ID: <53871B64.5040803@oracle.com>

Hello,

Please review the fix for jdk 9:
http://cr.openjdk.java.net/~mcherkas/8041439/9/webrev.00/
the bug:
https://bugs.openjdk.java.net/browse/JDK-8041439

SurfaceData uses wrong pipe in case of complex clipping shape as result 
clipping doesn't work
if we use xor color composition and double buffering.

Thanks,
Mikhail.


From andrew.brygin at oracle.com  Thu May 29 12:12:00 2014
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Thu, 29 May 2014 16:12:00 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8041439: Clipping doesn't
 work on JPanel after setXORMode method call.
In-Reply-To: <53871B64.5040803@oracle.com>
References: <53871B64.5040803@oracle.com>
Message-ID: <53872410.80000@oracle.com>

Hello Mikhail,

  could you please provide a bit more detailed explanation for your fix?

Thanks,
Andrew

On 5/29/2014 3:35 PM, mikhail cherkasov wrote:
> Hello,
>
> Please review the fix for jdk 9:
> http://cr.openjdk.java.net/~mcherkas/8041439/9/webrev.00/
> the bug:
> https://bugs.openjdk.java.net/browse/JDK-8041439
>
> SurfaceData uses wrong pipe in case of complex clipping shape as 
> result clipping doesn't work
> if we use xor color composition and double buffering.
>
> Thanks,
> Mikhail.



From mikhail.cherkasov at oracle.com  Thu May 29 16:29:38 2014
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Thu, 29 May 2014 20:29:38 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8041439: Clipping doesn't
 work on JPanel after setXORMode method call.
In-Reply-To: <53872410.80000@oracle.com>
References: <53871B64.5040803@oracle.com> <53872410.80000@oracle.com>
Message-ID: <53876072.2040706@oracle.com>

Sure Andrew:

The problem is that to render complex clipping we need to use 
PixelToShapeConverter with SpanShapeRenderer.
But in case of XOR composition, SurfaceData uses colorViaShape or 
colorViaPgram converter:
http://tvp129231.uk.oracle.com:8080/source/xref/jdk9-dev/jdk/src/share/classes/sun/java2d/SurfaceData.java#568
colorViaShape and colorViaPgram has type PixelToShapeLoopConverter that 
implements
marker interface LoopBasedPipe:
http://tvp129231.uk.oracle.com:8080/source/xref/jdk9-dev/jdk/src/share/classes/sun/java2d/SurfaceData.java#407
and SurfaceData passes  LoopPipe to constructor of 
PixelToShapeLoopConverter
http://tvp129231.uk.oracle.com:8080/source/xref/jdk9-dev/jdk/src/share/classes/sun/java2d/SurfaceData.java#457
http://tvp129231.uk.oracle.com:8080/source/xref/jdk9-dev/jdk/src/share/classes/sun/java2d/SurfaceData.java#colorPrimitives
as result we don't get to SpanShapeRenderer.

Now we have the following call chain: PixelToShapeConverter -> LoopPipe 
-> SunGraphics2D.loops.fillPathLoop .FillPath
http://tvp129231.uk.oracle.com:8080/source/xref/jdk9-dev/jdk/src/share/classes/sun/java2d/pipe/LoopPipe.java#308
But native method FillPath doesn't support complex clipping.

That's why I replaced converter(PixelToShapeLoopConverter(LoopPipe)) 
with paintViaShape(PixelToShapeConverter(SpanShapeRenderer)).

Thanks,
Mikhail.


On 5/29/2014 4:12 PM, Andrew Brygin wrote:
> Hello Mikhail,
>
>  could you please provide a bit more detailed explanation for your fix?
>
> Thanks,
> Andrew
>
> On 5/29/2014 3:35 PM, mikhail cherkasov wrote:
>> Hello,
>>
>> Please review the fix for jdk 9:
>> http://cr.openjdk.java.net/~mcherkas/8041439/9/webrev.00/
>> the bug:
>> https://bugs.openjdk.java.net/browse/JDK-8041439
>>
>> SurfaceData uses wrong pipe in case of complex clipping shape as 
>> result clipping doesn't work
>> if we use xor color composition and double buffering.
>>
>> Thanks,
>> Mikhail.
>



From steve.sides at oracle.com  Thu May 29 17:58:17 2014
From: steve.sides at oracle.com (Steve Sides)
Date: Thu, 29 May 2014 10:58:17 -0700
Subject: [OpenJDK 2D-Dev] Review Request for 8032527 - fix a couple
 doclint errors in java/awt/geom/Path2D
In-Reply-To: <53862237.4000206@oracle.com>
References: <53861F5F.7060204@oracle.com> <53862237.4000206@oracle.com>
Message-ID: <53877539.4090405@oracle.com>

Yes..and the links are correct and they work. :)
-steve

On 5/28/2014 10:51 AM, Phil Race wrote:
> Looks OK. I trust you actually generated the javadoc to prove its 
> correct ...  ?
>
> -phil.
>
> On 5/28/2014 10:39 AM, Steve Sides wrote:
>> Hello,
>>
>> Could you please review the fix for the following bug:
>> https://bugs.openjdk.java.net/browse/JDK-8032527
>> It is a just a couple @link fixes in Path2D.java which were 
>> previously blocked due to another bug.
>> Webrev  info:
>>
>> Webrev corresponding:
>> http://cr.openjdk.java.net/~ssides/8032527/
>>
>> commitComment:
>> jdk-8032527: fix a couple doclint errors in java/awt/geom/Path2D 
>> Summary: A couple @link tags could not be properly specified due to 
>> JDK-8031625.
>>
>> webrevComment:
>> This change was previously blocked because of JDK-8031625 which has 
>> now been fixed.
>>
>>
>> thanks,
>>
>> -steve
>



From Sergey.Bylokhov at oracle.com  Fri May 30 08:10:00 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 30 May 2014 12:10:00 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8041129 and 8017626
In-Reply-To: <53762FD0.9040407@oracle.com>
References: <53716EAB.90508@oracle.com> <53762FD0.9040407@oracle.com>
Message-ID: <53883CD8.6030209@oracle.com>

added @awt-dev

On 16.05.2014 19:33, Sergey Bylokhov wrote:
> Hello.
> Any volunteers? This change is targeted to 8u20, so I would like to 
> push it to jdk9/8 as soon as possible and to catch a possible 
> regressions.
>
> On 5/13/14 5:00 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk 9. This a second  iteration of the fix 
>> for 8041129, because it was changed to cover 8017626 as well.
>>
>> Description of the problem:
>> 8041129: [OGL] surface->sw blit is extremely slow
>>  - The problem is in the glReadPixels(), which is really slow and we 
>> call it very often for each image to make a flip.
>> Solution:
>>  - We call glReadPixels() only once and then flip is done using 
>> memcpy after the whole image was moved from gpu to the memory.
>>  - glPixelStorei were added/removed when necessary.
>>  - Note: actually on my mac the slow path and the fast path(memcpy) 
>> works in the same time. I left it as is, because on other system it 
>> can be faster.
>>
>> 8017626: [OGL] Translucent VolatileImages don't paint correctly
>>  - The problem is in OGLSurfaceToSwBlit. It was implemented with 
>> assumption that the source(ogl) surface contain argb color format, 
>> this is wrong because it use premultiplied alpha.
>> Solution:
>>  - The new ogl blit was added to cover the old behavior 
>> OGLSurfaceToSwBlit(SurfaceType.IntArgbPre,OGLSurfaceData.PF_INT_ARGB_PRE),
>>  - The blit was changed to properly restore the color components if 
>> the source is transparent and destination does not use premultiplied 
>> alpha.
>>
>> Bugs:
>>         https://bugs.openjdk.java.net/browse/JDK-8041129
>>         https://bugs.openjdk.java.net/browse/JDK-8017626
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8041129/webrev.10
>>
>> Benchmarks:
>> Note that each benchmark was executed 3 times(25 seconds each) to be 
>> protected from such spread:
>> D3D-base-nvidia-windows: 61796.32109 (var=308.77%) (5857.64%)
>> |*************
>> |*********************************************************
>> |**************************************************
>> So check the full report for additional information, since the spread 
>> for most of the test is small.
>>
>> ==========================================================
>> Windows 7 x64, lenovo T410, nvidia NVS 3100M
>> http://cr.openjdk.java.net/~serb/8041129/webrev.10/benchmarks/results_win.txt 
>>
>> Summary:
>>   OGL-base-nvidia-windows:
>>     Number of tests:  40
>>     Overall average:  1538.6158105111376
>>     Best spread:      0.26% variance
>>     Worst spread:     51.66% variance
>>     (Basis for results comparison)
>>
>>   D3D-base-nvidia-windows:
>>     Number of tests:  40
>>     Overall average:  25477.2292224911
>>     Best spread:      0.03% variance
>>     Worst spread:     308.77% variance
>>     Comparison to basis:
>>       Best result:      11192.65% of basis
>>       Worst result:     9.13% of basis
>>       Number of wins:   28
>>       Number of ties:   0
>>       Number of losses: 12
>>
>>   OGL-fix-nvidia-windows:
>>     Number of tests:  40
>>     Overall average:  125053.84134106003
>>     Best spread:      0.08% variance
>>     Worst spread:     11.96% variance
>>     Comparison to basis:
>>       Best result:      12631.78% of basis
>>       Worst result:     84.45% of basis
>>       Number of wins:   33
>>       Number of ties:   6
>>       Number of losses: 1
>> ==========================================================
>> OSX 10.8.5, macbook pro retina, nvidia GeForce GT 650M 1024 MB
>> http://cr.openjdk.java.net/~serb/8041129/webrev.10/benchmarks/results_osx_nvidia.txt 
>>
>> Summary:
>>   OGL-base-nvidia-osx:
>>     Number of tests:  20
>>     Overall average:  714.8688065382015
>>     Best spread:      0.16% variance
>>     Worst spread:     2.12% variance
>>     (Basis for results comparison)
>>
>>   OGL-fix-nvidia-osx:
>>     Number of tests:  20
>>     Overall average:  10497.046970040716
>>     Best spread:      0.11% variance
>>     Worst spread:     5.55% variance
>>     Comparison to basis:
>>       Best result:      4479.08% of basis
>>       Worst result:     172.49% of basis
>>       Number of wins:   20
>>       Number of ties:   0
>>       Number of losses: 0
>> ==========================================================
>> OSX 10.8.5, macbook pro retina, Intel HD Graphics 4000
>> http://cr.openjdk.java.net/~serb/8041129/webrev.10/benchmarks/results_osx_intel.txt 
>>
>> Summary:
>>   OGL-base-intel-osx:
>>     Number of tests:  20
>>     Overall average:  3912.1181498636274
>>     Best spread:      0.25% variance
>>     Worst spread:     22.52% variance
>>     (Basis for results comparison)
>>
>>   OGL-fix-intel-osx:
>>     Number of tests:  20
>>     Overall average:  9647.033915964947
>>     Best spread:      0.2% variance
>>     Worst spread:     23.32% variance
>>     Comparison to basis:
>>       Best result:      457.06% of basis
>>       Worst result:     104.3% of basis
>>       Number of wins:   20
>>       Number of ties:   0
>>       Number of losses: 0
>>
>
>


-- 
Best regards, Sergey.



From Sergey.Bylokhov at oracle.com  Fri May 30 08:10:35 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 30 May 2014 12:10:35 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8041644 [OGL] clip is
 ignored during surface->sw blit
In-Reply-To: <537B9171.6000806@oracle.com>
References: <537B8605.9010204@oracle.com>
	<537B8852.90407@oracle.com>	<537B8AE9.4010105@oracle.com>
	<537B8E35.30108@oracle.com> <537B9171.6000806@oracle.com>
Message-ID: <53883CFB.70104@oracle.com>

added awt-dev@

On 20.05.2014 21:31, Sergey Bylokhov wrote:
> On 5/20/14 9:17 PM, Phil Race wrote:
>> On 5/20/2014 10:03 AM, Sergey Bylokhov wrote:
>>> On 5/20/14 8:52 PM, Phil Race wrote:
>>>> So my first question here was. So what does D3D do ? We should just 
>>>> copy that code.
>>> D3D doesn't work as well.
>>>> Then I read the bug report and it says D3D has the same bug
>>>> I don't get why you'd fix it for OGL but not for D3D which seems 
>>>> like the
>>>> way more important case.
>>> OGL is important too, because it is default pipeline on osx. I plan 
>>> to fix D3D case later.
>>
>> And D3D is the default pipeline on Windows !  I submit that there are 
>> (many) more people
>> world-wide using that than OS X.
> I agree but right now I have no tested version of the fix for d3d.
>>
>>> Actually I am not familiar with d3d code and right now I focused on 
>>> hidpi support in SwingNode on OSX.
>>>> So when you check this in we'll just get one more failing 
>>>> regression test.
>>> Yes. It will be bound to the separate CR.
>>
>> At a minimum the test should only run on OS X or should specify 
>> -Dsun.java2d.d3d=false
>> until Windows is resolved.
> Ok. I will add this option to the test before the push.
>>
>> But I really think this should all be checked in as one fix.
>>
>>
>> -phil.
>>
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 5/20/2014 9:42 AM, Sergey Bylokhov wrote:
>>>>> Hello.
>>>>> Please review the fix for jdk 9, which is also targeted for jdk 8u20.
>>>>> Description:
>>>>>     Our implementation of opengl surface-> sw blit does not take 
>>>>> into account the clipped area.
>>>>> Suggested fix:
>>>>>    I intersect a clip and a coordinates of destination, and if the 
>>>>> resulted region is rectangle I use the usual blit, but if the 
>>>>> region is complex I use intermediate buffer(like 
>>>>> OGLAnyCompositeBlit.Blit() or OGLGeneralBlit.Blit()).
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041644
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/8041644/webrev.00
>>>>>
>>>>
>>>
>>>
>>
>
>


-- 
Best regards, Sergey.



From Sergey.Bylokhov at oracle.com  Fri May 30 08:11:03 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 30 May 2014 12:11:03 +0400
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8042103 Deserialization of
 empty java.awt.geom.Path2D will cause an exception
In-Reply-To: <537F94B2.6040608@oracle.com>
References: <53611C5A.8080303@oracle.com>
	<536198F6.1050109@oracle.com>	<53679274.5090304@oracle.com>
	<537F94B2.6040608@oracle.com>
Message-ID: <53883D17.8040908@oracle.com>

added awt-dev@

On 23.05.2014 22:34, Sergey Bylokhov wrote:
> Hello,
> Any volunteers to review the fix?
> On 5/5/14 5:30 PM, Sergey Bylokhov wrote:
>> Hi, Jim.
>> On 01.05.2014 4:44, Jim Graham wrote:
>>> Hi Sergey,
>>>
>>> I think the bug is in the readObject routine.  It sets the initial 
>>> size of the arrays based on if the number of segments/coords is "< 
>>> 0" and it sets them to INIT_SIZE or INIT_SIZE*2 accordingly.  Those 
>>> tests should be "< INIT_SIZE(*2)"...
>>
>> It was my first thought, but we have an API, which allows to set 
>> starting value of capacity to 0.
>> Copy from the bug description:
>> 1.Path2D path = Path2D.Float(int rule, int initialCapacity); while 
>> initialCapacity is 0
>> 2.Path2D path = Path2D.Double(int rule, int initialCapacity);
>> 3.Path2D path = Path2D.Float(Shape s); while s is empty Path2D
>> 4.Path2D path = Path2D.Float(Shape s, AffineTransform at);
>> 5.Path2D path = Path2D.Double(Shape s);
>> 6.Path2D path = Path2D.Double(Shape s, AffineTransform at);
>>
>> based on these I assume that empty capacity is correct value, and 
>> needRoom should be ready for that.
>>
>>>
>>>             ...jim
>>>
>>> On 4/30/14 8:52 AM, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review the fix for jdk 9.
>>>> needRoom() method does not take into account that current array of 
>>>> types
>>>> can be empty. In this case it fails to increase it.
>>>> I handle this case and increase the size of the array by 1 instead of
>>>> INIT_SIZE, because I assume that the user intentionally try to 
>>>> decrease
>>>> memory usage.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042103
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/8042103/webrev.00
>>>>
>>
>>
>
>


-- 
Best regards, Sergey.



From philip.race at oracle.com  Fri May 30 16:01:50 2014
From: philip.race at oracle.com (Phil Race)
Date: Fri, 30 May 2014 09:01:50 -0700
Subject: [OpenJDK 2D-Dev] Merging marlin & pisces rendering engines
In-Reply-To: <CAKjRUT4Es-LHT2Rr6FgWaw7KLuqHY0yCmjUtRfxLOt7rZcoqGQ@mail.gmail.com>
References: <CAKjRUT5zkGvOadndQc+OFiqaJqtxx3GhA02BhF77OSQyrJdhXw@mail.gmail.com>	<CAKjRUT4dsYFMneYvo1ZzPsatcsUr+cq58iYPT3Pwje5KWos-qA@mail.gmail.com>	<CAKjRUT52scryCXDKf9PEguOO9JjbqJGn3XLyxCz_rJrhcAtMaQ@mail.gmail.com>	<CAKjRUT4icTSFDek8aYi9daPovObbuTbNmnMDHCXeZ5nhc76HcQ@mail.gmail.com>	<CAKjRUT4WNgQMK78+MgGo7t=b_z8bw_iJqGWUL-2d946MubS=ug@mail.gmail.com>
	<CAKjRUT4Es-LHT2Rr6FgWaw7KLuqHY0yCmjUtRfxLOt7rZcoqGQ@mail.gmail.com>
Message-ID: <5388AB6E.5060705@oracle.com>

Hi,

If you can generate the webrevs I can host them on cr.openjdk.java.net
and create bug IDs for them. Is that what you are looking for ?

-phil.

On 5/28/14 11:08 AM, Laurent Bourg?s wrote:
>
> Phil,
>
> Do you some guys who could help me merging marlin with pisces in jdk9 ?
>
> I need help creating small sequential patches as webrevs and also 
> reviewers.
>
> I made the MapDisplay tool to perform regression tests vs pisces:
> https://github.com/bourgesl/mapbench
>
> FYI I released marlin 0.4.4 which is now as fast as ductus according 
> to my benchmarks:
> https://github.com/bourgesl/marlin-renderer/releases/latest
>
> https://github.com/bourgesl/marlin-renderer/wiki/Benchmarks
>
> https://bourgesl.github.io/marlin-0.5.4/default/compareResults_ductus_marlin0.4.x.htm#table11
>
> PS: I want to improve rendering quality in next steps.
>
> Regards,
> Laurent
>



From bourges.laurent at gmail.com  Fri May 30 16:38:26 2014
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Fri, 30 May 2014 12:38:26 -0400
Subject: [OpenJDK 2D-Dev] Merging marlin & pisces rendering engines
In-Reply-To: <5388AB6E.5060705@oracle.com>
References: <CAKjRUT5zkGvOadndQc+OFiqaJqtxx3GhA02BhF77OSQyrJdhXw@mail.gmail.com>
	<CAKjRUT4dsYFMneYvo1ZzPsatcsUr+cq58iYPT3Pwje5KWos-qA@mail.gmail.com>
	<CAKjRUT52scryCXDKf9PEguOO9JjbqJGn3XLyxCz_rJrhcAtMaQ@mail.gmail.com>
	<CAKjRUT4icTSFDek8aYi9daPovObbuTbNmnMDHCXeZ5nhc76HcQ@mail.gmail.com>
	<CAKjRUT4WNgQMK78+MgGo7t=b_z8bw_iJqGWUL-2d946MubS=ug@mail.gmail.com>
	<CAKjRUT4Es-LHT2Rr6FgWaw7KLuqHY0yCmjUtRfxLOt7rZcoqGQ@mail.gmail.com>
	<5388AB6E.5060705@oracle.com>
Message-ID: <CAKjRUT5qWkAbRXgDghBMX=8JzBFnPfcWM9aAWZd2ip=MfFa4JA@mail.gmail.com>

Phil,

As I work on pisces / marlin for 1 year, marlin is now bigger and contains
many changes vs pisces code base.

I do not know how to proceed: create smaller patches or a big one ...

Moreover I added debugging code to get statistics & monitoring that are
useless I think in jdk.
I added also many system properties to tune marlin settings.

Did you try marlin ? Or look at its code ?

As it is a fork, Marlin code is GPLv2 + CP like openjdk.

Could you have a quick look at its code and give me your first impressions ?

Thanks for your proposal,
Laurent

Le 30 mai 2014 12:01, "Phil Race" <philip.race at oracle.com> a ?crit :
>
> Hi,
>
> If you can generate the webrevs I can host them on cr.openjdk.java.net
> and create bug IDs for them. Is that what you are looking for ?
>
> -phil.
>
>
> On 5/28/14 11:08 AM, Laurent Bourg?s wrote:
>>
>>
>> Phil,
>>
>> Do you some guys who could help me merging marlin with pisces in jdk9 ?
>>
>> I need help creating small sequential patches as webrevs and also
reviewers.
>>
>> I made the MapDisplay tool to perform regression tests vs pisces:
>> https://github.com/bourgesl/mapbench
>>
>> FYI I released marlin 0.4.4 which is now as fast as ductus according to
my benchmarks:
>> https://github.com/bourgesl/marlin-renderer/releases/latest
>>
>> https://github.com/bourgesl/marlin-renderer/wiki/Benchmarks
>>
>>
https://bourgesl.github.io/marlin-0.5.4/default/compareResults_ductus_marlin0.4.x.htm#table11
>>
>> PS: I want to improve rendering quality in next steps.
>>
>> Regards,
>> Laurent
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20140530/608b3c85/attachment.html>