From sergey.bylokhov at oracle.com  Mon May  1 02:55:57 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 30 Apr 2017 19:55:57 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request for 8159902: OGL surfaces
 are not HiDPI compatible on Linux/Solaris
In-Reply-To: <5deb7d36-ba6f-fa75-6833-9e6c7ce932c8@oracle.com>
References: <5deb7d36-ba6f-fa75-6833-9e6c7ce932c8@oracle.com>
Message-ID: <26419F4E-DCFE-4451-8F51-5A134AE35EE7@oracle.com>

Hi, Semyon.
Should the GLXVSyncOffScreenSurfaceData/WGLVSyncOffScreenSurfaceData be updated as well? Seems it were also overlooked.
I thinks that instead of ?noreg-sqe? label it would be better to add the new bugid to the failed test.

> 
> Hello,
> 
> Please review the fix for jdk9.
> 
> bug:https://bugs.openjdk.java.net/browse/JDK-8159902
> 
> webrev: http://cr.openjdk.java.net/~ssadetsky/8159902/webrev.00/
> 
> Probably, HiDPI support for Linux OGL was forgoten.
> 
> Fix tries to add it now...
> 
> --Semyon
> 
> 



From semyon.sadetsky at oracle.com  Mon May  1 17:05:35 2017
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 1 May 2017 10:05:35 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request for 8159902: OGL surfaces
 are not HiDPI compatible on Linux/Solaris
In-Reply-To: <26419F4E-DCFE-4451-8F51-5A134AE35EE7@oracle.com>
References: <5deb7d36-ba6f-fa75-6833-9e6c7ce932c8@oracle.com>
 <26419F4E-DCFE-4451-8F51-5A134AE35EE7@oracle.com>
Message-ID: <7a967564-e727-a4a3-f614-326578b80fe1@oracle.com>

On 04/30/2017 07:55 PM, Sergey Bylokhov wrote:

> Hi, Semyon.
> Should the GLXVSyncOffScreenSurfaceData/WGLVSyncOffScreenSurfaceData be updated as well? Seems it were also overlooked.
> I thinks that instead of ?noreg-sqe? label it would be better to add the new bugid to the failed test.
The GLXVSyncOffScreenSurfaceData surface will inherit this functionality 
from the GLXOffScreenSurfaceData class after the current fix. The 
WGLVSyncOffScreenSurfaceData surface inherits HiDPI support from the 
WGLOffScreenSurfaceData class.

--Semyon
>> Hello,
>>
>> Please review the fix for jdk9.
>>
>> bug:https://bugs.openjdk.java.net/browse/JDK-8159902
>>
>> webrev: http://cr.openjdk.java.net/~ssadetsky/8159902/webrev.00/
>>
>> Probably, HiDPI support for Linux OGL was forgoten.
>>
>> Fix tries to add it now...
>>
>> --Semyon
>>
>>



From philip.race at oracle.com  Tue May  2 16:51:10 2017
From: philip.race at oracle.com (Phil Race)
Date: Tue, 2 May 2017 09:51:10 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request for 8159902: OGL surfaces
 are not HiDPI compatible on Linux/Solaris
In-Reply-To: <7a967564-e727-a4a3-f614-326578b80fe1@oracle.com>
References: <5deb7d36-ba6f-fa75-6833-9e6c7ce932c8@oracle.com>
 <26419F4E-DCFE-4451-8F51-5A134AE35EE7@oracle.com>
 <7a967564-e727-a4a3-f614-326578b80fe1@oracle.com>
Message-ID: <6c3d17ef-9c9d-539c-fcc4-d66eaeef8d6c@oracle.com>

Seems fine although I agree with Sergey to add the bug id to the test.

-phil.

On 05/01/2017 10:05 AM, Semyon Sadetsky wrote:
> On 04/30/2017 07:55 PM, Sergey Bylokhov wrote:
>
>> Hi, Semyon.
>> Should the GLXVSyncOffScreenSurfaceData/WGLVSyncOffScreenSurfaceData 
>> be updated as well? Seems it were also overlooked.
>> I thinks that instead of ?noreg-sqe? label it would be better to add 
>> the new bugid to the failed test.
> The GLXVSyncOffScreenSurfaceData surface will inherit this 
> functionality from the GLXOffScreenSurfaceData class after the current 
> fix. The WGLVSyncOffScreenSurfaceData surface inherits HiDPI support 
> from the WGLOffScreenSurfaceData class.
>
> --Semyon
>>> Hello,
>>>
>>> Please review the fix for jdk9.
>>>
>>> bug:https://bugs.openjdk.java.net/browse/JDK-8159902
>>>
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8159902/webrev.00/
>>>
>>> Probably, HiDPI support for Linux OGL was forgoten.
>>>
>>> Fix tries to add it now...
>>>
>>> --Semyon
>>>
>>>
>



From philip.race at oracle.com  Tue May  2 20:20:02 2017
From: philip.race at oracle.com (Phil Race)
Date: Tue, 2 May 2017 13:20:02 -0700
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review request for 8178984:
 Unnecessary angle brackets in the Line2D::intersectsLine() javadoc.
In-Reply-To: <e1296c26-0cbe-477a-92cb-84f4df5dc401@default>
References: <e1296c26-0cbe-477a-92cb-84f4df5dc401@default>
Message-ID: <7c3994ae-fcbb-3fe2-e799-8d8ae2d506e2@oracle.com>

Approved. You may push.

-phil.

On 04/20/2017 07:18 AM, Prahalad Kumar Narayanan wrote:
> Hello Semyon
>
> The fix looks good.
>
> Thanks
> Have a good day
>
> Prahalad N.
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 19 Apr 2017 13:56:30 -0700
> From: Semyon Sadetsky <semyon.sadetsky at oracle.com>
> To: 2d-dev at openjdk.java.net
> Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review request for 8178984:
> 	Unnecessary angle brackets in the Line2D::intersectsLine() javadoc.
> Message-ID: <df225d22-f9a5-1f44-0de6-c9104147646f at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hello,
>
> Please review the fix for jdk9.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8178984
>
> webrev: http://cr.openjdk.java.net/~ssadetsky/8178984/webrev.00/
>
> Angle brackets around "true" are removed.
>
> --Semyon



From sergey.bylokhov at oracle.com  Fri May  5 01:15:25 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 4 May 2017 18:15:25 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8179596 Update java.desktop to
	be HTML-5 friendly
Message-ID: <5d4c5a0d-04dd-4a1f-aabe-3e3c85fa3be8@default>

Hello,
Please review the fix for jdk9-dev.
This fix is a part of the effort to make all javadoc in jdk9 be compatible to HTML5.

In the fix the most common issues are fixed.
The issues related to tables will be fixed later, because it is depends from the new html styles which are under review[1].

After the fix the number of errors reported during the build in java.desktop module decreased from 300+ to 110.

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

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047433.html


From bourges.laurent at gmail.com  Fri May  5 05:02:03 2017
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 5 May 2017 07:02:03 +0200
Subject: [OpenJDK 2D-Dev] [10] Marlin2D upgrade 0.7.5
In-Reply-To: <CAKjRUT4mgD9eMeT5jhf_GFvnwpvLiAQk2kj-68W2VMEgV6-a4Q@mail.gmail.com>
References: <CAKjRUT4xU933gxKnMpNoqmp53ZMWm5T7KuhsVZzfysNEkDB3ow@mail.gmail.com>
 <6b7ddf24-62b7-d490-7b3b-54b8ab2ea70a@oracle.com>
 <CAKjRUT4mgD9eMeT5jhf_GFvnwpvLiAQk2kj-68W2VMEgV6-a4Q@mail.gmail.com>
Message-ID: <CAKjRUT48=EOMLE4s2SOJi3wTb2+8kWMDus18diVvw3+3-4WUcg@mail.gmail.com>

Hi Jim,

Would you have time to look at this 2nd webrev ?

Laurent

Le 26 avr. 2017 11:32 PM, "Laurent Bourg?s" <bourges.laurent at gmail.com> a
?crit :

> Hi Jim,
>
> Here is an updated webrev:
> http://cr.openjdk.java.net/~lbourges/marlin/Marlin-075.1/
>
> My comments below explaining changes:
>
> 2017-04-26 1:47 GMT+02:00 Jim Graham <james.graham at oracle.com>:
>
>> Hi Laurent,
>>
>> - I found some fp constants with no "d" or "f" modifier.  I sent a grep
>> output in a separate email...
>>
>
>     I fixed all true matches except in comments.
>
>
>>
>> - Why does FloatMath.java copy the constants from sun.misc rather than
>> refer to them?
>>   (An alternative is a static import or having local copies that copy by
>>    source-based reference (foo_bar = Foo.bar) rather than copying by
>>    human-cut-and-paste)
>>
>
>     This is needed by MarlinFX as sun.misc.FloatConsts is a class
> inaccessible from javafx.graphics module.
>     I prefer copying these constants (source code) to make Marlin2D /
> MarlinFX consistent and avoid exposing the FloatConsts class to modules.
>
>
>>
>> - Should FloatMath be renamed to FPMath or IEEEMath since it now also
>> handles doubles?
>>
>
>     Agreed and I would prefer FPMath, but it can be done later (52 matches)
>
>
>>
>> - MarlinCache - What was the reason to eliminate the mean crossings
>> calculations from the decision on whether or not to use RLE?
>>
>
>     I changed my mind as this calculation only disables 'RLE' and block
> flag optimization early: it is just a shortcut to avoid testing the real
> number of crossing per pixel row i.e. it only save few tests per row. To
> compute the mean crossings, I had to accumulate the edge height so it costs
> 1 add per edge that represents an overhead for lots of edges. Finally I
> prefer having simplified a bit the code.
>
>
>>
>> - MarlinCache line 548 - why the simpler logic here?
>>
>
>     This is related to modified Renderer calls to copyAARow() to better
> handle half-open intervals:
>         before: [maxX + 2] => now: [maxX + 1]
>         // +1 because alpha [pix_minX; pix_maxX[
>         copyAARow(_alpha, lastY, minX, maxX + 1, useBlkFlags);
>
>
>>
>> - MarlinProperties, getLog2_XY - 0 to 4 is 1 to 16 subpixel locations in
>> X or Y but you list the subpixel limits as 1 to 256.  Also, it looks like
>> the real limits are 0 to 8 which really does work out to 1 to 256.  So, I
>> think the "4" in the comment is incorrect and should be "8"?
>>
>
>     Fixed getSubPixel_Log2_X()
>
>
>>
>> - MarlinProperties - TileSize vs TileWidth.  Is there a reason you
>> haven't created a TileHeight property?  I could see a couple of ways of
>> going here:
>>    - TileSize means height and TileWidth is new which is just odd naming
>>      In this case, I'd make the default for TileWidth be the value for
>> TileSize
>>      otherwise setting tilesize used to set both W&H, but now it only
>> sets H?
>>    - TileSize is legacy and new values are TileWidth and TileHeight
>>      Both default to TileSize if not specified
>> In either case, I would think that TileWidth should default to TileSize?
>>
>
>     Fixed, I adopted the first solution and getTileWidth_Log2() uses
> getTileSize_Log2() to get the default value (W=H)
>
>
>>
>> - MarlinProperties - Inc/Dec - constants don't end with d or f.
>>
>
>     Fixed.
>
>
>>
>> - MarlinProperties - getFloat() takes doubles for def/min/max?
>>
>
>     Fixed.
>
>
>>
>> - MarlinTileGenerator - lines 67,69 - null is the default value for fields
>>
>
>     I prefer to be explicit (netbeans reports a warning): left unchanged.
>
>
>>
>> - MarlinTileGenerator,MarlinRenderer - all of the methods called on rdrF
>> and rdrD have the same signature.  Why not have MarlinRenderer include
>> those methods and then you just need to store a single MarlinRenderer field
>> and be able to manipulate either type...?
>>
>
>     I agree. I tried but benchamrks proved that interface calls method
> were slower than monomorphic calls so I adopted this bimorphic call
> optimization where only 1 type is really used at runtime.
>
>
>>
>> - MarlinTileGenerator.TH_AA_ALPHA_00/FF - seem misnamed, really they are
>> low and high thresholds for filling.  Maybe LO and HI?
>>
>
>     Renamed as TH_AA_ALPHA_FILL_EMPTY & TH_AA_ALPHA_FILL_FULL
>
>
>>
>> - MarlinTileGenerator, line 416,443,508 - Isn't that "skip" instead of
>> "fill"?
>>
>
>     Fixed.
>
>
>>
>> - MarlinTileGenerator, line 420,554,687 - Isn't cx >= aax0?  And isn't x1
>> >= aax0? ???
>>
>
>     Fixed comment:
>     // now: cx >= x0 and cx >= aax0
>
>
>>
>> - MarlinTileGenerator, line 491 - spacing on byte cast
>>
>
>     Fixed.
>
>
>>
>> - MarlinTilegenerator, line 655 - "Clear" or "Fill"?
>>
>
>     Fixed.
>
>
>>
>> - Renderer, line 85,114 - maybe add a line saying that is the result of
>> <name> test?  Did we put that test into the repo anywhere?
>>
>
>     Added comment: 'TestNonAARasterization: cubics/quads' (not in repo,
> only in JBS)
>
>
>>
>> - Renderer, line 1318,1365 - that was fallout from the half-open stuff at
>> 1391, right?
>>
>
>     Exactly, I fixed handling half-open intervals in MarlinFX so it is a
> backport.
>
>
>>
>> - Stroker, line 112 - "* 8"?  Or perhaps "* 6 + 2" since the endpoints
>> are shared?
>>
>
>     Yes endpoints are shared so I fixed the capacity
>
>
>>
>> - Stroker, line 347,376 - it appears to still use m[off],m[off+1] instead
>> of 0,1...?
>>
>
>     Fixed comments.
>
>
>>
>> - Stroker, line 377 - safecomputeMiter -> safeComputeMiter?  Also, this
>> looks to be some sort of "compute something for an offset for quads"
>> method, at least in the way it is used, even if it does look similar to the
>> computeMiter method.
>>
>
>     Renamed the method; it was backported from openpisces (so I did not
> really study the approach)
>
>
>>
>> - Stroker, line 841 - "winden" => "widen"
>>
>
>     Fixed.
>
>
>>
>> - Stroker, lines 839,847,856,866 - there is no p4
>>
>
>     Already mentioned: see https://bugs.openjdk.java.net/
> browse/JDK-8170029
>     To be fixed later
>
>
>>
>> I'm assuming that the D*.java files were all generated from the regular
>> files using a sed script?  I skipped those (for now)...
>>
>
> I also fixed D* files.
>
> Laurent
>
>
>> On 4/22/17 4:28 AM, Laurent Bourg?s wrote:
>>
>>> Hi,
>>>
>>> I am pleased to have successfully upgraded my machine with OpenJDK10 and
>>> merged my Marlin 0.7.5 release (dec 2016) with
>>> its Java2d variant.
>>>
>>> Please review this Marlin2D upgrade to Marlin 0.7.5:
>>>
>>> JBS: no bug yet for OpenJDK 10
>>> webrev: http://cr.openjdk.java.net/~lbourges/marlin/Marlin-075.0/
>>>
>>> Changes:
>>> - Improved MarlinTileGenerator to efficiently handle asymetric tiles (W
>>> x H) with almost full / empty fills
>>> - Added Marlin Double-precision pipeline
>>> - MarlinFX backports (Dasher, Stroker changes from OpenPisces)
>>> - dead code & few comment removals in Strokers
>>> - fixed all floating-point number literals to be x.0f or x.0d to
>>> simplify the conversion between float & double variants
>>>
>>> As this patch is huge, do you want me to provide webrevs against Float
>>> vs Double pipelines or against OpenJFX10 ?
>>>
>>> PS: I forgot to upgrade the copyright headers to 2017, but will do later
>>>
>>> Cheers,
>>> Laurent
>>>
>>
>
>
> --
> --
> Laurent Bourg?s
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170505/d3e07e68/attachment.html>

From alexey.menkov at oracle.com  Fri May  5 17:43:58 2017
From: alexey.menkov at oracle.com (Alex Menkov)
Date: Fri, 5 May 2017 10:43:58 -0700
Subject: [OpenJDK 2D-Dev] <Sound Dev> [9] Review Request: 8179596 Update
 java.desktop to be HTML-5 friendly
In-Reply-To: <5d4c5a0d-04dd-4a1f-aabe-3e3c85fa3be8@default>
References: <5d4c5a0d-04dd-4a1f-aabe-3e3c85fa3be8@default>
Message-ID: <e0795dbe-5529-89be-43fa-ffd0b55156d2@oracle.com>

Overall looks good.
One minor point - there are several places when you replace <center> 
with <p> without end </p>.
Usually absent </p> doesn't cause any problem, but it would be better to 
have end tags for all elements.

I see this in
src/java.desktop/share/classes/javax/sound/midi/MidiMessage.java
src/java.desktop/share/classes/javax/sound/sampled/FloatControl.java
src/java.desktop/share/classes/javax/sound/sampled/TargetDataLine.java
src/java.desktop/share/classes/javax/swing/SizeSequence.java

--alex

On 05/04/2017 18:15, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk9-dev.
> This fix is a part of the effort to make all javadoc in jdk9 be compatible to HTML5.
>
> In the fix the most common issues are fixed.
> The issues related to tables will be fixed later, because it is depends from the new html styles which are under review[1].
>
> After the fix the number of errors reported during the build in java.desktop module decreased from 300+ to 110.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179596
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8179596/webrev.00
> Specdiff: http://cr.openjdk.java.net/~serb/8179596/specdiff.00
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047433.html
>


From sergey.bylokhov at oracle.com  Fri May  5 19:37:17 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 5 May 2017 12:37:17 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] <Sound Dev> [9] Review Request: 8179596 Update
 java.desktop to be HTML-5 friendly
Message-ID: <e2e40bf4-9f2f-46f2-86a8-1ceca25e23e6@default>

Hi, Alexey.
Yes it is possible to add </p> to this changes, but actually </p> tag is not used in JavaSound docs. The last one were removed a few years ago. The <p> tag is used in assumption that it affect the text till the next <p> or till the end of the doc.
So for example in the MidiMessage.java/SizeSequence.java there are a few <p> tags which affects the text till the next <p>, and in this fix just one more <p> was added in the middle.

----- alexey.menkov at oracle.com wrote:

> Overall looks good.
> One minor point - there are several places when you replace <center> 
> with <p> without end </p>.
> Usually absent </p> doesn't cause any problem, but it would be better
> to 
> have end tags for all elements.
> 
> I see this in
> src/java.desktop/share/classes/javax/sound/midi/MidiMessage.java
> src/java.desktop/share/classes/javax/sound/sampled/FloatControl.java
> src/java.desktop/share/classes/javax/sound/sampled/TargetDataLine.java
> src/java.desktop/share/classes/javax/swing/SizeSequence.java
> 
> --alex
> 
> On 05/04/2017 18:15, Sergey Bylokhov wrote:
> > Hello,
> > Please review the fix for jdk9-dev.
> > This fix is a part of the effort to make all javadoc in jdk9 be
> compatible to HTML5.
> >
> > In the fix the most common issues are fixed.
> > The issues related to tables will be fixed later, because it is
> depends from the new html styles which are under review[1].
> >
> > After the fix the number of errors reported during the build in
> java.desktop module decreased from 300+ to 110.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8179596
> > Webrev can be found at:
> http://cr.openjdk.java.net/~serb/8179596/webrev.00
> > Specdiff: http://cr.openjdk.java.net/~serb/8179596/specdiff.00
> >
> > [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047433.html
> >


From philip.race at oracle.com  Fri May  5 19:54:26 2017
From: philip.race at oracle.com (Phil Race)
Date: Fri, 5 May 2017 12:54:26 -0700
Subject: [OpenJDK 2D-Dev] CFV: New2d group member : Laurent Bourges
Message-ID: <7222caf8-339b-923c-c837-a36c87d8c576@oracle.com>

I hereby nominate Laurent Bourges to membership in the 2D group.

Laurent is the principal (almost sole) author of the Marlin Renderer 
contributed
into OpenJDK via the Graphics Rasterizer project [1] and integrated into 
JDK 9
via JEP 265 [2]. In addition to that single extremely significant and large
contribution, Laurent has contributed additional fixes and enhancements to
Marlin. He is a JDK 9 and JDK 10 committer [3]
The list of JDK 9 commits/contributions can be found via [4].
He has continued to enhance Marlin and been consistently active on the 
2d-dev
mailing list [5] for over 4 years.

Votes are due by 19th May 2017

//Only current Members of the 2D Group [6] are eligible to vote on this 
nomination.
For Lazy Consensus voting instructions, see [7].

-Phil.

[1] http://openjdk.java.net/projects/graphics-rasterizer/
[2] https://bugs.openjdk.java.net/browse/JDK-8131760
[3] http://openjdk.java.net/census#lbourges
[4] http://hg.openjdk.java.net/jdk9/client/jdk/log?rev=lbourges
[5] http://mail.openjdk.java.net/pipermail/2d-dev/
[6] http://openjdk.java.net/census#2d
[7] http://openjdk.java.net/groups/#member-vote 
<http://openjdk.java.net/groups/#member-vote%7C>

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

From sergey.bylokhov at oracle.com  Fri May  5 19:57:12 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 5 May 2017 12:57:12 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] CFV: New2d group member : Laurent Bourges
Message-ID: <6718dc07-eeac-4b87-8f28-2a5f36890d04@default>

Vote: yes 

