JDK-8274066 : Polygon filled outside its area when very large coordinates are used
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: jfx11,jfx17
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2021-09-21
  • Updated: 2023-09-22
  • Resolved: 2022-09-19
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
Rendering a filled polygon that includes vertices with very large coordinates results in drawing glitches as the viewed area approaches those high coordinates: the fill is sometimes drawn outside the polygon, or partly outside and partly inside. 

The attached test case can be used to reproduce the issue on any platform (Linux, Mac and Windows), with any output scale (DPI 1.0, 1.5 or 2.0), and with any JavaFX version from 11, 17 or head.

There is a maximum value for the X coordinate that works as expected (see PolygonGood.png):

DPI 1.0 -> 4194304.250 + scene width
DPI 2.0 -> 4194304.250/2.0 + scene width

However, by simply adding 0.001 to it (or any other greater value):

DPI 1.0 -> 4194304.250 + scene width + 0.001
DPI 2.0 -> 4194304.250/2.0 + scene width + 0.001

then it fails (see PolygonBad.png): the polygon fill is shown outside the polygon itself. 

It doesn't depend on the Y coordinate (which can be as big as the X one), so it is not related to the bad form factor of the shape.

It does depend on the screen output scale, the scene width or the translate coordinates that are used to see the end of the polygon, though.
Comments
I verified that this is fixed by the Marlin 0.9.4.6 update. Closing as a duplicate of JDK-8287604.
19-09-2022

Adding the "regression" label and raising to P3, since this is a regression introduced in JavaFX 11.
07-01-2022

This bug in the Marlin-renderer for java FX (11+) is also present in the Marlin-renderer for java 2D (11+); should we open another java2d ticket ?
15-12-2021

Yes, please open another bug for java2d.
15-12-2021

When is JFX18 RDP0 ? I can propose the Marlin 0.9.4.5 PR that fixes this bug already, but I am still improving small aspects. Who will have time for review ? See draft: https://github.com/openjdk/jfx/pull/674
02-12-2021

Do you mean RDP1 (there is no "RDP0" milestone)? Jan 13, 2022. The JavaFX 18 schedule is posted here [1]. [1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-November/032657.html I can be a reviewer.
02-12-2021

Please try this new MarlinFX 0.9.4.5 release providing this bug fix: https://github.com/bourgesl/marlin-fx/releases/tag/v0.9.4.5 I will propose an OpenJFX patch soon.
30-10-2021

I fixed the Filler and now ClipShapeTest passed with numTests=50000, so code coverage and difficult cases are all fixed now with the new path clipper (filler case). See my fix: https://github.com/bourgesl/marlin-fx/commit/0347aa7d33ecde1bc51aa212d37697f882eadb10 It will take me some time to merge my branches with up-todate openjfx but I hope soon.
22-10-2021

FYI I am working on this problem: - 100% of Marlin's ClipPathTest Stroke tests are passing - 99.9% of Marlin's ClipPathTest Fill tests are passing now : only 10 cases / 5000 are still buggy. I hope to fix the remaining cases asap. - with coords > 1E15, the curve splitter is facing the numerical precision wall: it could be improved later to ensure intersections with the clip are outside using few ulps() more or less...
21-10-2021

FYI I tested the Stroker with your test and fixed 1 bug in closePath() when the origin was very far (~1E9) with your wide polygon inverted: it is now properly clipped. I will look then at the filler case: I think moveTo() and closePath() emit huge coords that should be clipped properly too: it is in my todo list.
07-10-2021

I made tests with internal debugging logs and I confirm there is an overflow in Renderer (x coord ~ 2^31). It is related to the scaling to subpixel coordinates : * 256 on x direction (since 11, was * 8 before, like pisces) but still * 8 on y direction. I tested with -Dprism.marlin.subPixel_log2_X=3 (like fx10) and the test passes, but using larger X coordinate > 134217736 (* 32 + 8) overflow happens again and artefacts are happening again. This overflow problem only impacts fill operations, not stroke operations (in this test). As these stages have a different clipper implementation, I noticed that PathClipFilter (filler case) still emits large moves (not clipped), so it could be improved to avoid overflow in the Renderer. I will take more time to investigate this problem ...
05-10-2021

I can reproduce this problem. The bug is somewhere in the Marlin rasterizer, and was introduced in the JavaFX 11 timeframe. JavaFX 10, which also has Marlin enabled by default, passes. JavaFX 10: pass JavaFX 11.0.12 + nativepisces: pass JavaFX 11.0.12 + marlin: fail JavaFX 17: fail
28-09-2021

[~lbourges] Can you take a look at this?
28-09-2021