[OpenJDK 2D-Dev] [10] Marlin2D upgrade 0.7.5

[Laurent Bourgès]

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>