----- philip.race at oracle.com wrote: 
> 
I hereby nominate Laurent Bourges to membership in the 2D group. 
> 
> Laurent is the principal (almost sole) author of the Marlin Renderer contributed 
> into OpenJDK via the Graphics Rasterizer project [1] and integrated into JDK 9 
> via JEP 265 [2]. In addition to that single extremely significant and large 
> contribution, Laurent has contributed additional fixes and enhancements to 
> Marlin. He is a JDK 9 and JDK 10 committer [3] 
> The list of JDK 9 commits/contributions can be found via [4]. 
> He has continued to enhance Marlin and been consistently active on the 2d-dev 
> mailing list [5] for over 4 years. 
> 
> Votes are due by 19th May 2017 
> 
> Only current Members of the 2D Group [6] are eligible to vote on this nomination. 
> For Lazy Consensus voting instructions, see [7]. 
> 
> -Phil. 
> 
> [1] http://openjdk.java.net/projects/graphics-rasterizer/ 
> [2] https://bugs.openjdk.java.net/browse/JDK-8131760 
> [3] http://openjdk.java.net/census#lbourges 
> [4] http://hg.openjdk.java.net/jdk9/client/jdk/log?rev=lbourges 
> [5] http://mail.openjdk.java.net/pipermail/2d-dev/ 
> [6] http://openjdk.java.net/census#2d 
> [7] http://openjdk.java.net/groups/#member-vote 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170505/a529717e/attachment.html>

From philip.race at oracle.com  Fri May  5 19:56:53 2017
From: philip.race at oracle.com (Phil Race)
Date: Fri, 5 May 2017 12:56:53 -0700
Subject: [OpenJDK 2D-Dev] CFV: New2d group member : Laurent Bourges
In-Reply-To: <7222caf8-339b-923c-c837-a36c87d8c576@oracle.com>
References: <7222caf8-339b-923c-c837-a36c87d8c576@oracle.com>
Message-ID: <bab661ba-900f-cc31-2207-d812fccf030e@oracle.com>

Vote: yes

-phil.


From philip.race at oracle.com  Fri May  5 20:02:16 2017
From: philip.race at oracle.com (Phil Race)
Date: Fri, 5 May 2017 13:02:16 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8179596 Update
 java.desktop to be HTML-5 friendly
In-Reply-To: <5d4c5a0d-04dd-4a1f-aabe-3e3c85fa3be8@default>
References: <5d4c5a0d-04dd-4a1f-aabe-3e3c85fa3be8@default>
Message-ID: <ac772f7e-e131-9811-b67f-f3ebe54b7f15@oracle.com>

This all looks OK to me.

-phil.

On 05/04/2017 06:15 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk9-dev.
> This fix is a part of the effort to make all javadoc in jdk9 be compatible to HTML5.
>
> In the fix the most common issues are fixed.
> The issues related to tables will be fixed later, because it is depends from the new html styles which are under review[1].
>
> After the fix the number of errors reported during the build in java.desktop module decreased from 300+ to 110.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179596
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8179596/webrev.00
> Specdiff: http://cr.openjdk.java.net/~serb/8179596/specdiff.00
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047433.html



From sergey.bylokhov at oracle.com  Fri May  5 20:20:45 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 5 May 2017 13:20:45 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] Review request for 8029339 Custom
 MultiResolution image support on HiDPI displays
Message-ID: <dbb08a3a-d013-45d2-88a3-1b40ba105fdc@default>

Hi, Jim, Phil.
> That sounds useful, but is your example code complete?  Don't you need
> to declare the "image" variable with the 
> appropriate generic type?

I guess its s too late to change it right now?

Now I thinking of possibility to change the Robot API to simplify its usage in the tests.
Just one method which return BufferedImage.
capture = robot.createCompatibleScreenCapture(rect);

The disadvantage of MRI in the current API is that MRI cannot be saved to the file, and it is not possible to quickly access its pixels, and requires an instanceof check.

What do you think? Or we can fix both?

> 
> Also, do we get a lot of compiler warnings if you want to ignore the
> generics in other code?  What's the pain point if 
> you don't care what the types of the images are?  (I suppose the most
> common case is that people have an "Image" without 
> even realizing that it is an MRI in the first place so this is only
> for those who want to manipulate MRIs)...
> 
> 			...jim
> 
> On 3/29/17 1:22 PM, Sergey Bylokhov wrote:
> > Hi, Jim, Phil.
> > I have started to use MRI and a new Robot in some of the tests and
> wonder why the MultiResolutionImage does not use
> > generics for getResolutionVariants()?
> >
> > So for example if we have an API like:
> >
> http://download.java.net/java/jdk9/docs/api/java/awt/Robot.html#createMultiResolutionScreenCapture-java.awt.Rectangle-
> > We cannot specify that the MRI contains BufferedImage(not just an
> image). So the users will need to check it via
> > instance of and cast.
> > So in the worse case the user will get something like this:
> >
> > =====
> > Test.java
> >             MultiResolutionImage image =
> >                     robot.createMultiResolutionScreenCapture(rect);
> >             List<Image> resolutionVariants =
> image.getResolutionVariants();
> >
> >             if (resolutionVariants.size() > 1) {
> >                 Image tmp = resolutionVariants.get(1);
> >                 if (tmp instanceof BufferedImage) {
> >                     capture = (BufferedImage) tmp;
> >                 }
> >             } else {
> >                 Image tmp = resolutionVariants.get(0);
> >                 if (tmp instanceof BufferedImage) {
> >                     capture = (BufferedImage) tmp;
> >                 }
> >             }
> > =====
> >
> > I am not sure but for writing the tests, I feel something like this
> will be simpler:
> > =====
> > Robot.java
> >     public synchronized MultiResolutionImage<BufferedImage>
> >             createMultiResolutionScreenCapture(Rectangle screenRect)
> {
> > //
> > Test.java
> >             MultiResolutionImage image =
> >                     robot.createMultiResolutionScreenCapture(rect);
> >             List<BufferedImage> resolutionVariants =
> image.getResolutionVariants();
> >
> >             if (resolutionVariants.size() > 1) {
> >                     capture = resolutionVariants.get(1);
> >             } else {
> >                     capture = resolutionVariants.get(0);
> >             }
> > =====
> > Or even this:
> > capture = robot.createCompatibleScreenCapture(rect);
> >
> >
> >
> >>
> >> Hi Alexandr,
> >>
> >> Sorry that this fell into the cracks.  Here are some fairly minor
> updates:
> >>
> >> AbstractMRI - getGraphics() should include "getGraphics() not
> supported on Multi-Resolution Images" as the exception
> >> description text.
> >>
> >> AbstractMRI - getBaseImage() should have doc comments:
> >> /**
> >> * Return the base image representing the best version of the image
> >> * for rendering at the default width and height.
> >> * @return the base image of the set of multi-resolution images
> >> */
> >> (Does it need an @since given that the entire interface is @since
> 1.9?)
> >>
> >> BaseMRI - the doc comments (both the class comment and the
> constructor comments) don't start with "/**" so they aren't
> >> really doc comments, but they look good so make them so.
> >>
> >> BaseMRI - class comment - "The implementation will return the first
> ... satisfy the rendering request."  Add another
> >> sentence right there "The last image in the array will be returned
> if no suitable image is found that is larger than
> >> the rendering request."
> >>
> >> BaseMRI - move "For best effect ..." should be moved to a new
> paragraph and mention that no exception will be thrown
> >> if the images are not sorted as suggested.
> >>
> >> RenderingHints - comments:
> >> DEFAULT, SIZE_FIT, DPI_FIT - "an image resolution variant is chosen
> ..." (add "an")
> >> DEFAULT - "... which may depend on the policies of the platform"
> >> SIZE_FIT, DPI_FIT "... on the DPI of ..." (add "the")
> >>
> >> SunHints - descriptor texts:
> >> SIZE_FIT, DPI_FIT "based on the DPI" (add "the")
> >>
> >> MRCachedImage - remind me what this is used for?
> >> MRCachedImage.getResolutionVariant - use ceil or round instead of
> (int) cast?  ceil() would match the actions of
> >> MRToolkitImage better.  Also note following comment about precision
> with SG2D.
> >>
> >> SG2D/MRI - the interface declares the values as float, the usage in
> SG2D computes values in double and then truncates
> >> them to int to pass to the interface - should we upgrade the
> interface to double for completeness?  If not, then the
> >> usage in SG2D should at least pass in float precision.
> >>
> >> SG2D.getResolutionVariant - using destRegionWH to calculate
> destImageWH can involve a lot of "do some math and then
> >> later have additional code undo it".  Would it be faster to just
> compute destImageWH directly, as in:
> >>
> >> float destImageWidth, destImageHeight;
> >>
> >> if (BASE) {
> >>    destImageWH = srcWH;
> >> } else if (DPI) {
> >>    destImageWH = (float) abs(srcWH * devScale);
> >> } else {
> >>    double destRegionWidth, destRegionHeight;
> >>    if (type) {
> >>    ...
> >>    }
> >>    destImageWH = (float) abs(srcWH * destRegionWH / swh);
> >> }
> >> Image rv = img.getRV(destImageWH);
> >>
> >> On the other hand, the last "else" is probably the most common case
> so this doesn't save anything in the common case,
> >> but it avoids a bunch of math that could introduce rounding error
> for the BASE/DPI cases (even though it is done in
> >> doubles).
> >>
> >> Is there intent to have the default case be mapped to DPI_FIT for
> Windows?
> >>
> >> MultiResolutionRenderinHints.java - should have "Test" appended to
> the name
> >>
> >> MRRHTest - why not render to a BufferedImage and avoid Robot? 
> Could it tap into internal APIs to create a
> >> BImg/compatibleImage with a given devScale?
> >>
> >> MRRHTest - why allow up to delta=50 on the comparison?
> >>
> >> MRRHTest - since the scale factor comes from a dialog, we depend on
> running this on a HiDPI display to fully test the
> >> hints?  Could using "scaled compatible images" allow testing this
> more definitively?
> >>
> >> MRRHTest - remove println before pushing?
> >>
> >> MRRHTest - probably shouldn't have a "right answer" for DEFAULT -
> it should probably just pass if the operation
> >> doesn't throw an exception?
> >>
> >> ...jim
> >>
> >>
> >> On 4/15/15 7:04 AM, Alexander Scherbatiy wrote:
> >>>
> >>>   Hello,
> >>>
> >>>  Could you review the updated fix:
> >>>    http://cr.openjdk.java.net/~alexsch/8029339/webrev.08/
> >>>
> >>>  - SunGraphics2D is updated to calculate the resolution variant
> size
> >>> according to the _BASE, _DPI_FIT, and _SIZE_FIT resolution
> rendering hint
> >>>  - MultiResolutionRenderingHints test is added
> >>>
> >>>  Thanks,
> >>>  Alexandr.
> >>>
> >>>
> >>> On 4/7/2015 1:02 PM, Jim Graham wrote:
> >>>> This is an interesting suggestion that would let us keep the
> >>>> implementation of the various hints centralized and simplify the
> >>>> interface to the part of the mechanism that is most tied in to
> the
> >>>> implementation specifics of the database of media variants -
> which is
> >>>> housed in the MRI-implementing object.
> >>>>
> >>>> I'm not sure we ever identified any need to customize the logic
> of
> >>>> "what size is needed for this render operation" beyond what we
> >>>> expressed in the hints, and given that the platform defaults may
> not
> >>>> be easy to express to an arbitrary implementation, it is
> probably
> >>>> better to put that part of the logic in SG2D, controlled by the
> easy
> >>>> to express hints and keep the current API both simple to
> implement and
> >>>> flexible to use.  Even if there was a need to customize that part
> of
> >>>> the operation (the "what size is relevant to this rendering
> operation"
> >>>> decision) beyond what the hints suggest, it would be
> inappropriate to
> >>>> tie that in to the "find me media" aspect of the MRI interface
> >>>> anyway.  So, best to keep them separate and have the hints affect
> what
> >>>> SG2D does and have the MRI focused on just storing (possibly
> creating)
> >>>> and managing/finding the variants.
> >>>>
> >>>>            ...jim
> >>>>
> >>>> On 4/1/15 6:46 AM, Alexander Scherbatiy wrote:
> >>>>> On 3/27/2015 12:48 AM, Jim Graham wrote:
> >>>>>> Hi Alexander,
> >>>>>
> >>>>>   http://cr.openjdk.java.net/~alexsch/8029339/webrev.07/
> >>>>>   I have updated the fix according to the comments except
> >>>>> RenderingHints.
> >>>>>
> >>>>>   RenderingHints are supposed to be set on Graphics2D and they
> have
> >>>>> keys/values which are not relevant to the getResolutionVariant()
> method.
> >>>>>   Graphics objects chooses an alternative according to the set
> >>>>> rendering hints.
> >>>>>   May be what SG2D should do just calculate dest image size for
> the
> >>>>> given resolution variant hint (_BASE - base image size,
> _SIZE_FIT -
> >>>>> including scale factor and graphics transform (Mac algorithm),
> >>>>> _DPI_FIT - scaled according to the system DPI) and then pass
> them to
> >>>>> the getResolutionVariant() method?
> >>>>>
> >>>>>  Thanks,
> >>>>>  Alexandr.
> >>>>>
> >>>>>>
> >>>>>> MRI.java:
> >>>>>>
> >>>>>> Who is the intended audience for the recommendation in the
> interface
> >>>>>> to cache image variants?  Are we asking the developers who call
> the
> >>>>>> methods on the interface to cache the answers? That would be
> unwise
> >>>>>> because the list of variants may change over time for some
> MRIs. Are
> >>>>>> we speaking to the implementer? If so, then I think that it is
> >>>>>> unnecessary to remind implementers of basic implementation
> >>>>>> strategies like "cache complicated objects".
> >>>>>>
> >>>>>> How about this wording for the getRV() method? - "Gets a
> specific
> >>>>>> image that is the best variant to represent this logical image
> at
> >>>>>> the indicated size and screen resolution."
> >>>>>>
> >>>>>> Perhaps we should clarify in the doc comments for the
> dimension
> >>>>>> arguments in getRV() that the dimensions are measured in
> pixels?
> >>>>>>
> >>>>>> line 56 - delete blank line between doc comment and method
> declaration
> >>>>>>
> >>>>>> Also, it is probably overkill to document that the interface
> >>>>>> getVariants() method returns an unmodifiable list. Responsible
> >>>>>> implementations would probably use an unmodifiable list, but I
> don't
> >>>>>> think it should be required by the interface.  We do need to
> specify
> >>>>>> that it isn't required to be modifiable so that a caller
> doesn't
> >>>>>> expect to be able to modify it, but that is a looser spec. 
> How
> >>>>>> about "Gets a readable list of all resolution variants.  Note
> that
> >>>>>> many implementations might return an unmodifiable list."?
> >>>>>>
> >>>>>> AbstractMIR.java:
> >>>>>>
> >>>>>> "provides a default implementation for the MRI" or "provides
> default
> >>>>>> implementations of several methods in the <MRI> interface and
> the
> >>>>>> <Image> class"?  Actually, I'll note that it provides none of
> the
> >>>>>> implementations of the MRI methods so maybe it should be
> "provides
> >>>>>> default implementations of several <Image> methods for classes
> that
> >>>>>> want to implement the <MRI> interface"?
> >>>>>>
> >>>>>> In the doc example - wrap the list to make it unmodifiable
> >>>>>>
> >>>>>> The doc example could be made 2 or 3 lines shorter by simply
> >>>>>> assuming the base image is in index 0 (it's just an example so
> I'm
> >>>>>> not sure the flexibility needs to be a part of the example).
> >>>>>>
> >>>>>> getGraphics is allowed by the Image interface to return null.
> >>>>>> Actually, the exact wording is that it can only be called for
> >>>>>> "offscreen images" and a MRI is technically not "an offscreen
> >>>>>> image".  Perhaps we should return null here since modifying the
> base
> >>>>>> image is unlikely to modify the variants and arguably it would
> be
> >>>>>> required by the wording in the method docs (even if the base
> image
> >>>>>> was an offscreen, the MRI produced from it stops being an
> offscreen)?
> >>>>>>
> >>>>>> Are all of the empty "@Inherit" comments needed?  I thought
> >>>>>> inheritance was the default?
> >>>>>>
> >>>>>> BaseMRI.java:
> >>>>>>
> >>>>>> "This class is [an] array-based implementation of the {AMRI}
> class"
> >>>>>> (missing "an" and "the")
> >>>>>>
> >>>>>> We should probably include the comment about the sorting of
> the
> >>>>>> images in the class comments as well as document that the
> algorithm
> >>>>>> is a simple scan from the beginning for the first image large
> enough
> >>>>>> (and default == last image).  The algorithm also might not work
> very
> >>>>>> well if the images are not monotonically both wider and taller.
>  How
> >>>>>> about adding this to the class comments:
> >>>>>>
> >>>>>> "The implementation will return the first image variant in the
> array
> >>>>>> that is large enough to satisfy the rendering request. For
> best
> >>>>>> effect the array of images should be sorted with each image
> being
> >>>>>> both wider and taller than the previous image. The base image
> need
> >>>>>> not be the first image in the array."
> >>>>>>
> >>>>>> getVariants() - you need to return an unmodifiable list.
> asList()
> >>>>>> returns a list that "writes back" to the array.  You need to
> use
> >>>>>> Collections.unmodifiableList(Arrays.asList(array)).
> >>>>>>
> >>>>>> RenderingHints.java:
> >>>>>>
> >>>>>> Where do we process this hint?  Don't we need to pass it to
> the
> >>>>>> getVariant() method?
> >>>>>>
> >>>>>> I don't understand the hint values other than the one that
> always
> >>>>>> uses the base image.  Default I guess gives us the ability to
> use
> >>>>>> the Mac algorithm of "next larger size" on Mac and "based on
> Screen
> >>>>>> DPI" on Windows, but the 3rd value "ON" is so vague as to not
> have
> >>>>>> any meaning.  Perhaps we should just delete it, but then do we
> just
> >>>>>> always do the Mac method? Or do we vaguely have our internal
> images
> >>>>>> have a platform-specific method and the Abstract/Base classes
> just
> >>>>>> do what they want with no control from the user?  In FX we are
> also
> >>>>>> still struggling with this issue and we may likely just do what
> the
> >>>>>> Mac does in all cases, but perhaps AWT needs to "behave like
> the
> >>>>>> platform" more?  If we are going to have actual values, then we
> need
> >>>>>> to have them do something, which means:
> >>>>>>
> >>>>>> - SG2D needs to track the hint just like we do the other hints
> that
> >>>>>> affect our processing
> >>>>>> - MRI.getVariant() needs to have the hint as an argument
> >>>>>> - BaseMRI should probably do something with that hint
> >>>>>> - hint values should include:
> >>>>>>    - ..._DEFAULT - implementation gets to decide
> >>>>>>    - ..._BASE - always use the base image
> >>>>>>    - ..._SIZE_FIT - Mac algorithm of smallest image that is big
> enough
> >>>>>>    - ..._DPI_FIT - choose based on DPI of the screen, ignoring
> >>>>>> transform
> >>>>>>
> >>>>>> line 978 - missing blank line between fields
> >>>>>>
> >>>>>> SG2D.java:
> >>>>>>
> >>>>>> - The interface says that you will be passing in the "logical
> DPI"
> >>>>>> of the display, but here you are actually passing in the
> screen's
> >>>>>> scale factor.
> >>>>>>
> >>>>>> BaseMRITest.java:
> >>>>>>
> >>>>>> - testBaseMRI also passes in a scale rather than a DPI to the
> MRI
> >>>>>> method.
> >>>>>>
> >>>>>> - How does the modification test pass when the implementation
> >>>>>> doesn't use unmodifiable lists?
> >>>>>>
> >>>>>> MRITest.java:
> >>>>>>
> >>>>>> - also uses scale rather than DPI in several places
> >>>>>>
> >>>>>>        ...jim
> >>>>>>
> >>>>>> On 3/13/15 6:34 AM, Alexander Scherbatiy wrote:
> >>>>>>>
> >>>>>>>   Hello,
> >>>>>>>
> >>>>>>>   Could you review the proposed API based on
> MultiresolutionImage
> >>>>>>> interface:
> >>>>>>>     http://cr.openjdk.java.net/~alexsch/8029339/webrev.06/
> >>>>>>>
> >>>>>>>  - return unmodifiable list comment is added to the
> >>>>>>> getResolutionVariants() method javadoc in
> MultiresolutionImage
> >>>>>>> interface
> >>>>>>>  - base image size arguments are removed form the
> >>>>>>> getResolutionVariant(...) method in MultiresolutionImage
> interface
> >>>>>>>  - BaseMultiResolutionImage class that allows to create a
> >>>>>>> multi-resolution image based on resolution variant array is
> added
> >>>>>>>  - the test for the BaseMultiResolutionImage is added
> >>>>>>>
> >>>>>>>  Thanks,
> >>>>>>>  Alexandr.
> >>>>>>>
> >>>>>>> On 2/14/2015 3:23 AM, Jim Graham wrote:
> >>>>>>>> The second solution looks good.  I'd make it standard
> practice
> >>>>>>>> (perhaps even mentioned in the documentation) to return
> unmodifiable
> >>>>>>>> lists from the getVariants() method.  The Collections class
> provides
> >>>>>>>> easy methods to create these lists, and it sends a clear
> message to
> >>>>>>>> the caller that the list was provided for them to read, but
> not write
> >>>>>>>> to.  Otherwise they may add a new image to the list you
> provided them
> >>>>>>>> and wonder why it wasn't showing up.  Also, an unmodifiable
> list can
> >>>>>>>> be cached and reused for subsequent calls without having to
> create a
> >>>>>>>> new list every time.
> >>>>>>>>
> >>>>>>>> In getResolutionVariant() was there a reason why the base
> dimensions
> >>>>>>>> were provided as float?  The destination dimensions make
> sense as
> >>>>>>>> float since they could be the result of a scale, but the
> source
> >>>>>>>> dimensions are typically getWidth/getHeight() on the base
> image.  A
> >>>>>>>> related question would be if they are needed at all, since
> the
> >>>>>>>> implementation should probably already be aware of what the
> base
> >>>>>>>> image
> >>>>>>>> is and what its dimensions are.  I'm guessing they are
> provided
> >>>>>>>> because the implementation in SG2D already knows them and it
> makes it
> >>>>>>>> easier to forward the implementation on to a shared (static?)
> method?
> >>>>>>>>
> >>>>>>>> With respect to default implementations, I take it that the
> >>>>>>>> BaseMRI is
> >>>>>>>> along the pattern that we see in Swing for Base classes.
> Would it be
> >>>>>>>> helpful to provide an implementation (in addition or instead)
> that
> >>>>>>>> allows a developer to take a bunch of images and quickly make
> an MRI
> >>>>>>>> without having to override anything?  The implementations of
> >>>>>>>> getBaseImage() and getResolutionVariants() are pretty
> straightforward
> >>>>>>>> and a fairly reasonable default algorithm can be provided
> for
> >>>>>>>> getRV(dimensions).  This question is more of an idle question
> for my
> >>>>>>>> own curiosity than a stumbling block...
> >>>>>>>>
> >>>>>>>>            ...jim
> >>>>>>>>
> >>>>>>>> On 1/22/2015 6:49 AM, Alexander Scherbatiy wrote:
> >>>>>>>>>
> >>>>>>>>>   Hi Phil,
> >>>>>>>>>
> >>>>>>>>>   I have prepared two versions of the proposed API:
> >>>>>>>>>
> >>>>>>>>>   I) Resolution variants are added directly to the Image:
> >>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/list/webrev.00
> >>>>>>>>>
> >>>>>>>>>   II)  MultiResolutionImage interface is used:
> >>>>>>>>> http://cr.openjdk.java.net/~alexsch/8029339/webrev.05
> >>>>>>>>>
> >>>>>>>>>   It could help to decide which way should be chosen for the
> the
> >>>>>>>>> multi-resolution image support.
> >>>>>>>>>
> >>>>>>>>>   Below are some comments:
> >>>>>>>>>
> >>>>>>>>>   1. High level goal:
> >>>>>>>>>      Introduce an API that allows to create and handle an
> image
> >>>>>>>>> with
> >>>>>>>>> resolution variants.
> >>>>>>>>>
> >>>>>>>>>   2. What is not subject of the provided API
> >>>>>>>>>     - Scale naming convention for high-resolution images
> >>>>>>>>>     - Providing pixel scale factor for the screen/window
> >>>>>>>>>
> >>>>>>>>>   3. Use cases
> >>>>>>>>>    3.1 Loading and drawing high-resolution icons in IntelliJ
> IDEA
> >>>>>>>>>      A high-resolution image is loaded from resources and
> stored in
> >>>>>>>>> JBHiDPIScaledImage class  which is a subclass of the
> buffered image.
> >>>>>>>>>      The high-resolution image is used to create a disabled
> icon
> >>>>>>>>> in the
> >>>>>>>>> IconLoader.getDisabledIcon(icon) method.
> >>>>>>>>>
> https://github.com/JetBrains/intellij-community/blob/master/platform/util/src/com/intellij/openapi/util/IconLoader.java
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>    3.2 Loading and drawing high-resolution icons in
> NetBeans
> >>>>>>>>>      NetBeans does not have support for the high-resolution
> icons
> >>>>>>>>> loading.
> >>>>>>>>>      It loads an icon from the file system using
> >>>>>>>>> Toolkit.getDefaultToolkit().getImage(url) method or from
> resources
> >>>>>>>>>      by  ImageReader  and store it in ToolTipImage class
> which is
> >>>>>>>>> subclass of the buffered image.
> >>>>>>>>>      ImageUtilities.createDisabledIcon(icon) method creates
> a
> >>>>>>>>> disabled
> >>>>>>>>> icon by applying  RGBImageFilter to the icon.
> >>>>>>>>>
> http://hg.netbeans.org/main/file/97dcf49eb4a7/openide.util/src/org/openide/util/ImageUtilities.java
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>    3.3 Loading system icons in JDK 1.8
> >>>>>>>>>      JDK requests icons from the native system for system
> L&Fs and
> >>>>>>>>> applies filters for them.
> >>>>>>>>>      See for example AquaUtils.generateLightenedImage()
> method:
> >>>>>>>>>
> http://hg.openjdk.java.net/jdk9/client/jdk/file/e6f48c4fad38/src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>   4. HiDPI support for Images on different OSes
> >>>>>>>>>
> >>>>>>>>>     4.1 Mac OS X
> >>>>>>>>>       Cocoa API contains NSImage that allows to work with
> image
> >>>>>>>>> representations: add/remove/get all representations.
> >>>>>>>>>       It picks up an image with necessary resolution based
> on the
> >>>>>>>>> screen backing store pixel scale factor and applied
> transforms.
> >>>>>>>>>
> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSImage_Class/Reference/Reference.html
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>     4.2 Linux
> >>>>>>>>>       GTK+ 3 API has gtkcssimagescaled lib (it seems that it
> is not
> >>>>>>>>> public/stable)
> >>>>>>>>>       that parses the -gtk-scaled css property and draws a
> >>>>>>>>> GtkCssImage
> >>>>>>>>> according to the given scale factor.
> >>>>>>>>>
> >>>>>>>>>       I have not found information about the HiDPI support
> in Xlib.
> >>>>>>>>>
> >>>>>>>>>     4.3 Windows
> >>>>>>>>>       I have only found the tutorial that suggests to select
> and
> >>>>>>>>> draw a
> >>>>>>>>> bitmap using the queried DPI
> >>>>>>>>>       and scale the coordinates for drawing a rectangular
> frame
> >>>>>>>>>
> http://msdn.microsoft.com/en-us/library/dd464659%28v=vs.85%29.aspx
> >>>>>>>>>
> >>>>>>>>>       Windows also provides the horizontal and vertical DPI
> of the
> >>>>>>>>> desktop
> >>>>>>>>>
> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316
> >>>>>>>>>
> >>>>>>>>>   5. Pseudo API
> >>>>>>>>>      Below are some ways which illustrates how
> multi-resolution
> >>>>>>>>> images
> >>>>>>>>> can be created and used.
> >>>>>>>>>
> >>>>>>>>>     5.1 Resolution variants are stored directly in Image
> class.
> >>>>>>>>>     To query a resolution variant it needs to compare the
> >>>>>>>>> resolution
> >>>>>>>>> variant width/height
> >>>>>>>>>     with the requested high-resolution size.
> >>>>>>>>>     ------------
> >>>>>>>>>     public abstract class Image {
> >>>>>>>>>
> >>>>>>>>>         public void addResolutionVariant(Image image) {...}
> >>>>>>>>>         public List<Image> getResolutionVariants() {...}
> >>>>>>>>>     }
> >>>>>>>>>     ------------
> >>>>>>>>>     // create a disabled image with resolution variants
> >>>>>>>>>
> >>>>>>>>>     Image disabledImage = getDisabledImage(image);
> >>>>>>>>>
> >>>>>>>>>     for (Image rv : image.getResolutionVariants()) {
> >>>>>>>>> disabledImage.addResolutionVariant(getDisabledImage(rv));
> >>>>>>>>>     }
> >>>>>>>>>     ------------
> >>>>>>>>>     This approach requires that all resolution variants have
> been
> >>>>>>>>> created even not of them are really used.
> >>>>>>>>>
> >>>>>>>>>     5.2  Resolution variants are stored in a separate object
> that
> >>>>>>>>> allows to create them by demand.
> >>>>>>>>>     To query a resolution variant it needs to compare the
> >>>>>>>>> resolution
> >>>>>>>>> variant scale factor
> >>>>>>>>>     with the requested scale (that can include both screen
> DPI
> >>>>>>>>> scale
> >>>>>>>>> and applied transforms).
> >>>>>>>>>     ------------
> >>>>>>>>>     public abstract class Image {
> >>>>>>>>>
> >>>>>>>>>         public static interface ResolutionVariant {
> >>>>>>>>>             Image getImage();
> >>>>>>>>>             float getScaleFactor();
> >>>>>>>>>         }
> >>>>>>>>>
> >>>>>>>>>         public void addResolutionVariant(ResolutionVariant
> >>>>>>>>> resolutionVariant) {...}
> >>>>>>>>>         public List<ResolutionVariant>
> getResolutionVariants()
> >>>>>>>>> {...}
> >>>>>>>>>     }
> >>>>>>>>>     ------------
> >>>>>>>>>     // create a disabled image with resolution variants
> >>>>>>>>>     Image disabledImage = getDisabledImage(image);
> >>>>>>>>>
> >>>>>>>>>     for (Image.ResolutionVariant rv :
> >>>>>>>>> image.getResolutionVariants()) {
> >>>>>>>>>         disabledImage.addResolutionVariant(new
> >>>>>>>>> Image.ResolutionVariant() {
> >>>>>>>>>
> >>>>>>>>>             public Image getImage() {
> >>>>>>>>>                 return getDisabledImage(rv.getImage());
> >>>>>>>>>             }
> >>>>>>>>>
> >>>>>>>>>             public float getScaleFactor() {
> >>>>>>>>>                 return rv.getScaleFactor();
> >>>>>>>>>             }
> >>>>>>>>>         });
> >>>>>>>>>     }
> >>>>>>>>>     ------------
> >>>>>>>>>
> >>>>>>>>>     It does not have problem if a predefined set of images
> is
> >>>>>>>>> provided
> >>>>>>>>> (like image.png and image at 2x.png on the file system).
> >>>>>>>>>     This does not cover cases where a resolution variant can
> be
> >>>>>>>>> created
> >>>>>>>>> using the exact requested size (like loading icons from the
> native
> >>>>>>>>> system).
> >>>>>>>>>     A resolution variant can be queried based on a scale
> factor and
> >>>>>>>>> applied transforms.
> >>>>>>>>>
> >>>>>>>>>     5.3 The provided example allows to create a resolution
> variant
> >>>>>>>>> using the requested high-resolution image size.
> >>>>>>>>>     ------------
> >>>>>>>>>     public interface MultiResolutionImage {
> >>>>>>>>>         Image getResolutionVariant(float width, float
> height);
> >>>>>>>>>     }
> >>>>>>>>>     ------------
> >>>>>>>>>     // create a multi-resolution image
> >>>>>>>>>     Image mrImage = new AbstractMultiResolutionImage() {
> >>>>>>>>>
> >>>>>>>>>             public Image getResolutionVariant(float width,
> float
> >>>>>>>>> height) {
> >>>>>>>>>                 // create and return a resolution variant
> with
> >>>>>>>>> exact
> >>>>>>>>> requested width/height size
> >>>>>>>>>             }
> >>>>>>>>>
> >>>>>>>>>             protected Image getBaseImage() {
> >>>>>>>>>                 return baseImage;
> >>>>>>>>>             }
> >>>>>>>>>         };
> >>>>>>>>>     ------------
> >>>>>>>>>     // create a disabled image with resolution variants
> >>>>>>>>>     Image disabledImage = null;
> >>>>>>>>>     if (image instanceof MultiResolutionImage) {
> >>>>>>>>>         final MultiResolutionImage mrImage =
> (MultiResolutionImage)
> >>>>>>>>> image;
> >>>>>>>>>         disabledImage = new AbstractMultiResolutionImage(){
> >>>>>>>>>
> >>>>>>>>>             public Image getResolutionVariant(float width,
> float
> >>>>>>>>> height) {
> >>>>>>>>>                 return
> >>>>>>>>> getDisabledImage(mrImage.getResolutionVariant(width,
> height));
> >>>>>>>>>             }
> >>>>>>>>>
> >>>>>>>>>             protected Image getBaseImage() {
> >>>>>>>>>                 return getDisabledImage(mrImage);
> >>>>>>>>>             }
> >>>>>>>>>         };
> >>>>>>>>>     } else {
> >>>>>>>>>         disabledImage = getDisabledImage(image);
> >>>>>>>>>     }
> >>>>>>>>>     ------------
> >>>>>>>>>
> >>>>>>>>>   Thanks,
> >>>>>>>>>   Alexandr.
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >


