[OpenJDK Rasterizer] Marlin #4

Laurent Bourgès bourges.laurent at gmail.com
Mon Nov 23 17:02:27 UTC 2015


Jim,

Here are few answers to several questions during last friday's sprint:


> I ran a bunch of tests on 4.2 and saw no issues and the performance looked
> good.  There were still some things that Ductus was faster on, but I just
> did a brief run of a few tests I cobbled together so I don't know how
> representative they are.  Marlin beat Ductus on a number of tests as well,
> so they are right there fighting neck and neck.  I was using the defaults
> which have the RLE code turned off I believe, so maybe I wasn't running it
> in its fastest configuration?
>

I tested your last Marlin patch (4.3+) as it is now in the GR repository:
with default settings, it works well and is as fast as usual.

I know that Marlin is slightly slower than ductus for shape size ~ 20:
Ductus seems using 16x16 blocks whereas Marlin uses 32x32 tiles so the new
RLE approach is not in use (raw encoding) i.e. lots of zero-fill / array
copy operations.

Maybe I could evaluate later if using inlined array cleanup (alphaRow) may
be faster when the ratio (alpha values != 0) ~ width / mean_num_crossing is
high.

Finally Marlin has still a disavantage: it does not perform shape clipping
in contrary to ductus = it's a remaining TODO.



> I'm code reading now:
>
> ArrayCache.java, line 205 - should that be needSize there?  Also, should
> these tests be > or >=?
>

I wanted to limit the size to 2M (Integer.MAX_VALUE) but it wanted 2
passes: first, return 2M, then if more needed, fail !
If prefer using >= to be simpler ie always check the current size.


> MarlinCache.java, line 181 - in the comment, shouldn't those be maxx and
> minx?
>

Yes, to be fixed.


>
> Renderer.java, line 1446 - initial value of useBlkFlags will be false if
> heuristics is enabled
> Renderer.java, line 1329 - we send a row to the cache before we update
> heuristics at line 1332
> - taken together that means that with heuristics the very first cache line
> sent out will always be non-RLE?
>

You're right:
In my first tests, I was testing every scanline but it was costly (8x more
tests but always clean blkFlags when used).
Now I only check 1/8th scanlines ie once per pixel row as it is roughly
"continuous" (maybe false positive) and it implies the very first row is
always non RLE encoded.


Comments on Marlin logs:

- turning off Marlin logging
>
>>
>> static final boolean enableLogs = false;
>>    34     // enable Logger
>>    35     static final boolean useLogger = enableLogs &&
>> MarlinProperties.isUseLogger();
>>
>> So the only way to enable logging is to edit this file and rebuild ?
>>
>
> From what I saw in the files, enableLogs basically turns everything off
> and causes a lot of code to be compiled out of the files due to there being
> static final boolean constants that evaluate to false.
>

Exactly: if logs are disabled (production), then all debug / log flags are
set to false (doStats ...)


>
> Once enableLogs is on, isUseLogging controls whether it goes to a log file
> or just prints to System.out.
>
> Also, there are other static booleans turn on and off different pieces of
> the logging at a finer granularity.  The only logging that was happening
> without being wrapped by a "if (doFooLogging)" conditional were the
> logInfos that executed when the RE was initialized.  I suppose those could
> have been neutered with a different "doStartupInfo" boolean, but I figured
> I would turn them all off by default for now.
>
> We can enable runtime-logging later on if we find a decent way to have it
> be low impact when not runtime-enabled...
>

(I deliberately disabled doMonitors and doChecks (for performance reasons))


However I would prefer having enableLogs = true if the renderer is in
verbose mode: "  -Dsun.java2d.renderer.verbose=true".

So it would display the startup informations in this case (including tuning
settings ...) and it would allow gathering Marlin statistics (if doStats =
true).

Moreover, I should refactor j.u.l.Logger usage by PlatformLogger (TODO) and
we should rename all Marlin System properties to use the prefix "
sun.java2d.marlin..."

What do you think ?


Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/graphics-rasterizer-dev/attachments/20151123/3d8e58f7/attachment.html>


More information about the graphics-rasterizer-dev mailing list