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