From james.graham at oracle.com  Fri May  5 20:50:00 2017
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 5 May 2017 13:50:00 -0700
Subject: [OpenJDK 2D-Dev] [10] Marlin2D upgrade 0.7.5
In-Reply-To: <CAKjRUT4mgD9eMeT5jhf_GFvnwpvLiAQk2kj-68W2VMEgV6-a4Q@mail.gmail.com>
References: <CAKjRUT4xU933gxKnMpNoqmp53ZMWm5T7KuhsVZzfysNEkDB3ow@mail.gmail.com>
 <6b7ddf24-62b7-d490-7b3b-54b8ab2ea70a@oracle.com>
 <CAKjRUT4mgD9eMeT5jhf_GFvnwpvLiAQk2kj-68W2VMEgV6-a4Q@mail.gmail.com>
Message-ID: <2a3ebeab-af95-3b4d-4711-6fae81bae5ac@oracle.com>

Hi Laurent,

A couple of comments that might just be points for clarification.  Minimally it would make sense to include the JBS 
report number on the third item below, but the rest are just notes and suggestions...

On 4/26/17 2:32 PM, Laurent Bourg?s wrote:
>     - MarlinProperties - TileSize vs TileWidth.  Is there a reason you haven't created a TileHeight property?  I could
>     see a couple of ways of going here:
>        - TileSize means height and TileWidth is new which is just odd naming
>          In this case, I'd make the default for TileWidth be the value for TileSize
>          otherwise setting tilesize used to set both W&H, but now it only sets H?
>        - TileSize is legacy and new values are TileWidth and TileHeight
>          Both default to TileSize if not specified
>     In either case, I would think that TileWidth should default to TileSize?
>
>
>     Fixed, I adopted the first solution and getTileWidth_Log2() uses getTileSize_Log2() to get the default value (W=H)

I was leaning towards adding W & H and having Size be the old mechanism - for symmetry - but this is fine.

>     - MarlinTileGenerator,MarlinRenderer - all of the methods called on rdrF and rdrD have the same signature.  Why not
>     have MarlinRenderer include those methods and then you just need to store a single MarlinRenderer field and be able
>     to manipulate either type...?
>
>
>     I agree. I tried but benchamrks proved that interface calls method were slower than monomorphic calls so I adopted
> this bimorphic call optimization where only 1 type is really used at runtime.

I'm curious how much difference this made to require this amount of complexity, but there is a solution here if you are 
really worried about performance - use a super-class instead of an interface.  If you can measure overhead for invoking 
an abstract method then there is something wrong with the VM.

>     - Renderer, line 85,114 - maybe add a line saying that is the result of <name> test?  Did we put that test into the
>     repo anywhere?
>
>
>     Added comment: 'TestNonAARasterization: cubics/quads' (not in repo, only in JBS)

I'd add the JBS number "JDK_NNNNNNNN" as well then.

				...jim


From james.graham at oracle.com  Fri May  5 20:52:02 2017
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 5 May 2017 13:52:02 -0700
Subject: [OpenJDK 2D-Dev] CFV: New2d group member : Laurent Bourges
In-Reply-To: <7222caf8-339b-923c-c837-a36c87d8c576@oracle.com>
References: <7222caf8-339b-923c-c837-a36c87d8c576@oracle.com>
Message-ID: <0fc33912-4665-0a6b-7855-293a5c323166@oracle.com>

Vote: yes

			...jim

On 5/5/17 12:54 PM, Phil Race wrote:
> I hereby nominate Laurent Bourges to membership in the 2D group.



From alexey.menkov at oracle.com  Fri May  5 21:21:33 2017
From: alexey.menkov at oracle.com (Alex Menkov)
Date: Fri, 5 May 2017 14:21:33 -0700
Subject: [OpenJDK 2D-Dev] <Sound Dev> [9] Review Request: 8179596 Update
 java.desktop to be HTML-5 friendly
In-Reply-To: <e2e40bf4-9f2f-46f2-86a8-1ceca25e23e6@default>
References: <e2e40bf4-9f2f-46f2-86a8-1ceca25e23e6@default>
Message-ID: <33a88ff4-de38-90ff-576e-d073ec360ab7@oracle.com>

Okay,

Then +1 to Phil's approval

--alex

On 05/05/2017 12:37, Sergey Bylokhov wrote:
> Hi, Alexey.
> Yes it is possible to add </p> to this changes, but actually </p> tag is not used in JavaSound docs. The last one were removed a few years ago. The <p> tag is used in assumption that it affect the text till the next <p> or till the end of the doc.
> So for example in the MidiMessage.java/SizeSequence.java there are a few <p> tags which affects the text till the next <p>, and in this fix just one more <p> was added in the middle.
>
> ----- alexey.menkov at oracle.com wrote:
>
>> Overall looks good.
>> One minor point - there are several places when you replace <center>
>> with <p> without end </p>.
>> Usually absent </p> doesn't cause any problem, but it would be better
>> to
>> have end tags for all elements.
>>
>> I see this in
>> src/java.desktop/share/classes/javax/sound/midi/MidiMessage.java
>> src/java.desktop/share/classes/javax/sound/sampled/FloatControl.java
>> src/java.desktop/share/classes/javax/sound/sampled/TargetDataLine.java
>> src/java.desktop/share/classes/javax/swing/SizeSequence.java
>>
>> --alex
>>
>> On 05/04/2017 18:15, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk9-dev.
>>> This fix is a part of the effort to make all javadoc in jdk9 be
>> compatible to HTML5.
>>>
>>> In the fix the most common issues are fixed.
>>> The issues related to tables will be fixed later, because it is
>> depends from the new html styles which are under review[1].
>>>
>>> After the fix the number of errors reported during the build in
>> java.desktop module decreased from 300+ to 110.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179596
>>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/8179596/webrev.00
>>> Specdiff: http://cr.openjdk.java.net/~serb/8179596/specdiff.00
>>>
>>> [1]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047433.html
>>>


From jonathan.gibbons at oracle.com  Fri May  5 22:22:43 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 05 May 2017 15:22:43 -0700
Subject: [OpenJDK 2D-Dev] <Sound Dev> [9] Review Request: 8179596 Update
 java.desktop to be HTML-5 friendly
In-Reply-To: <e2e40bf4-9f2f-46f2-86a8-1ceca25e23e6@default>
References: <e2e40bf4-9f2f-46f2-86a8-1ceca25e23e6@default>
Message-ID: <590CFB33.7010106@oracle.com>

Sergey,

This is not a comment on the content of the review; it is a minor 
comment on your interpretation of <p>.

<p> is a block-level tag that is implicitly terminated by any of many 
block-level tags. For the full list, see the W3C definition of the p 
element in HTML 5:
https://www.w3.org/TR/html5/grouping-content.html#the-p-element

> Tag omission in text/html 
> <https://www.w3.org/TR/html5/dom.html#element-dfn-tag-omission>:
>
>     A |p
>     <https://www.w3.org/TR/html5/grouping-content.html#the-p-element>|
>     element's end tag
>     <https://www.w3.org/TR/html5/syntax.html#syntax-end-tag> may be
>     omitted if the |p
>     <https://www.w3.org/TR/html5/grouping-content.html#the-p-element>|
>     element is immediately followed by an |address
>     <https://www.w3.org/TR/html5/sections.html#the-address-element>|,
>     |article
>     <https://www.w3.org/TR/html5/sections.html#the-article-element>|,
>     |aside
>     <https://www.w3.org/TR/html5/sections.html#the-aside-element>|,
>     |blockquote
>     <https://www.w3.org/TR/html5/grouping-content.html#the-blockquote-element>|,
>     |div
>     <https://www.w3.org/TR/html5/grouping-content.html#the-div-element>|,
>     |dl
>     <https://www.w3.org/TR/html5/grouping-content.html#the-dl-element>|,
>     |fieldset
>     <https://www.w3.org/TR/html5/forms.html#the-fieldset-element>|,
>     |footer
>     <https://www.w3.org/TR/html5/sections.html#the-footer-element>|,
>     |form <https://www.w3.org/TR/html5/forms.html#the-form-element>|,
>     |h1
>     <https://www.w3.org/TR/html5/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements>|,
>     |h2
>     <https://www.w3.org/TR/html5/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements>|,
>     |h3
>     <https://www.w3.org/TR/html5/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements>|,
>     |h4
>     <https://www.w3.org/TR/html5/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements>|,
>     |h5
>     <https://www.w3.org/TR/html5/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements>|,
>     |h6
>     <https://www.w3.org/TR/html5/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements>|,
>     |header
>     <https://www.w3.org/TR/html5/sections.html#the-header-element>|,
>     |hgroup <https://www.w3.org/TR/html5/obsolete.html#hgroup>|, |hr
>     <https://www.w3.org/TR/html5/grouping-content.html#the-hr-element>|,
>     |main
>     <https://www.w3.org/TR/html5/grouping-content.html#the-main-element>|,
>     |nav <https://www.w3.org/TR/html5/sections.html#the-nav-element>|,
>     |ol
>     <https://www.w3.org/TR/html5/grouping-content.html#the-ol-element>|,
>     |p
>     <https://www.w3.org/TR/html5/grouping-content.html#the-p-element>|, |pre
>     <https://www.w3.org/TR/html5/grouping-content.html#the-pre-element>|,
>     |section
>     <https://www.w3.org/TR/html5/sections.html#the-section-element>|,
>     |table
>     <https://www.w3.org/TR/html5/tabular-data.html#the-table-element>|, or
>     |ul
>     <https://www.w3.org/TR/html5/grouping-content.html#the-ul-element>|,
>     element, or if there is no more content in the parent element and
>     the parent element is not an |a
>     <https://www.w3.org/TR/html5/text-level-semantics.html#the-a-element>|
>     element.
>


