Before we come to any conclusions on performance, though, we might want to run this on something like a Microsoft
Surface that uses a mobile processor (m3 in the low end) that might not perform as well with doubles. Does anyone have
a low-end Surface they could try these patches on and see how t
If this eliminates the regressions in TestNonAA, then I'm for reworking this as
an in-place patch for MarlinFX.
We can't use the existing Dasher bug for this because Marlin isn't the default renderer, but we can mention the
DMarlinFX bug as a workaround for the Dasher bug...
One thing that might cause a problem is that the script modified ERR_STEP_MAX because it had 7f, but it was 0x7f, not
1.7f. Some other constants might be affected as well...
...jim
On 11/30/16 2:12 PM, Laurent Bourgès wrote:
- TestNonAARasterization: the errors seem ar
Jim,
I found the bug in RendererNoAA caused by a 'bad' regexp match:
0x7fff was modified to 0x7Dff !
so there is no more regression in TestNonAARasterization !
Laurent
FYI, here is the diff of the correction (over the previous big patches):
< +++
new/modules/javafx.graphics/src/main/j
Jim,
As announced yesterday night, I made a new 'Double' (alias D) pipeline for
marlinFX with 2 webrevs:
- cmp that compares the D pipeline vs the float pipeline:
http://cr.openjdk.java.net/~lbourges/marlinFX-D/marlinFX-Double-cmp/
- raw that makes no comparison to be easily applicable as a patch:
Hi again,
As I wanted to use double precision for long, I ported main marlinFX
classes using a tricky sed scripts... fixed the 'D' pipeline and it seems
already working well.
The 2 mentioned bugs are then fixed + the performance ob DemoFX / GUIMark
(webview) seems the same as the hot spot is in s
Hi,
For large curves, I would recommend using a first step to subdivide the
curve into smaller ones (1024 pixels as described in Lien paper) to ensure
the AFD algorithm preserves enough accuracy with float values (first) in
the Dasher.
Basic recursive subdivision at halves with a large flatness t
Am 29.11.16 um 01:09 schrieb Jim Graham:
With respect to float/double, I have another bug somewhere where we
have a large inaccuracy for a very large circle that intersects the
viewing area along only a very tiny portion. The errors get
especially bad with dashing because we iterate each das
Hi Laurent,
I think you've looked into the issues of flatness and how inflection points affect it about as much as I have at this
point. I'm not sure that sub-dividing at min/max values helps filling, but a way to subdivide at inflection points
might improve the flattening algorithm. It's wor
Jim,
There is one thing I think you should look at, though, and I wasn't sure if
> I should file a bug. If you've downloaded the Rasterization verifier from
> the old JBS bug for non-AA rendering, try running it with the 4quads mode
> (-quad argument I think). It looks like it averages slightly
10 matches
Mail list logo
