[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: javafx.scene.shape.Path (memory) inefficient PathElements
From:       Jim Graham <james.graham () oracle ! com>
Date:       2017-07-27 22:29:36
Message-ID: 7cd75384-e581-3d78-21a9-43c2cee191f4 () oracle ! com
[Download RAW message or body]

And, to clarify, the super-lazy property fix is currently only targeted to JDK10.  A \
case would need to be made to  back-port it to any update releases once it is fixed \
there.  We haven't seen or presented such a case at this point so  we are only \
planning to fix it in JDK10 and Tom has indicated that he has found his own \
workaround for JDK8.

The other bug related to creating a new Path object with lighter weight storage would \
be new API and not be eligible to  back-porting.

8u144 was not a general update release, it was an emergency regression fix for the \
8u141 CPU release.  Even if we had  pushed this into JDK10, it would not have been \
eligible to go into either of those releases...

			...jim

On 7/27/17 5:07 AM, Kevin Rushforth wrote:
> No, this fix hasn't yet been reviewed and pushed. When it is it will go into JDK \
> 10. 
> -- Kevin
> 
> 
> Jose Martinez wrote:
> > Just curious, did this make it to the 8u144 release?  If not, any idea which \
> > release (or when) we can expect it? Thank youjose
> > 
> > 
> > On ‎Wednesday‎, ‎May‎ ‎24‎, ‎2017‎ ‎08‎:‎38‎:‎41‎ \
> > ‎PM‎ ‎EDT, Jim Graham <james.graham@oracle.com> wrote: 
> > Thanks Tom, I've already posted a patch for 8180938 (lazy property creation).  \
> > Check it out and let me know how it  performs for you.
> > 
> > I have a couple of changes to make to it (and an independent memory usage test to \
> > write) before I send it out for  formal review...
> > 
> > ...jim
> > 
> > On 5/24/17 3:42 AM, Tom Schindl wrote:
> > > Hi,
> > > 
> > > I created:
> > > - https://bugs.openjdk.java.net/browse/JDK-8180935
> > > - https://bugs.openjdk.java.net/browse/JDK-8180938
> > > 
> > > I'll work on a showcase to find out how much memory one can save.
> > > 
> > > Tom
> > > 
> > > On 04.05.17 23:33, Jim Graham wrote:
> > > > Hi Tom,
> > > > 
> > > > Those look like good suggestions.  I would file bugs in JBS and create
> > > > them separately:
> > > > 
> > > > - Bug for lazy property creation in path elements
> > > > - Feature request for lower-memory paths
> > > > 
> > > > Did you benchmark how much the lazy properties, on their own, would save
> > > > your application?
> > > > 
> > > > ...jim
> > > > 
> > > > On 5/4/17 2:22 PM, Tom Schindl wrote:
> > > > > Hi,
> > > > > 
> > > > > We are currently working on a PDF-Rendering library in JavaFX and we
> > > > > need to draw glyphs using the JavaFX Path API (there are multiple
> > > > > reasons why we don't use the Text-Node and or Canvas).
> > > > > 
> > > > > When drawing a page full of Text this means that we have a Path-Object
> > > > > with gazillions of MoveTo and CubicCurveTo elements who sum up to 30MB
> > > > > just to represent them in the SG because PathElements store their
> > > > > information in properties and forcefully intialize them in their
> > > > > constructor.
> > > > > 
> > > > > The only public API to work around this problem is to construct a
> > > > > StringBuffer and use SVGPath which means:
> > > > > * it takes time to construct the SVG-Path-String
> > > > > * it takes time to parse the SVG-Path-String in JavaFX
> > > > > 
> > > > > As an experiment (and because we are still on Java8 we can easily do
> > > > > that) was that we created our own Shape-Subclass who:
> > > > > * uses floats (there's no reason to use double in the SG when the
> > > > > backing API - Path2D - is float based)
> > > > > * passes the floats directly to the Path2D/NGPath API
> > > > > 
> > > > > Guess what: We now need 2.5MB / page which means 27.5MB is the overhead
> > > > > added by the current Path-API - ouch!
> > > > > 
> > > > > I think a fairly low hanging memory optimization for the PathElement
> > > > > would be to create properties lazy (only if someone access the property).
> > > > > 
> > > > > For MoveTo this would mean the following minimal change (eg for the
> > > > > x-value):
> > > > > 
> > > > > private DoubleProperty x;
> > > > > private double _x;
> > > > > 
> > > > > public final void setX(double value) {
> > > > > if (x != null) {
> > > > > xProperty().set(value);
> > > > > } else {
> > > > > _x = value;
> > > > > u();
> > > > > }
> > > > > }
> > > > > 
> > > > > public final double getX() {
> > > > > return x == null ? _x : x.get();
> > > > > }
> > > > > 
> > > > > public final DoubleProperty xProperty() {
> > > > > if (x == null) {
> > > > > x = new DoublePropertyBase(_x) {
> > > > > 
> > > > > @Override
> > > > > public void invalidated() {
> > > > > u();
> > > > > }
> > > > > 
> > > > > @Override
> > > > > public Object getBean() {
> > > > > return MoveTo.this;
> > > > > }
> > > > > 
> > > > > @Override
> > > > > public String getName() {
> > > > > return "x";
> > > > > }
> > > > > };
> > > > > }
> > > > > return x;
> > > > > }
> > > > > 
> > > > > I guess 99% of the code out there never access the Property so the small
> > > > > footprint added by the primitive field is justifiable.
> > > > > 
> > > > > This still has the overhead of all the needless PathElement objects
> > > > > hanging around so another idea is to have a 3rd SG-Path-Type who
> > > > > strictly uses the float-Primitives with a similar API to Path2D (in fact
> > > > > it only acts as a public API to Path2D).
> > > > > 
> > > > > Thoughts?
> > > > > 
> > > > > Tom
> > > > > 


[prev in list] [next in list] [prev in thread] [next in thread]