-- Jon

On 05/05/2017 12:37 PM, Sergey Bylokhov wrote:
> Hi, Alexey.
> Yes it is possible to add </p> to this changes, but actually </p> tag is not used in JavaSound docs. The last one were removed a few years ago. The <p> tag is used in assumption that it affect the text till the next <p> or till the end of the doc.
> So for example in the MidiMessage.java/SizeSequence.java there are a few <p> tags which affects the text till the next <p>, and in this fix just one more <p> was added in the middle.
>
> ----- alexey.menkov at oracle.com wrote:
>
>> Overall looks good.
>> One minor point - there are several places when you replace <center>
>> with <p> without end </p>.
>> Usually absent </p> doesn't cause any problem, but it would be better
>> to
>> have end tags for all elements.
>>
>> I see this in
>> src/java.desktop/share/classes/javax/sound/midi/MidiMessage.java
>> src/java.desktop/share/classes/javax/sound/sampled/FloatControl.java
>> src/java.desktop/share/classes/javax/sound/sampled/TargetDataLine.java
>> src/java.desktop/share/classes/javax/swing/SizeSequence.java
>>
>> --alex
>>
>> On 05/04/2017 18:15, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk9-dev.
>>> This fix is a part of the effort to make all javadoc in jdk9 be
>> compatible to HTML5.
>>> In the fix the most common issues are fixed.
>>> The issues related to tables will be fixed later, because it is
>> depends from the new html styles which are under review[1].
>>> After the fix the number of errors reported during the build in
>> java.desktop module decreased from 300+ to 110.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179596
>>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/8179596/webrev.00
>>> Specdiff: http://cr.openjdk.java.net/~serb/8179596/specdiff.00
>>>
>>> [1]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047433.html

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

From bourges.laurent at gmail.com  Tue May  9 10:06:44 2017
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 9 May 2017 12:06:44 +0200
Subject: [OpenJDK 2D-Dev] [10] Marlin2D upgrade 0.7.5
In-Reply-To: <2a3ebeab-af95-3b4d-4711-6fae81bae5ac@oracle.com>
References: <CAKjRUT4xU933gxKnMpNoqmp53ZMWm5T7KuhsVZzfysNEkDB3ow@mail.gmail.com>
 <6b7ddf24-62b7-d490-7b3b-54b8ab2ea70a@oracle.com>
 <CAKjRUT4mgD9eMeT5jhf_GFvnwpvLiAQk2kj-68W2VMEgV6-a4Q@mail.gmail.com>
 <2a3ebeab-af95-3b4d-4711-6fae81bae5ac@oracle.com>
Message-ID: <CAKjRUT5o0iD-M4hcewkkLw3u=h=9ZxMD0wHHWXFKOnA2HgbPzg@mail.gmail.com>

Jim,

Here is the updated webrev:
http://cr.openjdk.java.net/~lbourges/marlin/Marlin-075.2/

Changes:
- Added 'TestNonAARasterization (JDK-8170879)' in (D)Stroker classes
- Fixed two comments related to half-open intervals in (D)Renderer classes
- Fixed copyright year to 2017
- Double-precision Marlin2D enabled by default in RenderingEngine:

-            final String marlinREClass = "sun.java2d.marlin.MarlinRende
ringEngine";
+            final String marlinREClass = "sun.java2d.marlin.DMarlinRend
eringEngine";


My comments below:


> On 4/26/17 2:32 PM, Laurent Bourg?s wrote:
>
>>     - MarlinProperties - TileSize vs TileWidth.  Is there a reason you
>> haven't created a TileHeight property?  I could
>>     see a couple of ways of going here:
>>        - TileSize means height and TileWidth is new which is just odd
>> naming
>>          In this case, I'd make the default for TileWidth be the value
>> for TileSize
>>          otherwise setting tilesize used to set both W&H, but now it only
>> sets H?
>>        - TileSize is legacy and new values are TileWidth and TileHeight
>>          Both default to TileSize if not specified
>>     In either case, I would think that TileWidth should default to
>> TileSize?
>>
>>
>>     Fixed, I adopted the first solution and getTileWidth_Log2() uses
>> getTileSize_Log2() to get the default value (W=H)
>>
>
> I was leaning towards adding W & H and having Size be the old mechanism -
> for symmetry - but this is fine.
>

Agreed but we could add that later when we will increase the tile width &
height (asymmetric) for performance. Few adjustments remain in java2d
pipeline classes.


>
>     - MarlinTileGenerator,MarlinRenderer - all of the methods called on
>> rdrF and rdrD have the same signature.  Why not
>>     have MarlinRenderer include those methods and then you just need to
>> store a single MarlinRenderer field and be able
>>     to manipulate either type...?
>>
>>
>>     I agree. I tried but benchamrks proved that interface calls method
>> were slower than monomorphic calls so I adopted
>> this bimorphic call optimization where only 1 type is really used at
>> runtime.
>>
>
> I'm curious how much difference this made to require this amount of
> complexity, but there is a solution here if you are really worried about
> performance - use a super-class instead of an interface.  If you can
> measure overhead for invoking an abstract method then there is something
> wrong with the VM.
>

I tested this issue a lot in december and this 'bimorphic' optimization is
concluding. I agree having an abstract class would be good but extracting
common parts between Renderer & DRenderer is not easy and it may be more
difficult to maintain.


>
>     - Renderer, line 85,114 - maybe add a line saying that is the result
>> of <name> test?  Did we put that test into the
>>     repo anywhere?
>>
>>
>>     Added comment: 'TestNonAARasterization: cubics/quads' (not in repo,
>> only in JBS)
>>
>
> I'd add the JBS number "JDK_NNNNNNNN" as well then.
>

Fixed.

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170509/3fdafb46/attachment-0001.html>

From james.graham at oracle.com  Tue May  9 20:51:42 2017
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 9 May 2017 13:51:42 -0700
Subject: [OpenJDK 2D-Dev] [10] Marlin2D upgrade 0.7.5
In-Reply-To: <CAKjRUT5o0iD-M4hcewkkLw3u=h=9ZxMD0wHHWXFKOnA2HgbPzg@mail.gmail.com>
References: <CAKjRUT4xU933gxKnMpNoqmp53ZMWm5T7KuhsVZzfysNEkDB3ow@mail.gmail.com>
 <6b7ddf24-62b7-d490-7b3b-54b8ab2ea70a@oracle.com>
 <CAKjRUT4mgD9eMeT5jhf_GFvnwpvLiAQk2kj-68W2VMEgV6-a4Q@mail.gmail.com>
 <2a3ebeab-af95-3b4d-4711-6fae81bae5ac@oracle.com>
 <CAKjRUT5o0iD-M4hcewkkLw3u=h=9ZxMD0wHHWXFKOnA2HgbPzg@mail.gmail.com>
Message-ID: <eef72fef-dd18-a16e-8716-9f5eacd9b710@oracle.com>

This looks fine, but I've reached out to Phil with a question about changing the default and whether we need to file a 
request for that.

Is there a JBS bug for this yet?

				...jim

On 5/9/17 3:06 AM, Laurent Bourg?s wrote:
> Jim,
>
> Here is the updated webrev:
> http://cr.openjdk.java.net/~lbourges/marlin/Marlin-075.2/
>
> Changes:
> - Added 'TestNonAARasterization (JDK-8170879)' in (D)Stroker classes
> - Fixed two comments related to half-open intervals in (D)Renderer classes
> - Fixed copyright year to 2017
> - Double-precision Marlin2D enabled by default in RenderingEngine:
>
> -            final String marlinREClass = "sun.java2d.marlin.MarlinRenderingEngine";
> +            final String marlinREClass = "sun.java2d.marlin.DMarlinRenderingEngine";
>
>
> My comments below:
>
>
>     On 4/26/17 2:32 PM, Laurent Bourg?s wrote:
>
>             - MarlinProperties - TileSize vs TileWidth.  Is there a reason you haven't created a TileHeight property?  I
>         could
>             see a couple of ways of going here:
>                - TileSize means height and TileWidth is new which is just odd naming
>                  In this case, I'd make the default for TileWidth be the value for TileSize
>                  otherwise setting tilesize used to set both W&H, but now it only sets H?
>                - TileSize is legacy and new values are TileWidth and TileHeight
>                  Both default to TileSize if not specified
>             In either case, I would think that TileWidth should default to TileSize?
>
>
>             Fixed, I adopted the first solution and getTileWidth_Log2() uses getTileSize_Log2() to get the default value
>         (W=H)
>
>
>     I was leaning towards adding W & H and having Size be the old mechanism - for symmetry - but this is fine.
>
>
> Agreed but we could add that later when we will increase the tile width & height (asymmetric) for performance. Few
> adjustments remain in java2d pipeline classes.
>
>
>
>             - MarlinTileGenerator,MarlinRenderer - all of the methods called on rdrF and rdrD have the same signature.
>         Why not
>             have MarlinRenderer include those methods and then you just need to store a single MarlinRenderer field and
>         be able
>             to manipulate either type...?
>
>
>             I agree. I tried but benchamrks proved that interface calls method were slower than monomorphic calls so I
>         adopted
>         this bimorphic call optimization where only 1 type is really used at runtime.
>
>
>     I'm curious how much difference this made to require this amount of complexity, but there is a solution here if you
>     are really worried about performance - use a super-class instead of an interface.  If you can measure overhead for
>     invoking an abstract method then there is something wrong with the VM.
>
>
> I tested this issue a lot in december and this 'bimorphic' optimization is concluding. I agree having an abstract class
> would be good but extracting common parts between Renderer & DRenderer is not easy and it may be more difficult to
> maintain.
>
>
>
>             - Renderer, line 85,114 - maybe add a line saying that is the result of <name> test?  Did we put that test
>         into the
>             repo anywhere?
>
>
>             Added comment: 'TestNonAARasterization: cubics/quads' (not in repo, only in JBS)
>
>
>     I'd add the JBS number "JDK_NNNNNNNN" as well then.
>
>
> Fixed.
>
> Cheers,
> Laurent

From bourges.laurent at gmail.com  Wed May 10 08:23:52 2017
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 10 May 2017 10:23:52 +0200
Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8180055: Upgrade the Marlin renderer
	in Java2D
Message-ID: <CAKjRUT54OikUMiPNxko7OCNaC4q5hO8ifSLbx4AVf4s1ejjDDQ@mail.gmail.com>

Hi,

Please review this Marlin2D upgrade:
Latest webrev: http://cr.openjdk.java.net/~lbourges/marlin/Marlin-075.2/
JBS: https://bugs.openjdk.java.net/browse/JDK-8180055

Previous discussion thread below:
http://mail.openjdk.java.net/pipermail/2d-dev/2017-April/008312.html
http://mail.openjdk.java.net/pipermail/2d-dev/2017-May/008324.html

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

From bourges.laurent at gmail.com  Thu May 11 07:32:18 2017
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 11 May 2017 09:32:18 +0200
Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8180055: Upgrade the Marlin
	renderer in Java2D
In-Reply-To: <CAKjRUT54OikUMiPNxko7OCNaC4q5hO8ifSLbx4AVf4s1ejjDDQ@mail.gmail.com>
References: <CAKjRUT54OikUMiPNxko7OCNaC4q5hO8ifSLbx4AVf4s1ejjDDQ@mail.gmail.com>
Message-ID: <CAKjRUT4S0KmRBNn1MhfdTV8rfygahChD+L-v_SogEjD+_+haqw@mail.gmail.com>

Hi,

One more reviewer, please ?
Jim already approved that big patch.

PS: Will synchronize again with MarlinFX and provide an updated patch for
OpenJFX 10

Lauren

Le 10 mai 2017 10:23 AM, "Laurent Bourg?s" <bourges.laurent at gmail.com> a
?crit :

> Hi,
>
> Please review this Marlin2D upgrade:
> Latest webrev: http://cr.openjdk.java.net/~lbourges/marlin/Marlin-075.2/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8180055
>
> Previous discussion thread below:
> http://mail.openjdk.java.net/pipermail/2d-dev/2017-April/008312.html
> http://mail.openjdk.java.net/pipermail/2d-dev/2017-May/008324.html
>
> Regards,
> Laurent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170511/717035e8/attachment.html>

From prahalad.kumar.narayanan at oracle.com  Thu May 11 09:46:22 2017
From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan)
Date: Thu, 11 May 2017 02:46:22 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8180055: Upgrade the Marlin
 renderer in Java2D
In-Reply-To: <CAKjRUT4S0KmRBNn1MhfdTV8rfygahChD+L-v_SogEjD+_+haqw@mail.gmail.com>
References: <CAKjRUT54OikUMiPNxko7OCNaC4q5hO8ifSLbx4AVf4s1ejjDDQ@mail.gmail.com>
 <CAKjRUT4S0KmRBNn1MhfdTV8rfygahChD+L-v_SogEjD+_+haqw@mail.gmail.com>
Message-ID: <27800b37-8369-4e3b-894f-aa1e1fb99873@default>

Hello Lauren

+1 for the code changes. 

Without going through the specifics, I imported the code & checked for successful build.
The build succeeded with the patch from your latest webrev link. 

Just for knowledge: You would have checked for the performance improvement with your improved Marlin renderer.
Can you share your insights and any specific use-cases that have benefited ?

Thank you
Have a good day

Prahalad N.

----

From: Laurent Bourg?s [mailto:bourges.laurent at gmail.com] 
Sent: Thursday, May 11, 2017 1:02 PM
To: Phil Race; Jim Graham; 2d-dev at openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8180055: Upgrade the Marlin renderer in Java2D

Hi,

One more reviewer, please ??
Jim already approved that big patch.

PS: Will synchronize again with MarlinFX and provide an updated patch for OpenJFX 10

Lauren

Le?10 mai 2017 10:23 AM, "Laurent Bourg?s" <bourges.laurent at gmail.com> a ?crit?:
Hi,
Please review this Marlin2D upgrade:
Latest webrev: http://cr.openjdk.java.net/~lbourges/marlin/Marlin-075.2/ 
JBS: https://bugs.openjdk.java.net/browse/JDK-8180055


Previous discussion thread below:
http://mail.openjdk.java.net/pipermail/2d-dev/2017-April/008312.html
http://mail.openjdk.java.net/pipermail/2d-dev/2017-May/008324.html

Regards,
Laurent

From bourges.laurent at gmail.com  Thu May 11 12:10:19 2017
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 11 May 2017 14:10:19 +0200
Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8180055: Upgrade the Marlin
 renderer in Java2D
In-Reply-To: <27800b37-8369-4e3b-894f-aa1e1fb99873@default>
References: <CAKjRUT54OikUMiPNxko7OCNaC4q5hO8ifSLbx4AVf4s1ejjDDQ@mail.gmail.com>
 <CAKjRUT4S0KmRBNn1MhfdTV8rfygahChD+L-v_SogEjD+_+haqw@mail.gmail.com>
 <27800b37-8369-4e3b-894f-aa1e1fb99873@default>
Message-ID: <CAKjRUT7CAd37-o5ZsY=kXoc4JmA=-VjoY+omAzD5ph09A5Gx3Q@mail.gmail.com>

Hi Prahalad,

2017-05-11 11:46 GMT+02:00 Prahalad Kumar Narayanan <
prahalad.kumar.narayanan at oracle.com>:

> Hello Lauren
>
> +1 for the code changes.
>
> Without going through the specifics, I imported the code & checked for
> successful build.
> The build succeeded with the patch from your latest webrev link.
>

Thanks for the review.


> Just for knowledge: You would have checked for the performance improvement
> with your improved Marlin renderer.
> Can you share your insights and any specific use-cases that have benefited
> ?
>

Could you be more precise ? Do you mean the performance improvements
between Marlin 0.7.5 and 0.7.4 ?
or in general by the Marlin renderer vs Pisces ...

In Marlin 0.7.5, I modified several aspects:
- double-precision (double) vs single-precision (float): ~ equivalent
performance
- tile fills optimization: it benefits to large shapes (almost empty /
full) like large circles or disks: up to 10% faster for large shapes
measured with my MapBench tool (ellipse-fill commands from radius = 1 to
1000)
- higher precision for curve / quad approximation: it impacts performance
as more segments are generated, sorted and rasterized ~ 10% globally in my
MapBench runs.

I could provide some results if you want.

Finally I am going to work again on Java2D pipeline optimizations: avoid
Path2D iterators, TexturePaint / CompositePaint (array / raster cache +
loops)...

PS: I still plan one day to implement another approach to compute pixel
coverage (exact) like agg / libart that could improve both quality and
performance a bit (1 single scanline with more maths) but no more 8
scanlines.

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

From prahalad.kumar.narayanan at oracle.com  Fri May 12 03:14:33 2017
From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan)
Date: Thu, 11 May 2017 20:14:33 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8180055: Upgrade the Marlin
 renderer in Java2D
In-Reply-To: <CAKjRUT7CAd37-o5ZsY=kXoc4JmA=-VjoY+omAzD5ph09A5Gx3Q@mail.gmail.com>
References: <CAKjRUT54OikUMiPNxko7OCNaC4q5hO8ifSLbx4AVf4s1ejjDDQ@mail.gmail.com>
 <CAKjRUT4S0KmRBNn1MhfdTV8rfygahChD+L-v_SogEjD+_+haqw@mail.gmail.com>
 <27800b37-8369-4e3b-894f-aa1e1fb99873@default>
 <CAKjRUT7CAd37-o5ZsY=kXoc4JmA=-VjoY+omAzD5ph09A5Gx3Q@mail.gmail.com>
Message-ID: <5b5585db-5017-43c5-a4b4-0d90271633b0@default>

Hello Laurent

?

Yes.. I wished to know the performance improvements between the versions of Marlin Renderer 0.7.5 and 0.7.4.

Thanks for the explanation. It helps.

?

Thank you

Have a good day

?

Prahalad N.

?

From: Laurent Bourg?s [mailto:bourges.laurent at gmail.com] 
Sent: Thursday, May 11, 2017 5:40 PM
To: Prahalad Kumar Narayanan
Cc: Philip Race; Jim Graham; 2d-dev at openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8180055: Upgrade the Marlin renderer in Java2D

?

Hi Prahalad,

2017-05-11 11:46 GMT+02:00 Prahalad Kumar Narayanan <HYPERLINK "mailto:prahalad.kumar.narayanan at oracle.com"prahalad.kumar.narayanan at oracle.com>:

Hello Lauren

+1 for the code changes.

Without going through the specifics, I imported the code & checked for successful build.
The build succeeded with the patch from your latest webrev link.


Thanks for the review.


Just for knowledge: You would have checked for the performance improvement with your improved Marlin renderer.
Can you share your insights and any specific use-cases that have benefited ?

?

Could you be more precise ? Do you mean the performance improvements between Marlin 0.7.5 and 0.7.4 ? 
or in general by the Marlin renderer vs Pisces ...

In Marlin 0.7.5, I modified several aspects:

- double-precision (double) vs single-precision (float): ~ equivalent performance

- tile fills optimization: it benefits to large shapes (almost empty / full) like large circles or disks: up to 10% faster for large shapes measured with my MapBench tool (ellipse-fill commands from radius = 1 to 1000)

- higher precision for curve / quad approximation: it impacts performance as more segments are generated, sorted and rasterized ~ 10% globally in my MapBench runs.

I could provide some results if you want.

?

Finally I am going to work again on Java2D pipeline optimizations: avoid Path2D iterators, TexturePaint / CompositePaint (array / raster cache + loops)...

?

PS: I still plan one day to implement another approach to compute pixel coverage (exact) like agg / libart that could improve both quality and performance a bit (1 single scanline with more maths) but no more 8 scanlines.

?

Regards,

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170511/7f37ff84/attachment-0001.html>

From philip.race at oracle.com  Fri May 12 23:36:39 2017
From: philip.race at oracle.com (Philip Race)
Date: Fri, 12 May 2017 16:36:39 -0700
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review Request: 8180326 Update
 the tables in java.desktop to be HTML-5 friendly
In-Reply-To: <d542b7bf-08e9-44ea-befb-329956eab69a@default>
References: <d542b7bf-08e9-44ea-befb-329956eab69a@default>
Message-ID: <59164707.7040605@oracle.com>

Adding 2d-dev because a number of the files are 2D.

What is the general reason for changing the appearance of the tables?

-phil.

On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
> Hello,
> Please review the fix for jdk9-dev.
>
> This fix is a part of the effort to make all javadoc in jdk9 be compatible to HTML5.
> It covers all errors which are reported by the javadoc tool during the build of jdk for java.desktop module.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8180326/webrev.01
>
> Note that an appearance of some tables were changed after the fix:
>
> Before: http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
> After: http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html
>
> Before: http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html
> After : http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html
>
> Before: http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html
> After: http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html

From sergey.bylokhov at oracle.com  Fri May 12 23:52:06 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 12 May 2017 16:52:06 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review Request: 8180326 Update
 the tables in java.desktop to be HTML-5 friendly
Message-ID: <f42480bd-df84-48d4-a062-da030d9a4fb7@default>

This is because I use the same style for most of the tables 'class="striped"', which apply the same/unified style for all(most) of our tables.
Also this is because I removed 'inlined' styles, like here:
http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html

----- philip.race at oracle.com wrote:

