date:20170727

Re: javafx.scene.shape.Path (memory) inefficient PathElements

2017-07-27 Thread Jim Graham

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 
 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

Re: javafx.scene.shape.Path (memory) inefficient PathElements

2017-07-27 Thread Tom Schindl

As mentionned at the beginning of the thread, in FX8 you can roll your
custom implementation. I did not yet had the time to test the changes
Jim made :-(

Tom

On 27.07.17 13:41, 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 you
> jose
> 
> 
> 
> On ‎Wednesday‎, ‎May‎ ‎24‎, ‎2017‎ ‎08‎:‎38‎:‎41‎ ‎PM‎ ‎EDT, Jim Graham
>  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

>>
>>


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Re: javafx.scene.shape.Path (memory) inefficient PathElements

2017-07-27 Thread Kevin Rushforth

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 
 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

Re: javafx.scene.shape.Path (memory) inefficient PathElements

2017-07-27 Thread Jose Martinez

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 
 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
>>>
> 
>

[10] Review request: 8185132: window.requestAnimationFrame API is not working

2017-07-27 Thread Arunprasad Rajkumar

Hi,

Please review the following changset,

Webrev: http://cr.openjdk.java.net/~arajkumar/8185132/webrev
Bug: https://bugs.openjdk.java.net/browse/JDK-8185132

Detailed analysis is updated as JBS comment.

Thanks,
Arun

Re: javafx.scene.shape.Path (memory) inefficient PathElements

Re: javafx.scene.shape.Path (memory) inefficient PathElements

Re: javafx.scene.shape.Path (memory) inefficient PathElements

Re: javafx.scene.shape.Path (memory) inefficient PathElements

[10] Review request: 8185132: window.requestAnimationFrame API is not working

5 matches

Site Navigation

Mail list logo

Footer information