Bug 537893 - GEF Geometry Line's boundsInParent is not correct calculated
Summary: GEF Geometry Line's boundsInParent is not correct calculated
Status: NEW
Alias: None
Product: GEF
Classification: Tools
Component: GEF Geometry (show other bugs)
Version: 5.0.100   Edit
Hardware: PC Windows 10
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: gef-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-13 05:40 EDT by Shenwei Zheng CLA
Modified: 2019-01-11 10:07 EST (History)
3 users (show)

See Also:


Attachments
GEF geometry line boundsInParent (49.21 KB, image/png)
2018-08-13 05:40 EDT, Shenwei Zheng CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Shenwei Zheng CLA 2018-08-13 05:40:48 EDT
Created attachment 275369 [details]
GEF geometry line boundsInParent

In a GEF application I defined a GEF geometry line which has width 150, height 10 and stroke line cap is BUTT. But the BoundsInParent of the line came out with width 160 and height 11. 
I set a background for the line and found out there is space before and after the line. Space is each side 5 Pixel. 
More detail can be found here https://www.eclipse.org/forums/index.php/t/1094514/
Thank you.
Comment 1 Matthias Wienand CLA 2019-01-11 10:07:27 EST
I added a test case w.r.t. the incorrect behavior of GeometryNode when using BUTT stroke line cap. The test also contains a conversion from the individual JavaFX bounds (layout-bounds, bounds-in-local, bounds-in-parent) to the geometric bounds of the wrapped geometry (to improve understandability, e.g. due to internal workings of JavaFX, bounds-in-local contain a "minimum pen size" that needs to be compensated).

Due to the complexity of GeometryNode -- necessary for automatic, geometry-preserving resizement and other niceties -- bounds need to be computed by GeometryNode, which is rather complicated. The current approximation of the underlying JavaFX computations is conceptually undesirable and is nearly impossible to get correct in all situations, also considering future changes applied to JavaFX, different platforms, etc.

Therefore, I would opt for providing an additional concept for the rendering of GEF geometries:
 - We could provide SimpleGeometryNode, extending JavaFX Path, and just bridging to GEF Geometry, i.e. providing geometry accessors.
 - In order to preserve the clickable-area-behavior associated with GeometryNode, we could potentially provide a ClickableAreaNode that can wrap a JavaFX Path.
 - Then, you should be able to leverage all JavaFX functionality while still being able to comfortably render and interact with GEF Geometry objects.
 - Also, the bounds computations are then done by JavaFX alone, so there cannot be any inconsistencies, with the exception of inconsistencies stemming from the conversion of a GEF Geometry to a JavaFX Path.