> Adding 2d-dev because a number of the files are 2D.
> 
> What is the general reason for changing the appearance of the tables?
> 
> -phil.
> 
> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
> > Hello,
> > Please review the fix for jdk9-dev.
> >
> > This fix is a part of the effort to make all javadoc in jdk9 be
> compatible to HTML5.
> > It covers all errors which are reported by the javadoc tool during
> the build of jdk for java.desktop module.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
> > Webrev can be found at:
> http://cr.openjdk.java.net/~serb/8180326/webrev.01
> >
> > Note that an appearance of some tables were changed after the fix:
> >
> > Before:
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
> > After:
> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html
> >
> > Before:
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html
> > After :
> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html
> >
> > Before:
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html
> > After:
> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html

From philip.race at oracle.com  Fri May 12 23:54:09 2017
From: philip.race at oracle.com (Philip Race)
Date: Fri, 12 May 2017 16:54:09 -0700
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review Request: 8180326 Update
 the tables in java.desktop to be HTML-5 friendly
In-Reply-To: <f42480bd-df84-48d4-a062-da030d9a4fb7@default>
References: <f42480bd-df84-48d4-a062-da030d9a4fb7@default>
Message-ID: <59164B21.3050803@oracle.com>

Does this in any way match the rest of the docs ? Or is everyone left to 
style things how they want.
I thought (?) maybe there is to be some javadoc tool support for CSS styles.

Also why are all the table summaries removed ?

-phil.

On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
> This is because I use the same style for most of the tables 'class="striped"', which apply the same/unified style for all(most) of our tables.
> Also this is because I removed 'inlined' styles, like here:
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
>
> ----- philip.race at oracle.com wrote:
>
>> Adding 2d-dev because a number of the files are 2D.
>>
>> What is the general reason for changing the appearance of the tables?
>>
>> -phil.
>>
>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk9-dev.
>>>
>>> This fix is a part of the effort to make all javadoc in jdk9 be
>> compatible to HTML5.
>>> It covers all errors which are reported by the javadoc tool during
>> the build of jdk for java.desktop module.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>> Note that an appearance of some tables were changed after the fix:
>>>
>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
>>> After:
>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html
>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html
>>> After :
>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html
>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html
>>> After:
>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html

From sergey.bylokhov at oracle.com  Sat May 13 00:00:30 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 12 May 2017 17:00:30 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review Request: 8180326 Update
 the tables in java.desktop to be HTML-5 friendly
Message-ID: <cc06639b-5267-4b26-a487-e05aaf40879c@default>

The "summary" is unsupported by the HTML5 and we replace it by invisible caption.
These new styles are located in the stylesheet.css in the root of the JavaDoc api folder, so I assume these styles should be used by others as well.
They were added by this fix:
https://bugs.openjdk.java.net/browse/JDK-8179479

----- philip.race at oracle.com wrote:

> Does this in any way match the rest of the docs ? Or is everyone left
> to 
> style things how they want.
> I thought (?) maybe there is to be some javadoc tool support for CSS
> styles.
> 
> Also why are all the table summaries removed ?
> 
> -phil.
> 
> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
> > This is because I use the same style for most of the tables
> 'class="striped"', which apply the same/unified style for all(most) of
> our tables.
> > Also this is because I removed 'inlined' styles, like here:
> >
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
> >
> > ----- philip.race at oracle.com wrote:
> >
> >> Adding 2d-dev because a number of the files are 2D.
> >>
> >> What is the general reason for changing the appearance of the
> tables?
> >>
> >> -phil.
> >>
> >> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
> >>> Hello,
> >>> Please review the fix for jdk9-dev.
> >>>
> >>> This fix is a part of the effort to make all javadoc in jdk9 be
> >> compatible to HTML5.
> >>> It covers all errors which are reported by the javadoc tool
> during
> >> the build of jdk for java.desktop module.
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
> >>> Webrev can be found at:
> >> http://cr.openjdk.java.net/~serb/8180326/webrev.01
> >>> Note that an appearance of some tables were changed after the
> fix:
> >>>
> >>> Before:
> >>
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
> >>> After:
> >>
> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html
> >>> Before:
> >>
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html
> >>> After :
> >>
> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html
> >>> Before:
> >>
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html
> >>> After:
> >>
> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html

From philip.race at oracle.com  Sat May 13 00:03:38 2017
From: philip.race at oracle.com (Philip Race)
Date: Fri, 12 May 2017 17:03:38 -0700
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review Request: 8180326 Update
 the tables in java.desktop to be HTML-5 friendly
In-Reply-To: <59164C3F.8070606@oracle.com>
References: <f42480bd-df84-48d4-a062-da030d9a4fb7@default>
 <59164B21.3050803@oracle.com> <59164C3F.8070606@oracle.com>
Message-ID: <59164D5A.60200@oracle.com>



On 5/12/17, 4:58 PM, Jonathan Gibbons wrote:
> Phil,
>
> 1. javadoc now provides support for 3 named styles in the default 
> stylesheet:
>         borderless:  no borders
>         plain:  simple 1px borders around tables and cells
>         striped: reduced borders; rows have alternating white and 
> light grey backgrounds
>
OK .. I see these being used.
>
> 2. summary attributes are not legal in HTML 5.
>     For accessibility reasons, you should consider having a table 
> caption instead.

OK. I saw these but I wasn't clear it was a direct replacement. HTML 5 
sometimes
seems to be different just to be different ..

-phil.
>
> -- Jon
>
>
> On 05/12/2017 04:54 PM, Philip Race wrote:
>> Does this in any way match the rest of the docs ? Or is everyone left 
>> to style things how they want.
>> I thought (?) maybe there is to be some javadoc tool support for CSS 
>> styles.
>>
>> Also why are all the table summaries removed ?
>>
>> -phil.
>>
>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>> This is because I use the same style for most of the tables 
>>> 'class="striped"', which apply the same/unified style for all(most) 
>>> of our tables.
>>> Also this is because I removed 'inlined' styles, like here:
>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>
>>>
>>> ----- philip.race at oracle.com wrote:
>>>
>>>> Adding 2d-dev because a number of the files are 2D.
>>>>
>>>> What is the general reason for changing the appearance of the tables?
>>>>
>>>> -phil.
>>>>
>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk9-dev.
>>>>>
>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>> compatible to HTML5.
>>>>> It covers all errors which are reported by the javadoc tool during
>>>> the build of jdk for java.desktop module.
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>> Webrev can be found at:
>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>> Note that an appearance of some tables were changed after the fix:
>>>>>
>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>
>>>>> After:
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>>
>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>>
>>>>> After :
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>>
>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>>
>>>>> After:
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>>
>

From jonathan.gibbons at oracle.com  Fri May 12 23:58:55 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 12 May 2017 16:58:55 -0700
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review Request: 8180326 Update
 the tables in java.desktop to be HTML-5 friendly
In-Reply-To: <59164B21.3050803@oracle.com>
References: <f42480bd-df84-48d4-a062-da030d9a4fb7@default>
 <59164B21.3050803@oracle.com>
Message-ID: <59164C3F.8070606@oracle.com>

Phil,

1. javadoc now provides support for 3 named styles in the default 
stylesheet:
         borderless:  no borders
         plain:  simple 1px borders around tables and cells
         striped: reduced borders; rows have alternating white and light 
grey backgrounds


2. summary attributes are not legal in HTML 5.
     For accessibility reasons, you should consider having a table 
caption instead.

-- Jon


On 05/12/2017 04:54 PM, Philip Race wrote:
> Does this in any way match the rest of the docs ? Or is everyone left 
> to style things how they want.
> I thought (?) maybe there is to be some javadoc tool support for CSS 
> styles.
>
> Also why are all the table summaries removed ?
>
> -phil.
>
> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>> This is because I use the same style for most of the tables 
>> 'class="striped"', which apply the same/unified style for all(most) 
>> of our tables.
>> Also this is because I removed 'inlined' styles, like here:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>
>>
>> ----- philip.race at oracle.com wrote:
>>
>>> Adding 2d-dev because a number of the files are 2D.
>>>
>>> What is the general reason for changing the appearance of the tables?
>>>
>>> -phil.
>>>
>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>> Hello,
>>>> Please review the fix for jdk9-dev.
>>>>
>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>> compatible to HTML5.
>>>> It covers all errors which are reported by the javadoc tool during
>>> the build of jdk for java.desktop module.
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>> Webrev can be found at:
>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>> Note that an appearance of some tables were changed after the fix:
>>>>
>>>> Before:
>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>
>>>> After:
>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>
>>>> Before:
>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>
>>>> After :
>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>
>>>> Before:
>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>
>>>> After:
>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>


From jonathan.gibbons at oracle.com  Sat May 13 00:07:20 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 12 May 2017 17:07:20 -0700
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review Request: 8180326 Update
 the tables in java.desktop to be HTML-5 friendly
In-Reply-To: <59164D5A.60200@oracle.com>
References: <f42480bd-df84-48d4-a062-da030d9a4fb7@default>
 <59164B21.3050803@oracle.com> <59164C3F.8070606@oracle.com>
 <59164D5A.60200@oracle.com>
Message-ID: <59164E38.5090809@oracle.com>



On 05/12/2017 05:03 PM, Philip Race wrote:
>
>
> On 5/12/17, 4:58 PM, Jonathan Gibbons wrote:
>> Phil,
>>
>> 1. javadoc now provides support for 3 named styles in the default 
>> stylesheet:
>>         borderless:  no borders
>>         plain:  simple 1px borders around tables and cells
>>         striped: reduced borders; rows have alternating white and 
>> light grey backgrounds
>>
> OK .. I see these being used.
>>
>> 2. summary attributes are not legal in HTML 5.
>>     For accessibility reasons, you should consider having a table 
>> caption instead.
>
> OK. I saw these but I wasn't clear it was a direct replacement. HTML 5 
> sometimes
> seems to be different just to be different ..

It's not a direct replacement. The summary attribute was used to give a 
more descriptive value
of the contents of the table.   A caption is more like a title. But the 
ARIA guidelines essentially
say, use one or the other, unless you want to dig deeper into aria 
attributes (not recommended.)

>
> -phil.
>>
>> -- Jon
>>
>>
>> On 05/12/2017 04:54 PM, Philip Race wrote:
>>> Does this in any way match the rest of the docs ? Or is everyone 
>>> left to style things how they want.
>>> I thought (?) maybe there is to be some javadoc tool support for CSS 
>>> styles.
>>>
>>> Also why are all the table summaries removed ?
>>>
>>> -phil.
>>>
>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>>> This is because I use the same style for most of the tables 
>>>> 'class="striped"', which apply the same/unified style for all(most) 
>>>> of our tables.
>>>> Also this is because I removed 'inlined' styles, like here:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>
>>>>
>>>> ----- philip.race at oracle.com wrote:
>>>>
>>>>> Adding 2d-dev because a number of the files are 2D.
>>>>>
>>>>> What is the general reason for changing the appearance of the tables?
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>>> Hello,
>>>>>> Please review the fix for jdk9-dev.
>>>>>>
>>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>>> compatible to HTML5.
>>>>>> It covers all errors which are reported by the javadoc tool during
>>>>> the build of jdk for java.desktop module.
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>>> Webrev can be found at:
>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>>> Note that an appearance of some tables were changed after the fix:
>>>>>>
>>>>>> Before:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>>
>>>>>> After:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>>>
>>>>>> Before:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>>>
>>>>>> After :
>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>>>
>>>>>> Before:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>>>
>>>>>> After:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>>>
>>


From jonathan.gibbons at oracle.com  Sat May 13 00:11:21 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 12 May 2017 17:11:21 -0700
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review Request: 8180326 Update
 the tables in java.desktop to be HTML-5 friendly
In-Reply-To: <cc06639b-5267-4b26-a487-e05aaf40879c@default>
References: <cc06639b-5267-4b26-a487-e05aaf40879c@default>
Message-ID: <59164F29.8070300@oracle.com>

Sergey,

FWIW, the invisible caption should be regarded as a temporary solution, 
until content authors can review/update the text of the caption and make 
it visible.

The general guideline in this conversion work has been to avoid changing 
the visible text of the specification, and captions fall into a grey 
area of whether the text is significant/normative or not.  Hence the 
temporary step to make them not displayed for now.

-- Jon

On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
> The "summary" is unsupported by the HTML5 and we replace it by invisible caption.
> These new styles are located in the stylesheet.css in the root of the JavaDoc api folder, so I assume these styles should be used by others as well.
> They were added by this fix:
> https://bugs.openjdk.java.net/browse/JDK-8179479
>
> ----- philip.race at oracle.com wrote:
>
>> Does this in any way match the rest of the docs ? Or is everyone left
>> to
>> style things how they want.
>> I thought (?) maybe there is to be some javadoc tool support for CSS
>> styles.
>>
>> Also why are all the table summaries removed ?
>>
>> -phil.
>>
>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>> This is because I use the same style for most of the tables
>> 'class="striped"', which apply the same/unified style for all(most) of
>> our tables.
>>> Also this is because I removed 'inlined' styles, like here:
>>>
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
>>> ----- philip.race at oracle.com wrote:
>>>
>>>> Adding 2d-dev because a number of the files are 2D.
>>>>
>>>> What is the general reason for changing the appearance of the
>> tables?
>>>> -phil.
>>>>
>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk9-dev.
>>>>>
>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>> compatible to HTML5.
>>>>> It covers all errors which are reported by the javadoc tool
>> during
>>>> the build of jdk for java.desktop module.
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>> Webrev can be found at:
>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>> Note that an appearance of some tables were changed after the
>> fix:
>>>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
>>>>> After:
>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html
>>>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html
>>>>> After :
>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html
>>>>> Before:
>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html
>>>>> After:
>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html


From bourges.laurent at gmail.com  Tue May 16 21:12:37 2017
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 16 May 2017 23:12:37 +0200
Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8180055: Upgrade the Marlin
 renderer in Java2D
In-Reply-To: <5b5585db-5017-43c5-a4b4-0d90271633b0@default>
References: <CAKjRUT54OikUMiPNxko7OCNaC4q5hO8ifSLbx4AVf4s1ejjDDQ@mail.gmail.com>
 <CAKjRUT4S0KmRBNn1MhfdTV8rfygahChD+L-v_SogEjD+_+haqw@mail.gmail.com>
 <27800b37-8369-4e3b-894f-aa1e1fb99873@default>
 <CAKjRUT7CAd37-o5ZsY=kXoc4JmA=-VjoY+omAzD5ph09A5Gx3Q@mail.gmail.com>
 <5b5585db-5017-43c5-a4b4-0d90271633b0@default>
Message-ID: <CAKjRUT7TL5Su=aQwOXd4-9Qc4EcS8TK-y2CA-FGr-rY_=yzZPg@mail.gmail.com>

Hi,

Here is a (slightly) modified Marlin2D patch after synchronizing again with
the coming MarlinFX patch:
http://cr.openjdk.java.net/~lbourges/marlin/Marlin-075.3/

Changes:
- (D)Helpers: fixed comment in subdivide()
- MarlinProperties: fixed indentation in align()

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170516/aaffb76d/attachment.html>

From bourges.laurent at gmail.com  Tue May 16 21:20:05 2017
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 16 May 2017 23:20:05 +0200
Subject: [OpenJDK 2D-Dev] [10] RFR 8078192: Path2D storage trimming
In-Reply-To: <58F93390.3060302@oracle.com>
References: <CAKjRUT7zQ=ZSqiQdbpdtOeCOSFoLVPzqHdvi-pXzsmwTgKRbDw@mail.gmail.com>
 <4a1d1917-dad7-6139-937a-39170c07b196@oracle.com>
 <CAKjRUT66H4pZdVSgKfrP+CT+9dxi3EmK417P6GP1yP5RrCThCQ@mail.gmail.com>
 <58F92273.6080403@oracle.com>
 <CAKjRUT6Rf=ua=2HP8qM7hDm+mtL7MWogjF+29g0U7HLyqKf0WQ@mail.gmail.com>
 <CAKjRUT59yL-ACOm3tee-od4iCdyaPvndYmA9+4r+4sQYs8QABA@mail.gmail.com>
 <58F93390.3060302@oracle.com>
Message-ID: <CAKjRUT7LJLb7aAZyaFNEJuAnpPM38BtC_tGrPwYBsS1Q-RU+eA@mail.gmail.com>

Phil,

Did you get any answer from the CSR process on this bug ?

Laurent


2017-04-21 0:17 GMT+02:00 Philip Race <philip.race at oracle.com>:

> OK. Although we still need to wait for the CSR process.
>
> -phil.
>
>
> On 4/20/17, 3:05 PM, Laurent Bourg?s wrote:
>
> Sorry (bad shortcut);
>
> Here is the fixed webrev:
> http://cr.openjdk.java.net/~lbourges/path2D/Path2D-8078192.3/
>
> Laurent
>
> 2017-04-21 0:04 GMT+02:00 Laurent Bourg?s <bourges.laurent at gmail.com>:
>
>> Sorry for the typo, I added also a newline before @since:
>>
>>
>> 2017-04-20 23:04 GMT+02:00 Philip Race <philip.race at oracle.com>:
>>
>>>  You have a capital letter here and I think it must be lower case ..
>>>
>>>
>>> 2499      * @Since 10
>>>
>>> -phil.
>>>
>>>
>>> On 4/20/17, 1:58 PM, Laurent Bourg?s wrote:
>>>
>>> Hi Phil & Jim,
>>>
>>> Here is the updated webrev:
>>> http://cr.openjdk.java.net/~lbourges/path2D/Path2D-8078192.2/
>>>
>>> Changes:
>>> - trimToSize() return void
>>> - fixed test + jtreg passed
>>>
>>> Bye,
>>> Laurent
>>>
>>> 2017-04-20 21:30 GMT+02:00 Jim Graham <james.graham at oracle.com>:
>>>
>>>> Hi Laurent,
>>>>
>>>> The implementation looks good, except that the method chaining-style
>>>> return value seems out of place here.  Similar trimToSize() methods in
>>>> Collections return void and none of the other methods in this area use the
>>>> method chaining paradigm.  In the interest of maintaining a common design
>>>> theme throughout 2D this method should just return void.
>>>>
>>>>                         ...jim
>>>>
>>>>
>>>> On 4/18/17 11:49 PM, Laurent Bourg?s wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Here is a first attempt to propose a Path2D patch (based on JDK10):
>>>>> http://cr.openjdk.java.net/~lbourges/path2D/Path2D-8078192.0/
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078192
>>>>>
>>>>> Please review the Path2D changes, notably the javadoc (english) and
>>>>> the modified Path2DCopyConstructor test which checks
>>>>> all public Path2D methods on concrete classes (Path2D.Float,
>>>>> Path2D.Double, GeneralPath) after calling path.trimToSize()
>>>>>
>>>>> Cheers,
>>>>> Laurent
>>>>>
>>>>
>>>
>>>
>>> --
>>> --
>>> Laurent Bourg?s
>>>
>>>
>>
>>
>> --
>> --
>> Laurent Bourg?s
>>
>
>
>
> --
> --
> Laurent Bourg?s
>
>


-- 
-- 
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170516/5664e3ab/attachment.html>

From james.graham at oracle.com  Tue May 16 22:15:09 2017
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 16 May 2017 15:15:09 -0700
Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8180055: Upgrade the Marlin
 renderer in Java2D
In-Reply-To: <CAKjRUT7TL5Su=aQwOXd4-9Qc4EcS8TK-y2CA-FGr-rY_=yzZPg@mail.gmail.com>
References: <CAKjRUT54OikUMiPNxko7OCNaC4q5hO8ifSLbx4AVf4s1ejjDDQ@mail.gmail.com>
 <CAKjRUT4S0KmRBNn1MhfdTV8rfygahChD+L-v_SogEjD+_+haqw@mail.gmail.com>
 <27800b37-8369-4e3b-894f-aa1e1fb99873@default>
 <CAKjRUT7CAd37-o5ZsY=kXoc4JmA=-VjoY+omAzD5ph09A5Gx3Q@mail.gmail.com>
 <5b5585db-5017-43c5-a4b4-0d90271633b0@default>
 <CAKjRUT7TL5Su=aQwOXd4-9Qc4EcS8TK-y2CA-FGr-rY_=yzZPg@mail.gmail.com>
Message-ID: <8d385c9f-288b-b347-2378-ed12e77a5554@oracle.com>

This looks good.  Approved...

			...jim

On 5/16/17 2:12 PM, Laurent Bourg?s wrote:
> Hi,
>
> Here is a (slightly) modified Marlin2D patch after synchronizing again with the coming MarlinFX patch:
> http://cr.openjdk.java.net/~lbourges/marlin/Marlin-075.3/
>
> Changes:
> - (D)Helpers: fixed comment in subdivide()
> - MarlinProperties: fixed indentation in align()
>
> Cheers,
> Laurent

From philip.race at oracle.com  Wed May 17 17:44:45 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 17 May 2017 10:44:45 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8177393: Result of RescaleOp for 4BYTE_ABGR
 images may be 25% black
Message-ID: <94ab2091-34f8-90da-0d4d-f322ff659159@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8177393
Webrev: http://cr.openjdk.java.net/~prr/8177393/

I have updated the bug report with a long evaluation and some additional
explanation of the proposed fix. I don't intend to duplicate all that here
so please go read it there. The following is a much briefer summary.

We are ending up in medialib native code that cannot interpret the Java 
2D child raster
it is handed. The child raster was an attempt to prevent rescaling of 
the alpha channel.

The proposed fix avoids creating that child raster and instead creates a 
LookupOp
which has an explicit lookup table for the alpha channel that does the 
identity lookup.

The fix has a couple of other updates.
(1) the "canUseLookupOp()" method now checks that the DataBuffer is
something that the medialib code used by LookupOp can handle.
This would have fixed the bug by itself although at the expense of always
falling back to slow Java code in RescaleOp. However it is still needed in
case the application itself supplies a child raster.

(2) The slow path in RescaleOp turns out to have the same bug that I think
was seen in some other bug report or fix. It is always re-scaling alpha as
well as colour components. I fixed that too.

Since the fix is entirely confined to RescaleOp any consequences - good 
or bad - are limited.

I ran the few regression tests we have that cover RescaleOp and also 
checked Java2Ddemo.

The commented out cases in the new regression test are to be handled 
under a different bug ID.

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

From philip.race at oracle.com  Wed May 17 18:19:01 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 17 May 2017 11:19:01 -0700
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review Request: 8180326 Update
 the tables in java.desktop to be HTML-5 friendly
In-Reply-To: <59164F29.8070300@oracle.com>
References: <cc06639b-5267-4b26-a487-e05aaf40879c@default>
 <59164F29.8070300@oracle.com>
Message-ID: <635d9ffc-bb5d-2a4e-273f-4b477caa7239@oracle.com>

I am not sure we are using the summary in a way that  makes it worthwhile.
As you noted in the other mail
"The summary attribute was used to give a more descriptive value
of the contents of the table.   A caption is more like a title"

The values I see are more like a title and as you say that is not the 
idea. See the example here

https://www.w3.org/TR/WCAG20-TECHS/H73.html

Caption sounds like a title so it might actually be more appropriate 
than summary
for the text we have except that its not clear why we'd want it to be 
visible when we were fine without.

But being there and invisible may be pointless unless screen readers 
look for it even if invisible.

But if its not doing any harm I guess we can leave it as proposed

I still need to look at the rest of the changes.

-phil.

On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
> Sergey,
>
> FWIW, the invisible caption should be regarded as a temporary 
> solution, until content authors can review/update the text of the 
> caption and make it visible.
>
> The general guideline in this conversion work has been to avoid 
> changing the visible text of the specification, and captions fall into 
> a grey area of whether the text is significant/normative or not.  
> Hence the temporary step to make them not displayed for now.
>
> -- Jon
>
> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
>> The "summary" is unsupported by the HTML5 and we replace it by 
>> invisible caption.
>> These new styles are located in the stylesheet.css in the root of the 
>> JavaDoc api folder, so I assume these styles should be used by others 
>> as well.
>> They were added by this fix:
>> https://bugs.openjdk.java.net/browse/JDK-8179479
>>
>> ----- philip.race at oracle.com wrote:
>>
>>> Does this in any way match the rest of the docs ? Or is everyone left
>>> to
>>> style things how they want.
>>> I thought (?) maybe there is to be some javadoc tool support for CSS
>>> styles.
>>>
>>> Also why are all the table summaries removed ?
>>>
>>> -phil.
>>>
>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>>> This is because I use the same style for most of the tables
>>> 'class="striped"', which apply the same/unified style for all(most) of
>>> our tables.
>>>> Also this is because I removed 'inlined' styles, like here:
>>>>
>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>
>>>> ----- philip.race at oracle.com wrote:
>>>>
>>>>> Adding 2d-dev because a number of the files are 2D.
>>>>>
>>>>> What is the general reason for changing the appearance of the
>>> tables?
>>>>> -phil.
>>>>>
>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>>> Hello,
>>>>>> Please review the fix for jdk9-dev.
>>>>>>
>>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>>> compatible to HTML5.
>>>>>> It covers all errors which are reported by the javadoc tool
>>> during
>>>>> the build of jdk for java.desktop module.
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>>> Webrev can be found at:
>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>>> Note that an appearance of some tables were changed after the
>>> fix:
>>>>>> Before:
>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>
>>>>>> After:
>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>
>>>>>> Before:
>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>
>>>>>> After :
>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>
>>>>>> Before:
>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>
>>>>>> After:
>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>
>


From jonathan.gibbons at oracle.com  Wed May 17 18:52:25 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 17 May 2017 11:52:25 -0700
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review Request: 8180326 Update
 the tables in java.desktop to be HTML-5 friendly
In-Reply-To: <635d9ffc-bb5d-2a4e-273f-4b477caa7239@oracle.com>
References: <cc06639b-5267-4b26-a487-e05aaf40879c@default>
 <59164F29.8070300@oracle.com>
 <635d9ffc-bb5d-2a4e-273f-4b477caa7239@oracle.com>
Message-ID: <591C9BE9.1080905@oracle.com>

Phil,

The bottom line is that in the JDK docs, tables should not have a 
summary attribute and should have a caption. This comes down to 
accessibility requirements, where we are slowly raising the bar on our 
docs, to be in accordance with Oracle's guidelines.

Hiding the caption (style="display:none") is an interim measure we have 
been using during the HTML 5 updates, especially in cases where the 
person doing the markup changes did not know enough to create an 
appropriate caption that should be displayed. In time, we should locate 
and update all table captions (in our standard docs bundle) that are not 
being displayed such that the text is both appropriate and visible.  If 
you guys want to do that as part of this update, go ahead.  FWIW, that 
is what we did for the java.xml module in the jaxp repo ... pretty much 
all tables there now have a reasonable, visible caption.

-- Jon



On 05/17/2017 11:19 AM, Phil Race wrote:
> I am not sure we are using the summary in a way that makes it worthwhile.
> As you noted in the other mail
> "The summary attribute was used to give a more descriptive value
> of the contents of the table.   A caption is more like a title"
>
> The values I see are more like a title and as you say that is not the 
> idea. See the example here
>
> https://www.w3.org/TR/WCAG20-TECHS/H73.html
>
> Caption sounds like a title so it might actually be more appropriate 
> than summary
> for the text we have except that its not clear why we'd want it to be 
> visible when we were fine without.
>
> But being there and invisible may be pointless unless screen readers 
> look for it even if invisible.
>
> But if its not doing any harm I guess we can leave it as proposed
>
> I still need to look at the rest of the changes.
>
> -phil.
>
> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
>> Sergey,
>>
>> FWIW, the invisible caption should be regarded as a temporary 
>> solution, until content authors can review/update the text of the 
>> caption and make it visible.
>>
>> The general guideline in this conversion work has been to avoid 
>> changing the visible text of the specification, and captions fall 
>> into a grey area of whether the text is significant/normative or 
>> not.  Hence the temporary step to make them not displayed for now.
>>
>> -- Jon
>>
>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
>>> The "summary" is unsupported by the HTML5 and we replace it by 
>>> invisible caption.
>>> These new styles are located in the stylesheet.css in the root of 
>>> the JavaDoc api folder, so I assume these styles should be used by 
>>> others as well.
>>> They were added by this fix:
>>> https://bugs.openjdk.java.net/browse/JDK-8179479
>>>
>>> ----- philip.race at oracle.com wrote:
>>>
>>>> Does this in any way match the rest of the docs ? Or is everyone left
>>>> to
>>>> style things how they want.
>>>> I thought (?) maybe there is to be some javadoc tool support for CSS
>>>> styles.
>>>>
>>>> Also why are all the table summaries removed ?
>>>>
>>>> -phil.
>>>>
>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>>>> This is because I use the same style for most of the tables
>>>> 'class="striped"', which apply the same/unified style for all(most) of
>>>> our tables.
>>>>> Also this is because I removed 'inlined' styles, like here:
>>>>>
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>
>>>>> ----- philip.race at oracle.com wrote:
>>>>>
>>>>>> Adding 2d-dev because a number of the files are 2D.
>>>>>>
>>>>>> What is the general reason for changing the appearance of the
>>>> tables?
>>>>>> -phil.
>>>>>>
>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>>>> Hello,
>>>>>>> Please review the fix for jdk9-dev.
>>>>>>>
>>>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>>>> compatible to HTML5.
>>>>>>> It covers all errors which are reported by the javadoc tool
>>>> during
>>>>>> the build of jdk for java.desktop module.
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>>>> Webrev can be found at:
>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>>>> Note that an appearance of some tables were changed after the
>>>> fix:
>>>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>
>>>>>>> After:
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>>
>>>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>>
>>>>>>> After :
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>>
>>>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>>
>>>>>>> After:
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>>
>>
>


From philip.race at oracle.com  Wed May 17 18:52:04 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 17 May 2017 11:52:04 -0700
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review Request: 8180326 Update
 the tables in java.desktop to be HTML-5 friendly
In-Reply-To: <635d9ffc-bb5d-2a4e-273f-4b477caa7239@oracle.com>
References: <cc06639b-5267-4b26-a487-e05aaf40879c@default>
 <59164F29.8070300@oracle.com>
 <635d9ffc-bb5d-2a4e-273f-4b477caa7239@oracle.com>
Message-ID: <5322c0d0-1ce4-10e8-e9e0-df305420274c@oracle.com>

I've looked through all the files now. No other comments. So approved.

-phil.

On 05/17/2017 11:19 AM, Phil Race wrote:
> I am not sure we are using the summary in a way that makes it worthwhile.
> As you noted in the other mail
> "The summary attribute was used to give a more descriptive value
> of the contents of the table.   A caption is more like a title"
>
> The values I see are more like a title and as you say that is not the 
> idea. See the example here
>
> https://www.w3.org/TR/WCAG20-TECHS/H73.html
>
> Caption sounds like a title so it might actually be more appropriate 
> than summary
> for the text we have except that its not clear why we'd want it to be 
> visible when we were fine without.
>
> But being there and invisible may be pointless unless screen readers 
> look for it even if invisible.
>
> But if its not doing any harm I guess we can leave it as proposed
>
> I still need to look at the rest of the changes.
>
> -phil.
>
> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
>> Sergey,
>>
>> FWIW, the invisible caption should be regarded as a temporary 
>> solution, until content authors can review/update the text of the 
>> caption and make it visible.
>>
>> The general guideline in this conversion work has been to avoid 
>> changing the visible text of the specification, and captions fall 
>> into a grey area of whether the text is significant/normative or 
>> not.  Hence the temporary step to make them not displayed for now.
>>
>> -- Jon
>>
>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
>>> The "summary" is unsupported by the HTML5 and we replace it by 
>>> invisible caption.
>>> These new styles are located in the stylesheet.css in the root of 
>>> the JavaDoc api folder, so I assume these styles should be used by 
>>> others as well.
>>> They were added by this fix:
>>> https://bugs.openjdk.java.net/browse/JDK-8179479
>>>
>>> ----- philip.race at oracle.com wrote:
>>>
>>>> Does this in any way match the rest of the docs ? Or is everyone left
>>>> to
>>>> style things how they want.
>>>> I thought (?) maybe there is to be some javadoc tool support for CSS
>>>> styles.
>>>>
>>>> Also why are all the table summaries removed ?
>>>>
>>>> -phil.
>>>>
>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>>>> This is because I use the same style for most of the tables
>>>> 'class="striped"', which apply the same/unified style for all(most) of
>>>> our tables.
>>>>> Also this is because I removed 'inlined' styles, like here:
>>>>>
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>
>>>>> ----- philip.race at oracle.com wrote:
>>>>>
>>>>>> Adding 2d-dev because a number of the files are 2D.
>>>>>>
>>>>>> What is the general reason for changing the appearance of the
>>>> tables?
>>>>>> -phil.
>>>>>>
>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>>>> Hello,
>>>>>>> Please review the fix for jdk9-dev.
>>>>>>>
>>>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>>>> compatible to HTML5.
>>>>>>> It covers all errors which are reported by the javadoc tool
>>>> during
>>>>>> the build of jdk for java.desktop module.
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>>>> Webrev can be found at:
>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>>>> Note that an appearance of some tables were changed after the
>>>> fix:
>>>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>
>>>>>>> After:
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>>
>>>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>>
>>>>>>> After :
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>>
>>>>>>> Before:
>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>>
>>>>>>> After:
>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>>
>>
>


From philip.race at oracle.com  Wed May 17 18:54:42 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 17 May 2017 11:54:42 -0700
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review Request: 8180326 Update
 the tables in java.desktop to be HTML-5 friendly
In-Reply-To: <591C9BE9.1080905@oracle.com>
References: <cc06639b-5267-4b26-a487-e05aaf40879c@default>
 <59164F29.8070300@oracle.com>
 <635d9ffc-bb5d-2a4e-273f-4b477caa7239@oracle.com>
 <591C9BE9.1080905@oracle.com>
Message-ID: <14e7746f-b3a6-7310-1b3a-e1196acf96d8@oracle.com>

I will leave the decision on whether to do that now up to Sergey although
it seems all he has to do here is remove "invisible".
Many of the "summary" ones had wrong or misleading text but they
seem to have been all fixed.

I'd want to see what the new HTML looks like with a visible title of 
course ..

-phil.

On 05/17/2017 11:52 AM, Jonathan Gibbons wrote:
> Phil,
>
> The bottom line is that in the JDK docs, tables should not have a 
> summary attribute and should have a caption. This comes down to 
> accessibility requirements, where we are slowly raising the bar on our 
> docs, to be in accordance with Oracle's guidelines.
>
> Hiding the caption (style="display:none") is an interim measure we 
> have been using during the HTML 5 updates, especially in cases where 
> the person doing the markup changes did not know enough to create an 
> appropriate caption that should be displayed. In time, we should 
> locate and update all table captions (in our standard docs bundle) 
> that are not being displayed such that the text is both appropriate 
> and visible.  If you guys want to do that as part of this update, go 
> ahead.  FWIW, that is what we did for the java.xml module in the jaxp 
> repo ... pretty much all tables there now have a reasonable, visible 
> caption.
>
> -- Jon
>
>
>
> On 05/17/2017 11:19 AM, Phil Race wrote:
>> I am not sure we are using the summary in a way that makes it 
>> worthwhile.
>> As you noted in the other mail
>> "The summary attribute was used to give a more descriptive value
>> of the contents of the table.   A caption is more like a title"
>>
>> The values I see are more like a title and as you say that is not the 
>> idea. See the example here
>>
>> https://www.w3.org/TR/WCAG20-TECHS/H73.html
>>
>> Caption sounds like a title so it might actually be more appropriate 
>> than summary
>> for the text we have except that its not clear why we'd want it to be 
>> visible when we were fine without.
>>
>> But being there and invisible may be pointless unless screen readers 
>> look for it even if invisible.
>>
>> But if its not doing any harm I guess we can leave it as proposed
>>
>> I still need to look at the rest of the changes.
>>
>> -phil.
>>
>> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
>>> Sergey,
>>>
>>> FWIW, the invisible caption should be regarded as a temporary 
>>> solution, until content authors can review/update the text of the 
>>> caption and make it visible.
>>>
>>> The general guideline in this conversion work has been to avoid 
>>> changing the visible text of the specification, and captions fall 
>>> into a grey area of whether the text is significant/normative or 
>>> not.  Hence the temporary step to make them not displayed for now.
>>>
>>> -- Jon
>>>
>>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
>>>> The "summary" is unsupported by the HTML5 and we replace it by 
>>>> invisible caption.
>>>> These new styles are located in the stylesheet.css in the root of 
>>>> the JavaDoc api folder, so I assume these styles should be used by 
>>>> others as well.
>>>> They were added by this fix:
>>>> https://bugs.openjdk.java.net/browse/JDK-8179479
>>>>
>>>> ----- philip.race at oracle.com wrote:
>>>>
>>>>> Does this in any way match the rest of the docs ? Or is everyone left
>>>>> to
>>>>> style things how they want.
>>>>> I thought (?) maybe there is to be some javadoc tool support for CSS
>>>>> styles.
>>>>>
>>>>> Also why are all the table summaries removed ?
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>>>>> This is because I use the same style for most of the tables
>>>>> 'class="striped"', which apply the same/unified style for 
>>>>> all(most) of
>>>>> our tables.
>>>>>> Also this is because I removed 'inlined' styles, like here:
>>>>>>
>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>>
>>>>>> ----- philip.race at oracle.com wrote:
>>>>>>
>>>>>>> Adding 2d-dev because a number of the files are 2D.
>>>>>>>
>>>>>>> What is the general reason for changing the appearance of the
>>>>> tables?
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>>>>> Hello,
>>>>>>>> Please review the fix for jdk9-dev.
>>>>>>>>
>>>>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>>>>> compatible to HTML5.
>>>>>>>> It covers all errors which are reported by the javadoc tool
>>>>> during
>>>>>>> the build of jdk for java.desktop module.
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>>>>> Webrev can be found at:
>>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>>>>> Note that an appearance of some tables were changed after the
>>>>> fix:
>>>>>>>> Before:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>>
>>>>>>>> After:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>>>
>>>>>>>> Before:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>>>
>>>>>>>> After :
>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>>>
>>>>>>>> Before:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>>>
>>>>>>>> After:
>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>>>
>>>
>>
>


From philip.race at oracle.com  Wed May 17 18:58:53 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 17 May 2017 11:58:53 -0700
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review Request: 8180326 Update
 the tables in java.desktop to be HTML-5 friendly
In-Reply-To: <14e7746f-b3a6-7310-1b3a-e1196acf96d8@oracle.com>
References: <cc06639b-5267-4b26-a487-e05aaf40879c@default>
 <59164F29.8070300@oracle.com>
 <635d9ffc-bb5d-2a4e-273f-4b477caa7239@oracle.com>
 <591C9BE9.1080905@oracle.com>
 <14e7746f-b3a6-7310-1b3a-e1196acf96d8@oracle.com>
Message-ID: <f1af3ebd-abde-d4e4-1091-e6165612cba6@oracle.com>

And PS I was not saying anything to contradict
 > tables should not have a summary attribute and should have a caption.

However that the docs I read on the web did seem to imply that
summary was very much intended for ATs but it was not at all clear this
is the point of caption. I'm sure they can read it, but I don't get how 
making
it visible matters to them so how it making it visible relates to 
accessibility
requirements is not an obvious connection to me. So why do we have
to make it visible for ATs ?

-phil.

On 05/17/2017 11:54 AM, Phil Race wrote:
> I will leave the decision on whether to do that now up to Sergey although
> it seems all he has to do here is remove "invisible".
> Many of the "summary" ones had wrong or misleading text but they
> seem to have been all fixed.
>
> I'd want to see what the new HTML looks like with a visible title of 
> course ..
>
> -phil.
>
> On 05/17/2017 11:52 AM, Jonathan Gibbons wrote:
>> Phil,
>>
>> The bottom line is that in the JDK docs, tables should not have a 
>> summary attribute and should have a caption. This comes down to 
>> accessibility requirements, where we are slowly raising the bar on 
>> our docs, to be in accordance with Oracle's guidelines.
>>
>> Hiding the caption (style="display:none") is an interim measure we 
>> have been using during the HTML 5 updates, especially in cases where 
>> the person doing the markup changes did not know enough to create an 
>> appropriate caption that should be displayed. In time, we should 
>> locate and update all table captions (in our standard docs bundle) 
>> that are not being displayed such that the text is both appropriate 
>> and visible. If you guys want to do that as part of this update, go 
>> ahead. FWIW, that is what we did for the java.xml module in the jaxp 
>> repo ... pretty much all tables there now have a reasonable, visible 
>> caption.
>>
>> -- Jon
>>
>>
>>
>> On 05/17/2017 11:19 AM, Phil Race wrote:
>>> I am not sure we are using the summary in a way that makes it 
>>> worthwhile.
>>> As you noted in the other mail
>>> "The summary attribute was used to give a more descriptive value
>>> of the contents of the table.   A caption is more like a title"
>>>
>>> The values I see are more like a title and as you say that is not 
>>> the idea. See the example here
>>>
>>> https://www.w3.org/TR/WCAG20-TECHS/H73.html
>>>
>>> Caption sounds like a title so it might actually be more appropriate 
>>> than summary
>>> for the text we have except that its not clear why we'd want it to 
>>> be visible when we were fine without.
>>>
>>> But being there and invisible may be pointless unless screen readers 
>>> look for it even if invisible.
>>>
>>> But if its not doing any harm I guess we can leave it as proposed
>>>
>>> I still need to look at the rest of the changes.
>>>
>>> -phil.
>>>
>>> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
>>>> Sergey,
>>>>
>>>> FWIW, the invisible caption should be regarded as a temporary 
>>>> solution, until content authors can review/update the text of the 
>>>> caption and make it visible.
>>>>
>>>> The general guideline in this conversion work has been to avoid 
>>>> changing the visible text of the specification, and captions fall 
>>>> into a grey area of whether the text is significant/normative or 
>>>> not.  Hence the temporary step to make them not displayed for now.
>>>>
>>>> -- Jon
>>>>
>>>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
>>>>> The "summary" is unsupported by the HTML5 and we replace it by 
>>>>> invisible caption.
>>>>> These new styles are located in the stylesheet.css in the root of 
>>>>> the JavaDoc api folder, so I assume these styles should be used by 
>>>>> others as well.
>>>>> They were added by this fix:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8179479
>>>>>
>>>>> ----- philip.race at oracle.com wrote:
>>>>>
>>>>>> Does this in any way match the rest of the docs ? Or is everyone 
>>>>>> left
>>>>>> to
>>>>>> style things how they want.
>>>>>> I thought (?) maybe there is to be some javadoc tool support for CSS
>>>>>> styles.
>>>>>>
>>>>>> Also why are all the table summaries removed ?
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>>>>>> This is because I use the same style for most of the tables
>>>>>> 'class="striped"', which apply the same/unified style for 
>>>>>> all(most) of
>>>>>> our tables.
>>>>>>> Also this is because I removed 'inlined' styles, like here:
>>>>>>>
>>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>>>
>>>>>>> ----- philip.race at oracle.com wrote:
>>>>>>>
>>>>>>>> Adding 2d-dev because a number of the files are 2D.
>>>>>>>>
>>>>>>>> What is the general reason for changing the appearance of the
>>>>>> tables?
>>>>>>>> -phil.
>>>>>>>>
>>>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>>>>>> Hello,
>>>>>>>>> Please review the fix for jdk9-dev.
>>>>>>>>>
>>>>>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>>>>>> compatible to HTML5.
>>>>>>>>> It covers all errors which are reported by the javadoc tool
>>>>>> during
>>>>>>>> the build of jdk for java.desktop module.
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>>>>>> Webrev can be found at:
>>>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>>>>>> Note that an appearance of some tables were changed after the
>>>>>> fix:
>>>>>>>>> Before:
>>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>>>
>>>>>>>>> After:
>>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>>>>
>>>>>>>>> Before:
>>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>>>>
>>>>>>>>> After :
>>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>>>>
>>>>>>>>> Before:
>>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>>>>
>>>>>>>>> After:
>>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>>>>
>>>>
>>>
>>
>


From philip.race at oracle.com  Wed May 17 20:04:15 2017
From: philip.race at oracle.com (Phil Race)
Date: Wed, 17 May 2017 13:04:15 -0700
Subject: [OpenJDK 2D-Dev] [10] RFR 8078192: Path2D storage trimming
In-Reply-To: <CAKjRUT7LJLb7aAZyaFNEJuAnpPM38BtC_tGrPwYBsS1Q-RU+eA@mail.gmail.com>
References: <CAKjRUT7zQ=ZSqiQdbpdtOeCOSFoLVPzqHdvi-pXzsmwTgKRbDw@mail.gmail.com>
 <4a1d1917-dad7-6139-937a-39170c07b196@oracle.com>
 <CAKjRUT66H4pZdVSgKfrP+CT+9dxi3EmK417P6GP1yP5RrCThCQ@mail.gmail.com>
 <58F92273.6080403@oracle.com>
 <CAKjRUT6Rf=ua=2HP8qM7hDm+mtL7MWogjF+29g0U7HLyqKf0WQ@mail.gmail.com>
 <CAKjRUT59yL-ACOm3tee-od4iCdyaPvndYmA9+4r+4sQYs8QABA@mail.gmail.com>
 <58F93390.3060302@oracle.com>
 <CAKjRUT7LJLb7aAZyaFNEJuAnpPM38BtC_tGrPwYBsS1Q-RU+eA@mail.gmail.com>
Message-ID: <81bf576a-ddfe-9174-b234-7d070e163d26@oracle.com>

Early next week is the hope.

-phil

On 05/16/2017 02:20 PM, Laurent Bourg?s wrote:
> Phil,
>
> Did you get any answer from the CSR process on this bug ?
>
> Laurent
>
>
> 2017-04-21 0:17 GMT+02:00 Philip Race <philip.race at oracle.com 
> <mailto:philip.race at oracle.com>>:
>
>     OK. Although we still need to wait for the CSR process.
>
>     -phil.
>
>
>     On 4/20/17, 3:05 PM, Laurent Bourg?s wrote:
>>     Sorry (bad shortcut);
>>
>>     Here is the fixed webrev:
>>     http://cr.openjdk.java.net/~lbourges/path2D/Path2D-8078192.3/
>>     <http://cr.openjdk.java.net/%7Elbourges/path2D/Path2D-8078192.3/>
>>
>>     Laurent
>>
>>     2017-04-21 0:04 GMT+02:00 Laurent Bourg?s
>>     <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>>:
>>
>>         Sorry for the typo, I added also a newline before @since:
>>
>>
>>         2017-04-20 23:04 GMT+02:00 Philip Race
>>         <philip.race at oracle.com <mailto:philip.race at oracle.com>>:
>>
>>              You have a capital letter here and I think it must be
>>             lower case ..
>>
>>
>>             2499      * @Since 10
>>
>>             -phil.
>>
>>
>>             On 4/20/17, 1:58 PM, Laurent Bourg?s wrote:
>>>             Hi Phil & Jim,
>>>
>>>             Here is the updated webrev:
>>>             http://cr.openjdk.java.net/~lbourges/path2D/Path2D-8078192.2/
>>>             <http://cr.openjdk.java.net/%7Elbourges/path2D/Path2D-8078192.2/>
>>>
>>>             Changes:
>>>             - trimToSize() return void
>>>             - fixed test + jtreg passed
>>>
>>>             Bye,
>>>             Laurent
>>>
>>>             2017-04-20 21:30 GMT+02:00 Jim Graham
>>>             <james.graham at oracle.com <mailto:james.graham at oracle.com>>:
>>>
>>>                 Hi Laurent,
>>>
>>>                 The implementation looks good, except that the
>>>                 method chaining-style return value seems out of
>>>                 place here. Similar trimToSize() methods in
>>>                 Collections return void and none of the other
>>>                 methods in this area use the method chaining
>>>                 paradigm.  In the interest of maintaining a common
>>>                 design theme throughout 2D this method should just
>>>                 return void.
>>>
>>>                         ...jim
>>>
>>>
>>>                 On 4/18/17 11:49 PM, Laurent Bourg?s wrote:
>>>
>>>                     Hi,
>>>
>>>                     Here is a first attempt to propose a Path2D
>>>                     patch (based on JDK10):
>>>                     http://cr.openjdk.java.net/~lbourges/path2D/Path2D-8078192.0/
>>>                     <http://cr.openjdk.java.net/%7Elbourges/path2D/Path2D-8078192.0/>
>>>
>>>                     JBS:
>>>                     https://bugs.openjdk.java.net/browse/JDK-8078192
>>>                     <https://bugs.openjdk.java.net/browse/JDK-8078192>
>>>
>>>                     Please review the Path2D changes, notably the
>>>                     javadoc (english) and the modified
>>>                     Path2DCopyConstructor test which checks
>>>                     all public Path2D methods on concrete classes
>>>                     (Path2D.Float, Path2D.Double, GeneralPath) after
>>>                     calling path.trimToSize()
>>>
>>>                     Cheers,
>>>                     Laurent
>>>
>>>
>>>
>>>
>>>             -- 
>>>             -- 
>>>             Laurent Bourg?s
>>
>>
>>
>>
>>         -- 
>>         -- 
>>         Laurent Bourg?s
>>
>>
>>
>>
>>     -- 
>>     -- 
>>     Laurent Bourg?s
>
>
>
>
> -- 
> -- 
> Laurent Bourg?s

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

From bourges.laurent at gmail.com  Wed May 17 20:12:35 2017
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 17 May 2017 22:12:35 +0200
Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8180055: Upgrade the Marlin
 renderer in Java2D
In-Reply-To: <8d385c9f-288b-b347-2378-ed12e77a5554@oracle.com>
References: <CAKjRUT54OikUMiPNxko7OCNaC4q5hO8ifSLbx4AVf4s1ejjDDQ@mail.gmail.com>
 <CAKjRUT4S0KmRBNn1MhfdTV8rfygahChD+L-v_SogEjD+_+haqw@mail.gmail.com>
 <27800b37-8369-4e3b-894f-aa1e1fb99873@default>
 <CAKjRUT7CAd37-o5ZsY=kXoc4JmA=-VjoY+omAzD5ph09A5Gx3Q@mail.gmail.com>
 <5b5585db-5017-43c5-a4b4-0d90271633b0@default>
 <CAKjRUT7TL5Su=aQwOXd4-9Qc4EcS8TK-y2CA-FGr-rY_=yzZPg@mail.gmail.com>
 <8d385c9f-288b-b347-2378-ed12e77a5554@oracle.com>
Message-ID: <CAKjRUT5c1kWvSzg+HXigZNHr98hhwCtac7CmnoPB04Se3E_Zjg@mail.gmail.com>

Marlin2D Patch pushed:
URL: http://hg.openjdk.java.net/jdk10/client/jdk/rev/a6c0c022f56f

Thanks a lot, that was a quite big patch.

Laurent


2017-05-17 0:15 GMT+02:00 Jim Graham <james.graham at oracle.com>:

> This looks good.  Approved...
>
>                         ...jim
>
>
> On 5/16/17 2:12 PM, Laurent Bourg?s wrote:
>
>> Hi,
>>
>> Here is a (slightly) modified Marlin2D patch after synchronizing again
>> with the coming MarlinFX patch:
>> http://cr.openjdk.java.net/~lbourges/marlin/Marlin-075.3/
>>
>> Changes:
>> - (D)Helpers: fixed comment in subdivide()
>> - MarlinProperties: fixed indentation in align()
>>
>> Cheers,
>> Laurent
>>
>


-- 
-- 
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170517/0b2067b4/attachment.html>

From jonathan.gibbons at oracle.com  Wed May 17 21:41:17 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 17 May 2017 14:41:17 -0700
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review Request: 8180326 Update
 the tables in java.desktop to be HTML-5 friendly
In-Reply-To: <f1af3ebd-abde-d4e4-1091-e6165612cba6@oracle.com>
References: <cc06639b-5267-4b26-a487-e05aaf40879c@default>
 <59164F29.8070300@oracle.com>
 <635d9ffc-bb5d-2a4e-273f-4b477caa7239@oracle.com>
 <591C9BE9.1080905@oracle.com>
 <14e7746f-b3a6-7310-1b3a-e1196acf96d8@oracle.com>
 <f1af3ebd-abde-d4e4-1091-e6165612cba6@oracle.com>
Message-ID: <591CC37D.70709@oracle.com>

Phil,

I have no evidence one way or the other whether screen readers pay 
attention
to undisplayed or invisible captions. It seemed safest to assume that 
they would
read a visible caption, and that we should head in that general direction.

-- Jon


On 05/17/2017 11:58 AM, Phil Race wrote:
> And PS I was not saying anything to contradict
> > tables should not have a summary attribute and should have a caption.
>
> However that the docs I read on the web did seem to imply that
> summary was very much intended for ATs but it was not at all clear this
> is the point of caption. I'm sure they can read it, but I don't get 
> how making
> it visible matters to them so how it making it visible relates to 
> accessibility
> requirements is not an obvious connection to me. So why do we have
> to make it visible for ATs ?
>
> -phil.
>
> On 05/17/2017 11:54 AM, Phil Race wrote:
>> I will leave the decision on whether to do that now up to Sergey 
>> although
>> it seems all he has to do here is remove "invisible".
>> Many of the "summary" ones had wrong or misleading text but they
>> seem to have been all fixed.
>>
>> I'd want to see what the new HTML looks like with a visible title of 
>> course ..
>>
>> -phil.
>>
>> On 05/17/2017 11:52 AM, Jonathan Gibbons wrote:
>>> Phil,
>>>
>>> The bottom line is that in the JDK docs, tables should not have a 
>>> summary attribute and should have a caption. This comes down to 
>>> accessibility requirements, where we are slowly raising the bar on 
>>> our docs, to be in accordance with Oracle's guidelines.
>>>
>>> Hiding the caption (style="display:none") is an interim measure we 
>>> have been using during the HTML 5 updates, especially in cases where 
>>> the person doing the markup changes did not know enough to create an 
>>> appropriate caption that should be displayed. In time, we should 
>>> locate and update all table captions (in our standard docs bundle) 
>>> that are not being displayed such that the text is both appropriate 
>>> and visible. If you guys want to do that as part of this update, go 
>>> ahead. FWIW, that is what we did for the java.xml module in the jaxp 
>>> repo ... pretty much all tables there now have a reasonable, visible 
>>> caption.
>>>
>>> -- Jon
>>>
>>>
>>>
>>> On 05/17/2017 11:19 AM, Phil Race wrote:
>>>> I am not sure we are using the summary in a way that makes it 
>>>> worthwhile.
>>>> As you noted in the other mail
>>>> "The summary attribute was used to give a more descriptive value
>>>> of the contents of the table.   A caption is more like a title"
>>>>
>>>> The values I see are more like a title and as you say that is not 
>>>> the idea. See the example here
>>>>
>>>> https://www.w3.org/TR/WCAG20-TECHS/H73.html
>>>>
>>>> Caption sounds like a title so it might actually be more 
>>>> appropriate than summary
>>>> for the text we have except that its not clear why we'd want it to 
>>>> be visible when we were fine without.
>>>>
>>>> But being there and invisible may be pointless unless screen 
>>>> readers look for it even if invisible.
>>>>
>>>> But if its not doing any harm I guess we can leave it as proposed
>>>>
>>>> I still need to look at the rest of the changes.
>>>>
>>>> -phil.
>>>>
>>>> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
>>>>> Sergey,
>>>>>
>>>>> FWIW, the invisible caption should be regarded as a temporary 
>>>>> solution, until content authors can review/update the text of the 
>>>>> caption and make it visible.
>>>>>
>>>>> The general guideline in this conversion work has been to avoid 
>>>>> changing the visible text of the specification, and captions fall 
>>>>> into a grey area of whether the text is significant/normative or 
>>>>> not.  Hence the temporary step to make them not displayed for now.
>>>>>
>>>>> -- Jon
>>>>>
>>>>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
>>>>>> The "summary" is unsupported by the HTML5 and we replace it by 
>>>>>> invisible caption.
>>>>>> These new styles are located in the stylesheet.css in the root of 
>>>>>> the JavaDoc api folder, so I assume these styles should be used 
>>>>>> by others as well.
>>>>>> They were added by this fix:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179479
>>>>>>
>>>>>> ----- philip.race at oracle.com wrote:
>>>>>>
>>>>>>> Does this in any way match the rest of the docs ? Or is everyone 
>>>>>>> left
>>>>>>> to
>>>>>>> style things how they want.
>>>>>>> I thought (?) maybe there is to be some javadoc tool support for 
>>>>>>> CSS
>>>>>>> styles.
>>>>>>>
>>>>>>> Also why are all the table summaries removed ?
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
>>>>>>>> This is because I use the same style for most of the tables
>>>>>>> 'class="striped"', which apply the same/unified style for 
>>>>>>> all(most) of
>>>>>>> our tables.
>>>>>>>> Also this is because I removed 'inlined' styles, like here:
>>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>>>>
>>>>>>>> ----- philip.race at oracle.com wrote:
>>>>>>>>
>>>>>>>>> Adding 2d-dev because a number of the files are 2D.
>>>>>>>>>
>>>>>>>>> What is the general reason for changing the appearance of the
>>>>>>> tables?
>>>>>>>>> -phil.
>>>>>>>>>
>>>>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
>>>>>>>>>> Hello,
>>>>>>>>>> Please review the fix for jdk9-dev.
>>>>>>>>>>
>>>>>>>>>> This fix is a part of the effort to make all javadoc in jdk9 be
>>>>>>>>> compatible to HTML5.
>>>>>>>>>> It covers all errors which are reported by the javadoc tool
>>>>>>> during
>>>>>>>>> the build of jdk for java.desktop module.
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
>>>>>>>>>> Webrev can be found at:
>>>>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
>>>>>>>>>> Note that an appearance of some tables were changed after the
>>>>>>> fix:
>>>>>>>>>> Before:
>>>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html 
>>>>>>>
>>>>>>>>>> After:
>>>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html 
>>>>>>>
>>>>>>>>>> Before:
>>>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html 
>>>>>>>
>>>>>>>>>> After :
>>>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html 
>>>>>>>
>>>>>>>>>> Before:
>>>>>>> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html 
>>>>>>>
>>>>>>>>>> After:
>>>>>>> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html 
>>>>>>>
>>>>>
>>>>
>>>
>>
>


From prasanta.sadhukhan at oracle.com  Thu May 18 10:32:13 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 18 May 2017 16:02:13 +0530
Subject: [OpenJDK 2D-Dev] RFR: 8177393: Result of RescaleOp for
 4BYTE_ABGR images may be 25% black
In-Reply-To: <94ab2091-34f8-90da-0d4d-f322ff659159@oracle.com>
References: <94ab2091-34f8-90da-0d4d-f322ff659159@oracle.com>
Message-ID: <66089a18-dd70-4280-0645-7809f368dfb0@oracle.com>

Looks good to me. [Checked 8080287 also works ok with this change]

Regards
Prasanta
On 5/17/2017 11:14 PM, Phil Race wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177393
> Webrev: http://cr.openjdk.java.net/~prr/8177393/
>
> I have updated the bug report with a long evaluation and some additional
> explanation of the proposed fix. I don't intend to duplicate all that here
> so please go read it there. The following is a much briefer summary.
>
> We are ending up in medialib native code that cannot interpret the 
> Java 2D child raster
> it is handed. The child raster was an attempt to prevent rescaling of 
> the alpha channel.
>
> The proposed fix avoids creating that child raster and instead creates 
> a LookupOp
> which has an explicit lookup table for the alpha channel that does the 
> identity lookup.
>
> The fix has a couple of other updates.
> (1) the "canUseLookupOp()" method now checks that the DataBuffer is
> something that the medialib code used by LookupOp can handle.
> This would have fixed the bug by itself although at the expense of always
> falling back to slow Java code in RescaleOp. However it is still needed in
> case the application itself supplies a child raster.
>
> (2) The slow path in RescaleOp turns out to have the same bug that I think
> was seen in some other bug report or fix. It is always re-scaling alpha as
> well as colour components. I fixed that too.
>
> Since the fix is entirely confined to RescaleOp any consequences - 
> good or bad - are limited.
>
> I ran the few regression tests we have that cover RescaleOp and also 
> checked Java2Ddemo.
>
> The commented out cases in the new regression test are to be handled 
> under a different bug ID.
>
> -phil.

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

From sergey.bylokhov at oracle.com  Thu May 18 21:48:39 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 18 May 2017 14:48:39 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review Request: 8180326 Update
 the tables in java.desktop to be HTML-5 friendly
Message-ID: <541766fe-bd76-487f-9d4d-946cd87906c5@default>

Hello.
Here is an updated version where most of the caption are visible.
Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
Webrev can be found at: http://cr.openjdk.java.net/~serb/8180326/webrev.02/
Specdiff: http://cr.openjdk.java.net/~serb/8180326/specdiff.02/overview-summary.html

You can use search to check the changes in some specific class:
Old docs: http://cr.openjdk.java.net/~serb/8180326/api_old.02/overview-summary.html
New docs: http://cr.openjdk.java.net/~serb/8180326/api.02/overview-summary.html


----- jonathan.gibbons at oracle.com wrote:

> Phil,
> 
> I have no evidence one way or the other whether screen readers pay 
> attention
> to undisplayed or invisible captions. It seemed safest to assume that
> 
> they would
> read a visible caption, and that we should head in that general
> direction.
> 
> -- Jon
> 
> 
> On 05/17/2017 11:58 AM, Phil Race wrote:
> > And PS I was not saying anything to contradict
> > > tables should not have a summary attribute and should have a
> caption.
> >
> > However that the docs I read on the web did seem to imply that
> > summary was very much intended for ATs but it was not at all clear
> this
> > is the point of caption. I'm sure they can read it, but I don't get
> 
> > how making
> > it visible matters to them so how it making it visible relates to 
> > accessibility
> > requirements is not an obvious connection to me. So why do we have
> > to make it visible for ATs ?
> >
> > -phil.
> >
> > On 05/17/2017 11:54 AM, Phil Race wrote:
> >> I will leave the decision on whether to do that now up to Sergey 
> >> although
> >> it seems all he has to do here is remove "invisible".
> >> Many of the "summary" ones had wrong or misleading text but they
> >> seem to have been all fixed.
> >>
> >> I'd want to see what the new HTML looks like with a visible title
> of 
> >> course ..
> >>
> >> -phil.
> >>
> >> On 05/17/2017 11:52 AM, Jonathan Gibbons wrote:
> >>> Phil,
> >>>
> >>> The bottom line is that in the JDK docs, tables should not have a
> 
> >>> summary attribute and should have a caption. This comes down to 
> >>> accessibility requirements, where we are slowly raising the bar on
> 
> >>> our docs, to be in accordance with Oracle's guidelines.
> >>>
> >>> Hiding the caption (style="display:none") is an interim measure we
> 
> >>> have been using during the HTML 5 updates, especially in cases
> where 
> >>> the person doing the markup changes did not know enough to create
> an 
> >>> appropriate caption that should be displayed. In time, we should 
> >>> locate and update all table captions (in our standard docs bundle)
> 
> >>> that are not being displayed such that the text is both
> appropriate 
> >>> and visible. If you guys want to do that as part of this update,
> go 
> >>> ahead. FWIW, that is what we did for the java.xml module in the
> jaxp 
> >>> repo ... pretty much all tables there now have a reasonable,
> visible 
> >>> caption.
> >>>
> >>> -- Jon
> >>>
> >>>
> >>>
> >>> On 05/17/2017 11:19 AM, Phil Race wrote:
> >>>> I am not sure we are using the summary in a way that makes it 
> >>>> worthwhile.
> >>>> As you noted in the other mail
> >>>> "The summary attribute was used to give a more descriptive value
> >>>> of the contents of the table.   A caption is more like a title"
> >>>>
> >>>> The values I see are more like a title and as you say that is not
> 
> >>>> the idea. See the example here
> >>>>
> >>>> https://www.w3.org/TR/WCAG20-TECHS/H73.html
> >>>>
> >>>> Caption sounds like a title so it might actually be more 
> >>>> appropriate than summary
> >>>> for the text we have except that its not clear why we'd want it
> to 
> >>>> be visible when we were fine without.
> >>>>
> >>>> But being there and invisible may be pointless unless screen 
> >>>> readers look for it even if invisible.
> >>>>
> >>>> But if its not doing any harm I guess we can leave it as
> proposed
> >>>>
> >>>> I still need to look at the rest of the changes.
> >>>>
> >>>> -phil.
> >>>>
> >>>> On 05/12/2017 05:11 PM, Jonathan Gibbons wrote:
> >>>>> Sergey,
> >>>>>
> >>>>> FWIW, the invisible caption should be regarded as a temporary 
> >>>>> solution, until content authors can review/update the text of
> the 
> >>>>> caption and make it visible.
> >>>>>
> >>>>> The general guideline in this conversion work has been to avoid
> 
> >>>>> changing the visible text of the specification, and captions
> fall 
> >>>>> into a grey area of whether the text is significant/normative or
> 
> >>>>> not.  Hence the temporary step to make them not displayed for
> now.
> >>>>>
> >>>>> -- Jon
> >>>>>
> >>>>> On 05/12/2017 05:00 PM, Sergey Bylokhov wrote:
> >>>>>> The "summary" is unsupported by the HTML5 and we replace it by
> 
> >>>>>> invisible caption.
> >>>>>> These new styles are located in the stylesheet.css in the root
> of 
> >>>>>> the JavaDoc api folder, so I assume these styles should be used
> 
> >>>>>> by others as well.
> >>>>>> They were added by this fix:
> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8179479
> >>>>>>
> >>>>>> ----- philip.race at oracle.com wrote:
> >>>>>>
> >>>>>>> Does this in any way match the rest of the docs ? Or is
> everyone 
> >>>>>>> left
> >>>>>>> to
> >>>>>>> style things how they want.
> >>>>>>> I thought (?) maybe there is to be some javadoc tool support
> for 
> >>>>>>> CSS
> >>>>>>> styles.
> >>>>>>>
> >>>>>>> Also why are all the table summaries removed ?
> >>>>>>>
> >>>>>>> -phil.
> >>>>>>>
> >>>>>>> On 5/12/17, 4:52 PM, Sergey Bylokhov wrote:
> >>>>>>>> This is because I use the same style for most of the tables
> >>>>>>> 'class="striped"', which apply the same/unified style for 
> >>>>>>> all(most) of
> >>>>>>> our tables.
> >>>>>>>> Also this is because I removed 'inlined' styles, like here:
> >>>>>>>>
> >>>>>>>
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
> 
> >>>>>>>
> >>>>>>>> ----- philip.race at oracle.com wrote:
> >>>>>>>>
> >>>>>>>>> Adding 2d-dev because a number of the files are 2D.
> >>>>>>>>>
> >>>>>>>>> What is the general reason for changing the appearance of
> the
> >>>>>>> tables?
> >>>>>>>>> -phil.
> >>>>>>>>>
> >>>>>>>>> On 5/12/17, 4:25 PM, Sergey Bylokhov wrote:
> >>>>>>>>>> Hello,
> >>>>>>>>>> Please review the fix for jdk9-dev.
> >>>>>>>>>>
> >>>>>>>>>> This fix is a part of the effort to make all javadoc in
> jdk9 be
> >>>>>>>>> compatible to HTML5.
> >>>>>>>>>> It covers all errors which are reported by the javadoc
> tool
> >>>>>>> during
> >>>>>>>>> the build of jdk for java.desktop module.
> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180326
> >>>>>>>>>> Webrev can be found at:
> >>>>>>>>> http://cr.openjdk.java.net/~serb/8180326/webrev.01
> >>>>>>>>>> Note that an appearance of some tables were changed after
> the
> >>>>>>> fix:
> >>>>>>>>>> Before:
> >>>>>>>
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/java/awt/font/TextAttribute.html
> 
> >>>>>>>
> >>>>>>>>>> After:
> >>>>>>>
> http://cr.openjdk.java.net/~serb/8180326/api.01/java/awt/font/TextAttribute.html
> 
> >>>>>>>
> >>>>>>>>>> Before:
> >>>>>>>
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioSystem.html
> 
> >>>>>>>
> >>>>>>>>>> After :
> >>>>>>>
> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioSystem.html
> 
> >>>>>>>
> >>>>>>>>>> Before:
> >>>>>>>
> http://cr.openjdk.java.net/~serb/8180326/api_old.01/javax/sound/sampled/AudioPermission.html
> 
> >>>>>>>
> >>>>>>>>>> After:
> >>>>>>>
> http://cr.openjdk.java.net/~serb/8180326/api.01/javax/sound/sampled/AudioPermission.html
> 
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >

From philip.race at oracle.com  Fri May 19 05:50:42 2017
From: philip.race at oracle.com (Philip Race)
Date: Thu, 18 May 2017 22:50:42 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8177393: Result of RescaleOp for
 4BYTE_ABGR images may be 25% black
In-Reply-To: <66089a18-dd70-4280-0645-7809f368dfb0@oracle.com>
References: <94ab2091-34f8-90da-0d4d-f322ff659159@oracle.com>
 <66089a18-dd70-4280-0645-7809f368dfb0@oracle.com>
Message-ID: <591E87B2.7010806@oracle.com>

Some review discussion with Jim is in the bug report comments.

Updated webrev to address the minimal set of issues :
http://cr.openjdk.java.net/~prr/8177393.1/

-phil.

On 5/18/17, 3:32 AM, Prasanta Sadhukhan wrote:
>
> Looks good to me. [Checked 8080287 also works ok with this change]
>
> Regards
> Prasanta
> On 5/17/2017 11:14 PM, Phil Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177393
>> Webrev: http://cr.openjdk.java.net/~prr/8177393/
>>
>> I have updated the bug report with a long evaluation and some additional
>> explanation of the proposed fix. I don't intend to duplicate all that 
>> here
>> so please go read it there. The following is a much briefer summary.
>>
>> We are ending up in medialib native code that cannot interpret the 
>> Java 2D child raster
>> it is handed. The child raster was an attempt to prevent rescaling of 
>> the alpha channel.
>>
>> The proposed fix avoids creating that child raster and instead 
>> creates a LookupOp
>> which has an explicit lookup table for the alpha channel that does 
>> the identity lookup.
>>
>> The fix has a couple of other updates.
>> (1) the "canUseLookupOp()" method now checks that the DataBuffer is
>> something that the medialib code used by LookupOp can handle.
>> This would have fixed the bug by itself although at the expense of always
>> falling back to slow Java code in RescaleOp. However it is still 
>> needed in
>> case the application itself supplies a child raster.
>>
>> (2) The slow path in RescaleOp turns out to have the same bug that I 
>> think
>> was seen in some other bug report or fix. It is always re-scaling 
>> alpha as
>> well as colour components. I fixed that too.
>>
>> Since the fix is entirely confined to RescaleOp any consequences - 
>> good or bad - are limited.
>>
>> I ran the few regression tests we have that cover RescaleOp and also 
>> checked Java2Ddemo.
>>
>> The commented out cases in the new regression test are to be handled 
>> under a different bug ID.
>>
>> -phil.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170518/fa1090ab/attachment.html>

From sergey.bylokhov at oracle.com  Sat May 20 02:21:27 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 19 May 2017 19:21:27 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8177628 Opensource
 unit/regression tests for ImageIO
Message-ID: <f043a2b8-eaa3-4e9a-b900-adf9954688c7@default>

Hello,
Please review the fix for jdk9.

This fix is a part of the effort to opensource the tests in jdk.
In the fix a number of tests for ImageIO are moved to the open ws.
Note that most of the code moved as-is, and probably can be improved in the future, but I tried to limit the number of changes in this move.

Bug: https://bugs.openjdk.java.net/browse/JDK-8177628
Webrev can be found at: http://cr.openjdk.java.net/~serb/8177628/webrev.00
The same fix for JavaSound: http://mail.openjdk.java.net/pipermail/sound-dev/2016-October/000472.html

From prahalad.kumar.narayanan at oracle.com  Mon May 22 11:23:09 2017
From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan)
Date: Mon, 22 May 2017 04:23:09 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8177628 Opensource
 unit/regression tests for ImageIO
In-Reply-To: <f043a2b8-eaa3-4e9a-b900-adf9954688c7@default>
References: <f043a2b8-eaa3-4e9a-b900-adf9954688c7@default>
Message-ID: <e1b22380-e8e0-4c69-bd93-532c43a6735e@default>

Hello Sergey

The patch looks good to me. 
    . I imported the patch and executed automated jtreg tests.
    . No failures were noticed on win64 build.

One subtle observation
    . One of the test cases- DestTypeTest.java, seems to require VancouverIsland200.jpg.
    . Since the file is looked up in a try ... catch block, the test will continue to execute despite image not being a part of the patch.
    . You could check this test code & copyrights for the image just to ensure the intended functionality is tested.

Thanks
Have a good day

Prahalad N.

-----Original Message-----
From: Sergey Bylokhov 
Sent: Saturday, May 20, 2017 7:51 AM
To: Jayathirth D V; Philip R Race
Cc: 2d-Dev
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8177628 Opensource unit/regression tests for ImageIO

Hello,
Please review the fix for jdk9.

This fix is a part of the effort to opensource the tests in jdk.
In the fix a number of tests for ImageIO are moved to the open ws.
Note that most of the code moved as-is, and probably can be improved in the future, but I tried to limit the number of changes in this move.

Bug: https://bugs.openjdk.java.net/browse/JDK-8177628
Webrev can be found at: http://cr.openjdk.java.net/~serb/8177628/webrev.00
The same fix for JavaSound: http://mail.openjdk.java.net/pipermail/sound-dev/2016-October/000472.html

From sergey.bylokhov at oracle.com  Mon May 22 21:46:17 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 22 May 2017 14:46:17 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8177628 Opensource
 unit/regression tests for ImageIO
Message-ID: <41a06cb1-e0fc-420d-b152-0bc1160987c0@default>

Hi, Prahalad.
Thank you for review.
Yes, this image(if found) is used to initialize the BImage, but the test can generates BImage on its own.
In the new version the usage of ".jpg" is removed:
http://cr.openjdk.java.net/~serb/8177628/webrev.01

I have checked that the test fails on jdk5 where related bug was not fixed.

----- prahalad.kumar.narayanan at oracle.com wrote:

> Hello Sergey
> 
> The patch looks good to me. 
>     . I imported the patch and executed automated jtreg tests.
>     . No failures were noticed on win64 build.
> 
> One subtle observation
>     . One of the test cases- DestTypeTest.java, seems to require
> VancouverIsland200.jpg.
>     . Since the file is looked up in a try ... catch block, the test
> will continue to execute despite image not being a part of the patch.
>     . You could check this test code & copyrights for the image just
> to ensure the intended functionality is tested.
> 
> Thanks
> Have a good day
> 
> Prahalad N.
> 
> -----Original Message-----
> From: Sergey Bylokhov 
> Sent: Saturday, May 20, 2017 7:51 AM
> To: Jayathirth D V; Philip R Race
> Cc: 2d-Dev
> Subject: [OpenJDK 2D-Dev] [9] Review Request: 8177628 Opensource
> unit/regression tests for ImageIO
> 
> Hello,
> Please review the fix for jdk9.
> 
> This fix is a part of the effort to opensource the tests in jdk.
> In the fix a number of tests for ImageIO are moved to the open ws.
> Note that most of the code moved as-is, and probably can be improved
> in the future, but I tried to limit the number of changes in this
> move.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177628
> Webrev can be found at:
> http://cr.openjdk.java.net/~serb/8177628/webrev.00
> The same fix for JavaSound:
> http://mail.openjdk.java.net/pipermail/sound-dev/2016-October/000472.html

From philip.race at oracle.com  Mon May 22 22:22:12 2017
From: philip.race at oracle.com (Phil Race)
Date: Mon, 22 May 2017 15:22:12 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8177628 Opensource
 unit/regression tests for ImageIO
In-Reply-To: <41a06cb1-e0fc-420d-b152-0bc1160987c0@default>
References: <41a06cb1-e0fc-420d-b152-0bc1160987c0@default>
Message-ID: <b237c1cb-e9a6-acd5-59a0-21ed3805e978@oracle.com>

+1

-phil.

On 05/22/2017 02:46 PM, Sergey Bylokhov wrote:
> Hi, Prahalad.
> Thank you for review.
> Yes, this image(if found) is used to initialize the BImage, but the test can generates BImage on its own.
> In the new version the usage of ".jpg" is removed:
> http://cr.openjdk.java.net/~serb/8177628/webrev.01
>
> I have checked that the test fails on jdk5 where related bug was not fixed.
>
> ----- prahalad.kumar.narayanan at oracle.com wrote:
>
>> Hello Sergey
>>
>> The patch looks good to me.
>>      . I imported the patch and executed automated jtreg tests.
>>      . No failures were noticed on win64 build.
>>
>> One subtle observation
>>      . One of the test cases- DestTypeTest.java, seems to require
>> VancouverIsland200.jpg.
>>      . Since the file is looked up in a try ... catch block, the test
>> will continue to execute despite image not being a part of the patch.
>>      . You could check this test code & copyrights for the image just
>> to ensure the intended functionality is tested.
>>
>> Thanks
>> Have a good day
>>
>> Prahalad N.
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Saturday, May 20, 2017 7:51 AM
>> To: Jayathirth D V; Philip R Race
>> Cc: 2d-Dev
>> Subject: [OpenJDK 2D-Dev] [9] Review Request: 8177628 Opensource
>> unit/regression tests for ImageIO
>>
>> Hello,
>> Please review the fix for jdk9.
>>
>> This fix is a part of the effort to opensource the tests in jdk.
>> In the fix a number of tests for ImageIO are moved to the open ws.
>> Note that most of the code moved as-is, and probably can be improved
>> in the future, but I tried to limit the number of changes in this
>> move.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177628
>> Webrev can be found at:
>> http://cr.openjdk.java.net/~serb/8177628/webrev.00
>> The same fix for JavaSound:
>> http://mail.openjdk.java.net/pipermail/sound-dev/2016-October/000472.html


From prahalad.kumar.narayanan at oracle.com  Tue May 23 01:54:25 2017
From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan)
Date: Mon, 22 May 2017 18:54:25 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8177628 Opensource
 unit/regression tests for ImageIO
In-Reply-To: <41a06cb1-e0fc-420d-b152-0bc1160987c0@default>
References: <41a06cb1-e0fc-420d-b152-0bc1160987c0@default>
Message-ID: <f83b757a-7129-45ca-a0e9-f531c3033a62@default>

Hello Sergey

The changes look good.

Thanks
Have a good day

Prahalad N.

-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, May 23, 2017 3:16 AM
To: Prahalad Kumar Narayanan
Cc: Jayathirth D V; 2d-dev at openjdk.java.net; Philip Race
Subject: Re: [OpenJDK 2D-Dev] [9] Review Request: 8177628 Opensource unit/regression tests for ImageIO

Hi, Prahalad.
Thank you for review.
Yes, this image(if found) is used to initialize the BImage, but the test can generates BImage on its own.
In the new version the usage of ".jpg" is removed:
http://cr.openjdk.java.net/~serb/8177628/webrev.01

I have checked that the test fails on jdk5 where related bug was not fixed.

----- prahalad.kumar.narayanan at oracle.com wrote:

> Hello Sergey
> 
> The patch looks good to me. 
>     . I imported the patch and executed automated jtreg tests.
>     . No failures were noticed on win64 build.
> 
> One subtle observation
>     . One of the test cases- DestTypeTest.java, seems to require 
> VancouverIsland200.jpg.
>     . Since the file is looked up in a try ... catch block, the test 
> will continue to execute despite image not being a part of the patch.
>     . You could check this test code & copyrights for the image just 
> to ensure the intended functionality is tested.
> 
> Thanks
> Have a good day
> 
> Prahalad N.
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Saturday, May 20, 2017 7:51 AM
> To: Jayathirth D V; Philip R Race
> Cc: 2d-Dev
> Subject: [OpenJDK 2D-Dev] [9] Review Request: 8177628 Opensource 
> unit/regression tests for ImageIO
> 
> Hello,
> Please review the fix for jdk9.
> 
> This fix is a part of the effort to opensource the tests in jdk.
> In the fix a number of tests for ImageIO are moved to the open ws.
> Note that most of the code moved as-is, and probably can be improved 
> in the future, but I tried to limit the number of changes in this 
> move.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177628
> Webrev can be found at:
> http://cr.openjdk.java.net/~serb/8177628/webrev.00
> The same fix for JavaSound:
> http://mail.openjdk.java.net/pipermail/sound-dev/2016-October/000472.h
> tml

From philip.race at oracle.com  Tue May 23 19:18:53 2017
From: philip.race at oracle.com (Phil Race)
Date: Tue, 23 May 2017 12:18:53 -0700
Subject: [OpenJDK 2D-Dev] Result: New 2D Group Member: Laurent Bourges
Message-ID: <c0e7184c-a9dd-2186-8a1f-d1b832040b11@oracle.com>

The vote for Laurent Bourges [1] is now closed.

Yes: 3
Veto: 0
Abstain: 0

According to the OpenJDK Bylaws definition of Lazy Consensus [2],
this is sufficient to approve the nomination.

-phil.

[1] http://mail.openjdk.java.net/pipermail/2d-dev/2017-May/008327.html
[2] http://openjdk.java.net/bylaws#lazy-consensus


From sergey.bylokhov at oracle.com  Mon May 29 21:48:03 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 29 May 2017 14:48:03 -0700 (PDT)
Subject: [OpenJDK 2D-Dev] <AWT Dev> Safe to take Base64 encoded image
	from client?
Message-ID: <39b4f079-3d3f-4f13-a7e0-0ea1d39aef06@default>

Hi,
The question is related to Java2D API and 2d-dev (cc).

----- timo.vander.schuit at globalrelay.net wrote:

> Hi,
> 
> The front-end generates a base64 encoded image of a graph and send it
> to the backend to use it with pdfbox to create a pdf file.
> Are there any security concerns with in particular this line
> "BufferedImage bufImg = ImageIO.read(new
> ByteArrayInputStream(imageByte));
> ??
> 
> @POST
> @Consumes(MediaType.APPLICATION_JSON)
> @Path("/pdfbox")
> public void getChartsPdf(String base64ImageData) throws IOException{
> 
>     PDDocument doc = null;
>     byte[] imageByte;
>     String base64Image = base64ImageData.split(",")[1];
>     BASE64Decoder decoder = new BASE64Decoder();
>     imageByte = decoder.decodeBuffer(base64Image);
>     try {
>         doc = new PDDocument();
>         PDPage page = new PDPage();
>         doc.addPage(page);
>         PDFont font = PDType1Font.HELVETICA_BOLD;
>         PDPageContentStream contentStream = new
> PDPageContentStream(doc, page);
> 
>         BufferedImage bufImg = ImageIO.read(new
> ByteArrayInputStream(imageByte));
>         PDXObjectImage ximage = new PDPixelMap(doc, bufImg);
> 
>         contentStream.beginText();
>         contentStream.setFont( font, 12 );
>         contentStream.moveTextPositionByAmount( 50, 700 );
>         contentStream.drawString("Timeline");
>         contentStream.endText();
>         contentStream.drawXObject(ximage, 20, 500,
> ximage.getWidth()/2, ximage.getHeight()/2);
>         contentStream.close();
>         doc.save("testCharts.pdf");
>     } catch (Exception e) {
>         System.err.println(e.getMessage());
>     } finally {
>         if (doc != null) {
>             doc.close();
>         }
>     }
> }
> 
> Regards,
> 
> Timo

From philip.race at oracle.com  Tue May 30 14:07:52 2017
From: philip.race at oracle.com (Philip Race)
Date: Tue, 30 May 2017 07:07:52 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> Safe to take Base64 encoded image
 from client?
In-Reply-To: <39b4f079-3d3f-4f13-a7e0-0ea1d39aef06@default>
References: <39b4f079-3d3f-4f13-a7e0-0ea1d39aef06@default>
Message-ID: <592D7CB8.7010500@oracle.com>

 From a JDK perspective you need to make sure you run with the
latest secure baseline update for your version : for more info see
http://www.oracle.com/technetwork/java/javase/overview/security-2043272.html

The rest is application architecture for which I don't think we can or 
should give advice.
This is not a support channel. These lists are for people contributing 
source code to OpenJDK.

-phil.

On 5/29/17, 2:48 PM, Sergey Bylokhov wrote:
> Hi,
> The question is related to Java2D API and 2d-dev (cc).
>
> ----- timo.vander.schuit at globalrelay.net wrote:
>
>> Hi,
>>
>> The front-end generates a base64 encoded image of a graph and send it
>> to the backend to use it with pdfbox to create a pdf file.
>> Are there any security concerns with in particular this line
>> "BufferedImage bufImg = ImageIO.read(new
>> ByteArrayInputStream(imageByte));
>> ??
>>
>> @POST
>> @Consumes(MediaType.APPLICATION_JSON)
>> @Path("/pdfbox")
>> public void getChartsPdf(String base64ImageData) throws IOException{
>>
>>      PDDocument doc = null;
>>      byte[] imageByte;
>>      String base64Image = base64ImageData.split(",")[1];
>>      BASE64Decoder decoder = new BASE64Decoder();
>>      imageByte = decoder.decodeBuffer(base64Image);
>>      try {
>>          doc = new PDDocument();
>>          PDPage page = new PDPage();
>>          doc.addPage(page);
>>          PDFont font = PDType1Font.HELVETICA_BOLD;
>>          PDPageContentStream contentStream = new
>> PDPageContentStream(doc, page);
>>
>>          BufferedImage bufImg = ImageIO.read(new
>> ByteArrayInputStream(imageByte));
>>          PDXObjectImage ximage = new PDPixelMap(doc, bufImg);
>>
>>          contentStream.beginText();
>>          contentStream.setFont( font, 12 );
>>          contentStream.moveTextPositionByAmount( 50, 700 );
>>          contentStream.drawString("Timeline");
>>          contentStream.endText();
>>          contentStream.drawXObject(ximage, 20, 500,
>> ximage.getWidth()/2, ximage.getHeight()/2);
>>          contentStream.close();
>>          doc.save("testCharts.pdf");
>>      } catch (Exception e) {
>>          System.err.println(e.getMessage());
>>      } finally {
>>          if (doc != null) {
>>              doc.close();
>>          }
>>      }
>> }
>>
>> Regards,
>>
>> Timo