Re: buffer too small

[Jim Graham]

I think I see the issue.

In the code that calls maskTex.update(...) it passes 
maskTex.physicalWidth() as the scan stride of the buffer, but the scan 
stride of the buffer is based on the content size, not the physical 
size.  Thus, the checkUpdateParams() method overestimates how many bytes 
are consumed by the operation.


Changing that to maskTex.getContentWidth() should be fine...

...jim

On 3/8/16 6:14 AM, Johan Vos wrote:

We got a number of bug reports (on Android and iOS) reported by developers
using large images:

java.lang.IllegalArgumentException: Upload requires 2475266 elements, but
only 1549938 elements remain in the buffer

at com.sun.prism.impl.BaseTexture.checkUpdateParams(BaseTexture.java:354)

at com.sun.prism.es2.ES2Texture.update(ES2Texture.java:640)

at com.sun.prism.impl.BaseContext.flushVertexBuffer(BaseContext.java:106)

at com.sun.prism.impl.BaseContext.updateMaskTexture(BaseContext.java:248)

at
com.sun.prism.impl.ps.BaseShaderGraphics.renderShape(BaseShaderGraphics.java:482)


I traced this down to the following:

initially, a buffer of [1024 * 1024] is allocated by
BaseContext.validateMaskTexture. When the MaskData becomes bigger than 1024
(w or h), a new buffer is allocated with capacity [newTexW * newTexH] with
newTexW and newTexH the new width/height that are passed when creating a
new Texture. However, the physical size of the texture can be different --
e.g.

ES2Texture.create (ES2Context, PixelFormat, WrapMode, int, int, bool) will
in some cases set the real texWidth/height to the next power of 2.

Subsequently, in next rendering loops when the Texture needs to be updated,
it is checked whether the capacity of the buffer is large enough to hold
the texture. In this case, the physical width is passed and the buffer is
not large enough.

Adding the following two lines in BaseContext.validateMaskTexture() (line
220) fixes the problem:

 newTexW = Math.max(newTexW, maskTex.getPhysicalWidth());

 newTexH = Math.max(newTexH, maskTex.getPhysicalHeight());

Using this patch, the size of the buffer will take the physical size of the
texture into account. I'm not sure this is the best approach though.

- Johan

Re: buffer too small

[Jim Graham]

Hi Johan,

Notes in line below...

On 3/8/16 6:14 AM, Johan Vos wrote:

We got a number of bug reports (on Android and iOS) reported by developers
using large images:

java.lang.IllegalArgumentException: Upload requires 2475266 elements, but
only 1549938 elements remain in the buffer

at com.sun.prism.impl.BaseTexture.checkUpdateParams(BaseTexture.java:354)

at com.sun.prism.es2.ES2Texture.update(ES2Texture.java:640)

at com.sun.prism.impl.BaseContext.flushVertexBuffer(BaseContext.java:106)

at com.sun.prism.impl.BaseContext.updateMaskTexture(BaseContext.java:248)

at
com.sun.prism.impl.ps.BaseShaderGraphics.renderShape(BaseShaderGraphics.java:482)


I traced this down to the following:

initially, a buffer of [1024 * 1024] is allocated by
BaseContext.validateMaskTexture. When the MaskData becomes bigger than 1024
(w or h), a new buffer is allocated with capacity [newTexW * newTexH] with
newTexW and newTexH the new width/height that are passed when creating a
new Texture. However, the physical size of the texture can be different --
e.g.

ES2Texture.create (ES2Context, PixelFormat, WrapMode, int, int, bool) will
in some cases set the real texWidth/height to the next power of 2.


This is one of the primary reasons why content dimensions and physical 
dimensions are not the same.



Subsequently, in next rendering loops when the Texture needs to be updated,
it is checked whether the capacity of the buffer is large enough to hold
the texture. In this case, the physical width is passed and the buffer is
not large enough.


Where is this code that you referred to above?  Where is the physical 
width passed from/to?  Lines of code?


The capacity checks at the top of updateMaskTexture() are all using 
content dimensions which are appropriate, so where are the capacity 
checks you see which are using the physical width?



Adding the following two lines in BaseContext.validateMaskTexture() (line
220) fixes the problem:

 newTexW = Math.max(newTexW, maskTex.getPhysicalWidth());

 newTexH = Math.max(newTexH, maskTex.getPhysicalHeight());


That may mask the problem, but it doesn't fix the underlying problem. 
newTexWH are supposed to be the new content dimensions and should not be 
based on the old phyiscal dimensions or we will grow the texture 
unnecessarily large in many cases.



Using this patch, the size of the buffer will take the physical size of the
texture into account. I'm not sure this is the best approach though.


The buffer is used to update the content portion of the texture, it 
should only ever take the content dimensions of the texture into 
account.  The physical dimensions are not relevant to the discussion here.


There is an optimization that could avoid allocating a new texture that 
could be based on physical dimensions, but you aren't tying into it with 
the above analysis.  I want to get up to speed on what you've found 
above before I can recommend a more appropriate solution...


...jim

iMX.6 X11 limitations.

[Daniel.]

Hi everybody,

At wiki there is this statement:
Using X11 to obtain the EGL context, but acting as if we are the only
application. This path was implemented in the "Monocle" windowing
subsystem, which is available in the OpenJFX build, and will be part
of a future JDK for ARM release. This path was added to enable us to
demonstrate JavaFX on platforms where the direct to Framebuffer
drivers are not easily available. There are limitations inherent to
using this path, and so it is not recommenced for production use.

I would like to know what are the limitations of ussing X11 path?

Best regards and thanks in advance

-- 
"Do or do not. There is no try"
  Yoda Master

Re: ProgressIndicator indeterminate transition bugs

[Chien Yang]

You may track the progress of this work with this JIRA for now. We are 
still investigating the scope and impact of this work. We may decide to 
create a new JIRA and resolve this as a duplicate if we decide to go 
with a better naming.


https://bugs.openjdk.java.net/browse/JDK-8090322

- Chien


On 03/08/16 01:58, Cirujano Cuesta, Diego wrote:

Great! In that case forget the patch I made, it doesn’t make sense until the 
treeVisible property is implemented. Is there any jira ticket that I could 
follow?

Thank you Jonathan.

From: Jonathan Giles [mailto:jonathan.gi...@oracle.com]
Sent: Dienstag, 8. März 2016 10:01
To: Cirujano Cuesta, Diego; openjfx-dev@openjdk.java.net
Subject: RE: ProgressIndicator indeterminate transition bugs

The plan is that a new public API will be developed that matches the 
expectations, whilst retaining the existing treeVisible semantics in that API. 
Chien will be looking into this in the coming weeks. At that point we can 
properly fix these issues.

-- Jonathan
Sent from a touch device. Please excuse my brevity.
On 8 March 2016 21:53:07 GMT+13:00, "Cirujano Cuesta, Diego" 
mailto:diego.cirujano-cue...@zeiss.com>> wrote:

Hi all,

As I understood in the comments(JDK-8094829, JDK-8094078), treeVisible is 
buggy. Is it still buggy? If yes, is there intention to fix the treeVisible 
behavior? In case of fixing this it could be used to fix this issue. If I am 
not wrong, treeVisible is still used by Node, SwingNode and MediaView.

@Jonathan As you mentioned in JDK-8094829 "having a correctly working treeVisible 
property would be immensely useful." And I am completely agree and I would like to 
add that having in the public API would be even better :-).

Thank you,
Diego

-Original Message-
From: Jonathan Giles [mailto:jonathan.gi...@oracle.com]
Sent: Sonntag, 28. Februar 2016 22:54
To: Cirujano Cuesta, Diego; 
openjfx-dev@openjdk.java.net
Subject: Re: ProgressIndicator indeterminate transition bugs

If you can, are you able to file bug reports for these?

-- Jonathan

On 29/02/16 10:49 AM, Cirujano Cuesta, Diego wrote:

  Hi all,

  We found two important bugs in ProgressIndicator that are related with the 
following tickets:

  https://bugs.openjdk.java.net/browse/JDK-8094829
  https://bugs.openjdk.java.net/browse/JDK-8094078

  Now are quite critical because in a 4K monitor may cause OutOfMemoryException.

  Using the following example:
  "
  public class JFXMain extends Application{

   @Override
   public void start(Stage primaryStage) throws Exception {
   HBox root = new HBox();
   ToggleButton toggleButton = new ToggleButton();
   ProgressIndicator progressIndicator = new 
ProgressIndicator(ProgressIndicator.INDETERMINATE_PROGRESS);
   StackPane stackPane = new StackPane(progressIndicator);
   stackPane.visibleProperty().bind(toggleButton.selectedProperty());
   root.getChildren().addAll(toggleButton, stackPane);
   primaryStage.setScene(new Scene(root));
   primaryStage.show();
   }
  }
  "

  ** First bug **

  Starting the Progress Indicator with indeterminate progress will
  trigger: rebuildTimeline by ProgressIndicatorSkin and in line 599
  start the animation even is not shown already:
  indeterminateTransition.playFromStart();

  ** Second bug **

  With the last commits in ProgressIndicator, as commented in JDK-8094829, the 
listeners do not care about the real visibility of the node(before it was used 
impl_treeVisibleProperty()). The consequence is that the ProgressIndicator in 
the example won´t be stopped.

  I can imagine that impl_treeVisibleProperty() should not be used and Jonathan G. said: 
" but I can't reliably fix that without an API such as what I expect the treeVisible 
API should do." But we did not find such alternative property.

  The solution we though is the usage of internal tree visible property like 
this:

  1. Modify method:
  "
   protected void updateAnimation(boolean isTreeVisible) { "
  2. Remove current calls to method in
  "
   @Override protected void handleControlPropertyChanged(String p) {
   super.handleControlPropertyChanged(p);

   if ("INDETERMINATE".equals(p)) {
   initialize();
   } else if ("PROGRESS".equals(p)) {
   updateProgress();
   }
}
  "
  3. Add listener at the end of the IndeterminateSpinner contructor the 
visibility listener:
  "
   private IndeterminateSpinner(boolean spinEnabled, Paint 
fillOverride) {
[...]
   impl_treeVisibleProperty().addListener((obs, oldVal, newVal) ->{
   updateAnimation(newVal);
   });
 }
  "

  What do you think?

  Additional note: I would like to add one more thing. I think that could be 
very good a property ReadOnlyBooleanProperty treeVisibleProperty() available in 
all Nodes.

  Please let me know if we can do something else.

  Diego

review for enabling systemTest with Jake

[David Hill]

Kevin,

(finally)

https://bugs.openjdk.java.net/browse/JDK-8147399

http://cr.openjdk.java.net/~ddhill/8147399/

--
David Hill
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the 
world."
-- George Santayana (1863 - 1952)

Re: Learning Prism

[Morris Meyer]

As the Quantum author I will echo Johan that looking at the 
QuantumToolkit.pulse() and QuantumRenderer.submitRenderJob() are good 
places to start. Ignore the PaintCollector (Pain Collector :-) ) and pay 
attention to the View Painters.


This article has good background.

http://fxexperience.com/2012/02/a-short-tour-through-javafx-ui-common/

The SceneGraph converts SG nodes to Prism NG nodes. The painters convert 
Prism NG nodes into graphics operations. That node graph is rendered 
onto a Prism hardware (or software prism-sw) pipeline.  This winds up at 
the GPU layer in places like native-prism-es2/macosx or native-prism-d3d.


Glass manages operating system resources like menu bars, events, 
dragging, pasteboard, screens and graphical layers.


On Mac OSX drawing winds up in native-glass/mac in places like 
GlassView3D.m (begin, end) and GlassLayer3D.m (drawInCGLContext) - a 
good way to see what is going on at the low level is uncommenting 
VERBOSE in these Glass classes in native-glass/mac and seeing the flow 
at the native level.


There is sort of a separation of Church and State thing going on with 
the Prism native layers (native-prism-es2/macosx vs native-glass/mac) 
that has been very well designed over various iterations by Chein Yang 
in the Java Client Group.


One final note about time from the Quantum dude.  Our JavaFX timebase is 
not driven by a time that is going off at 16 ms to simulate a 60 Hertz 
retrace.  Our pulsed painting timebase (since RT-13660) is driven from 
the vertical retrace interval.  Quantum queues up the pulses from the 
Glass timer at 16 ms (faster than 60 Hz), such that a pulse is waiting 
its turn for the graphics vertical retrace to happen (on Mac, Linux-GPU, 
Windows-D3D and iOS).  The pulse is kicked off immediately after the 
vertical retrace which ensures a rock solid 60 Hz timebase for JavaFX 
animations.


--morris

NP - Young the Giant, Young the Giant, My Body


On 3/7/16 10:45 PM, Jeffrey Guenther wrote:

Hi Devs,

I’m interested in learning more about JavaFX’s low level graphics implementation. 
I’ve spent a couple afternoons source diving in the modules/graphics folder to get 
the lay of the land and now I think I need some help. Can anyone point me to 
documentation describing the system’s high level design? Let’s say one or two levels 
deeper than http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm? 


Ultimately, I’d like to gain a better understanding on how JavaFX lays out and 
renders text for the purposes of understanding how I might be able to 
contribute to a more advanced text API with support for things like kerning.

Secondly, can anyone explain to me how shaders are compiled and passed down to 
the graphics layer? I’d like to gain a better understanding of how a JavaFX 
programmer could leverage/add to Prism such that we can write custom 
shaders/GPU kernels for Effects nodes.

I realize the graphics system in JavaFX is not for the faint of heart. There’s 
much going on beneath the surface. I’m willing to dive deep and do the learning 
to understand the design. Can anyone point me to docs where I can get started? 
Or maybe which class to start with and work out from when I’m source diving?

Jeff

JavaFX 9 / JRE 9 on ARMv7

[Maurice]

Given that development of JavaFX 9 will switch to JRE 9 completely 
anytime soon I'm thinking of switching to JavaFX 9 and a JRE 9. However, 
do the freely available JVMs for ARMv7 32bit have a JIT?


Maurice.

buffer too small

[Johan Vos]

We got a number of bug reports (on Android and iOS) reported by developers
using large images:

java.lang.IllegalArgumentException: Upload requires 2475266 elements, but
only 1549938 elements remain in the buffer

at com.sun.prism.impl.BaseTexture.checkUpdateParams(BaseTexture.java:354)

at com.sun.prism.es2.ES2Texture.update(ES2Texture.java:640)

at com.sun.prism.impl.BaseContext.flushVertexBuffer(BaseContext.java:106)

at com.sun.prism.impl.BaseContext.updateMaskTexture(BaseContext.java:248)

at
com.sun.prism.impl.ps.BaseShaderGraphics.renderShape(BaseShaderGraphics.java:482)


I traced this down to the following:

initially, a buffer of [1024 * 1024] is allocated by
BaseContext.validateMaskTexture. When the MaskData becomes bigger than 1024
(w or h), a new buffer is allocated with capacity [newTexW * newTexH] with
newTexW and newTexH the new width/height that are passed when creating a
new Texture. However, the physical size of the texture can be different --
e.g.

ES2Texture.create (ES2Context, PixelFormat, WrapMode, int, int, bool) will
in some cases set the real texWidth/height to the next power of 2.

Subsequently, in next rendering loops when the Texture needs to be updated,
it is checked whether the capacity of the buffer is large enough to hold
the texture. In this case, the physical width is passed and the buffer is
not large enough.

Adding the following two lines in BaseContext.validateMaskTexture() (line
220) fixes the problem:

newTexW = Math.max(newTexW, maskTex.getPhysicalWidth());

newTexH = Math.max(newTexH, maskTex.getPhysicalHeight());

Using this patch, the size of the buffer will take the physical size of the
texture into account. I'm not sure this is the best approach though.

- Johan

Re: Learning Prism

[Johan Vos]

Hi,

I think the best way to get started really depends on your personal
preferences (e.g. do you like to read code, docs, diagrams,...).
I can only comment on how I do it, but others may have other approaches:

First of all, you can run a simple JavaFX apps with lots of verbose info.
See com.sun.prism.impl.PrismSettings for a list, and have at least
prism.verbose set to true. This already gives you lots of insight in what
is happening.

Second, you want to know what happens on a pulse. Although many complex
things are happening, this is not very hard to detect from the code: start
from QuantumToolkit.pulse() and follow it from there. There are basically
two main parts:
* do the calculations (on the FX Thread) (e.g. look at
Scene.ScenePulseListener.pulse())
* do the rendering (PaintCollector.renderAll() which will ultimately call
QuantumRenderer.submitRenderJob() which runs on the Prism thread).

- Johan


On Tue, Mar 8, 2016 at 5:34 AM, Felix Bembrick 
wrote:

> +1
>
> I too would love to dive as deep as possible and improve anything that
> needs improving so some guidance would help greatly!
>
> Felix
>
> On 8 March 2016 at 14:45, Jeffrey Guenther 
> wrote:
>
> > Hi Devs,
> >
> > I’m interested in learning more about JavaFX’s low level graphics
> > implementation. I’ve spent a couple afternoons source diving in the
> > modules/graphics folder to get the lay of the land and now I think I need
> > some help. Can anyone point me to documentation describing the system’s
> > high level design? Let’s say one or two levels deeper than
> > http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm? <
> > http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm?>
> >
> > Ultimately, I’d like to gain a better understanding on how JavaFX lays
> out
> > and renders text for the purposes of understanding how I might be able to
> > contribute to a more advanced text API with support for things like
> kerning.
> >
> > Secondly, can anyone explain to me how shaders are compiled and passed
> > down to the graphics layer? I’d like to gain a better understanding of
> how
> > a JavaFX programmer could leverage/add to Prism such that we can write
> > custom shaders/GPU kernels for Effects nodes.
> >
> > I realize the graphics system in JavaFX is not for the faint of heart.
> > There’s much going on beneath the surface. I’m willing to dive deep and
> do
> > the learning to understand the design. Can anyone point me to docs where
> I
> > can get started? Or maybe which class to start with and work out from
> when
> > I’m source diving?
> >
> > Jeff
>

RE: ProgressIndicator indeterminate transition bugs

[Cirujano Cuesta, Diego]

Great! In that case forget the patch I made, it doesn’t make sense until the 
treeVisible property is implemented. Is there any jira ticket that I could 
follow?

Thank you Jonathan.

From: Jonathan Giles [mailto:jonathan.gi...@oracle.com]
Sent: Dienstag, 8. März 2016 10:01
To: Cirujano Cuesta, Diego; openjfx-dev@openjdk.java.net
Subject: RE: ProgressIndicator indeterminate transition bugs

The plan is that a new public API will be developed that matches the 
expectations, whilst retaining the existing treeVisible semantics in that API. 
Chien will be looking into this in the coming weeks. At that point we can 
properly fix these issues.

-- Jonathan
Sent from a touch device. Please excuse my brevity.
On 8 March 2016 21:53:07 GMT+13:00, "Cirujano Cuesta, Diego" 
mailto:diego.cirujano-cue...@zeiss.com>> wrote:

Hi all,

As I understood in the comments(JDK-8094829, JDK-8094078), treeVisible is 
buggy. Is it still buggy? If yes, is there intention to fix the treeVisible 
behavior? In case of fixing this it could be used to fix this issue. If I am 
not wrong, treeVisible is still used by Node, SwingNode and MediaView.

@Jonathan As you mentioned in JDK-8094829 "having a correctly working 
treeVisible property would be immensely useful." And I am completely agree and 
I would like to add that having in the public API would be even better :-).

Thank you,
Diego

-Original Message-
From: Jonathan Giles [mailto:jonathan.gi...@oracle.com]
Sent: Sonntag, 28. Februar 2016 22:54
To: Cirujano Cuesta, Diego; 
openjfx-dev@openjdk.java.net
Subject: Re: ProgressIndicator indeterminate transition bugs

If you can, are you able to file bug reports for these?

-- Jonathan

On 29/02/16 10:49 AM, Cirujano Cuesta, Diego wrote:

 Hi all,

 We found two important bugs in ProgressIndicator that are related with the 
following tickets:

 https://bugs.openjdk.java.net/browse/JDK-8094829
 https://bugs.openjdk.java.net/browse/JDK-8094078

 Now are quite critical because in a 4K monitor may cause OutOfMemoryException.

 Using the following example:
 "
 public class JFXMain extends Application{

  @Override
  public void start(Stage primaryStage) throws Exception {
  HBox root = new HBox();
  ToggleButton toggleButton = new ToggleButton();
  ProgressIndicator progressIndicator = new 
ProgressIndicator(ProgressIndicator.INDETERMINATE_PROGRESS);
  StackPane stackPane = new StackPane(progressIndicator);
  stackPane.visibleProperty().bind(toggleButton.selectedProperty());
  root.getChildren().addAll(toggleButton, stackPane);
  primaryStage.setScene(new Scene(root));
  primaryStage.show();
  }
 }
 "

 ** First bug **

 Starting the Progress Indicator with indeterminate progress will
 trigger: rebuildTimeline by ProgressIndicatorSkin and in line 599
 start the animation even is not shown already:
 indeterminateTransition.playFromStart();

 ** Second bug **

 With the last commits in ProgressIndicator, as commented in JDK-8094829, the 
listeners do not care about the real visibility of the node(before it was used 
impl_treeVisibleProperty()). The consequence is that the ProgressIndicator in 
the example won´t be stopped.

 I can imagine that impl_treeVisibleProperty() should not be used and Jonathan 
G. said: " but I can't reliably fix that without an API such as what I expect 
the treeVisible API should do." But we did not find such alternative property.

 The solution we though is the usage of internal tree visible property like 
this:

 1. Modify method:
 "
  protected void updateAnimation(boolean isTreeVisible) { "
 2. Remove current calls to method in
 "
  @Override protected void handleControlPropertyChanged(String p) {
  super.handleControlPropertyChanged(p);

  if ("INDETERMINATE".equals(p)) {
  initialize();
  } else if ("PROGRESS".equals(p)) {
  updateProgress();
  }
   }
 "
 3. Add listener at the end of the IndeterminateSpinner contructor the 
visibility listener:
 "
  private IndeterminateSpinner(boolean spinEnabled, Paint fillOverride) 
{
   [...]
  impl_treeVisibleProperty().addListener((obs, oldVal, newVal) ->{
  updateAnimation(newVal);
  });
}
 "

 What do you think?

 Additional note: I would like to add one more thing. I think that could be 
very good a property ReadOnlyBooleanProperty treeVisibleProperty() available in 
all Nodes.

 Please let me know if we can do something else.

 Diego

RE: ProgressIndicator indeterminate transition bugs

[Jonathan Giles]

The plan is that a new public API will be developed that matches the 
expectations, whilst retaining the existing treeVisible semantics in that API. 
Chien will be looking into this in the coming weeks. At that point we can 
properly fix these issues.

-- Jonathan
Sent from a touch device. Please excuse my brevity.

On 8 March 2016 21:53:07 GMT+13:00, "Cirujano Cuesta, Diego" 
 wrote:
>Hi all,
>
>As I understood in the comments(JDK-8094829, JDK-8094078), treeVisible
>is buggy. Is it still buggy? If yes, is there intention to fix the
>treeVisible behavior? In case of fixing this it could be used to fix
>this issue. If I am not wrong, treeVisible is still used by Node,
>SwingNode and MediaView.
>
>@Jonathan As you mentioned in JDK-8094829 "having a correctly working
>treeVisible property would be immensely useful." And I am completely
>agree and I would like to add that having in the public API would be
>even better :-).
>
>Thank you,
>Diego
>
>-Original Message-
>From: Jonathan Giles [mailto:jonathan.gi...@oracle.com] 
>Sent: Sonntag, 28. Februar 2016 22:54
>To: Cirujano Cuesta, Diego; openjfx-dev@openjdk.java.net
>Subject: Re: ProgressIndicator indeterminate transition bugs
>
>If you can, are you able to file bug reports for these?
>
>-- Jonathan
>
>On 29/02/16 10:49 AM, Cirujano Cuesta, Diego wrote:
>> Hi all,
>>
>> We found two important bugs in ProgressIndicator that are related
>with the following tickets:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8094829
>> https://bugs.openjdk.java.net/browse/JDK-8094078
>>
>> Now are quite critical because in a 4K monitor may cause
>OutOfMemoryException.
>>
>> Using the following example:
>> "
>> public class JFXMain extends Application{
>>
>>  @Override
>>  public void start(Stage primaryStage) throws Exception {
>>  HBox root = new HBox();
>>  ToggleButton toggleButton = new ToggleButton();
>>  ProgressIndicator progressIndicator = new
>ProgressIndicator(ProgressIndicator.INDETERMINATE_PROGRESS);
>>  StackPane stackPane = new StackPane(progressIndicator);
>> 
>stackPane.visibleProperty().bind(toggleButton.selectedProperty());
>>  root.getChildren().addAll(toggleButton, stackPane);
>>  primaryStage.setScene(new Scene(root));
>>  primaryStage.show();
>>  }
>> }
>> "
>>
>> ** First bug **
>>
>> Starting the Progress Indicator with indeterminate progress will 
>> trigger: rebuildTimeline by ProgressIndicatorSkin and in line 599 
>> start the animation even is not shown already: 
>> indeterminateTransition.playFromStart();
>>
>> ** Second bug **
>>
>> With the last commits in ProgressIndicator, as commented in
>JDK-8094829, the listeners do not care about the real visibility of the
>node(before it was used impl_treeVisibleProperty()). The consequence is
>that the ProgressIndicator in the example won´t be stopped.
>>
>> I can imagine that impl_treeVisibleProperty() should not be used and
>Jonathan G. said: " but I can't reliably fix that without an API such
>as what I expect the treeVisible API should do." But we did not find
>such alternative property.
>>
>> The solution we though is the usage of internal tree visible property
>like this:
>>
>> 1. Modify method:
>> "
>>  protected void updateAnimation(boolean isTreeVisible) { "
>> 2. Remove current calls to method in
>> "
>>  @Override protected void handleControlPropertyChanged(String p) {
>>  super.handleControlPropertyChanged(p);
>>
>>  if ("INDETERMINATE".equals(p)) {
>>  initialize();
>>  } else if ("PROGRESS".equals(p)) {
>>  updateProgress();
>>  }
>>  }
>> "
>> 3. Add listener at the end of the IndeterminateSpinner contructor the
>visibility listener:
>> "
>>  private IndeterminateSpinner(boolean spinEnabled, Paint
>fillOverride) {
>>  [...]
>>  impl_treeVisibleProperty().addListener((obs, oldVal,
>newVal) ->{
>>  updateAnimation(newVal);
>>  });
>>}
>> "
>>
>> What do you think?
>>
>> Additional note: I would like to add one more thing. I think that
>could be very good a property ReadOnlyBooleanProperty
>treeVisibleProperty() available in all Nodes.
>>
>> Please let me know if we can do something else.
>>
>> Diego

RE: ProgressIndicator indeterminate transition bugs

[Cirujano Cuesta, Diego]

Hi all,

As I understood in the comments(JDK-8094829, JDK-8094078), treeVisible is 
buggy. Is it still buggy? If yes, is there intention to fix the treeVisible 
behavior? In case of fixing this it could be used to fix this issue. If I am 
not wrong, treeVisible is still used by Node, SwingNode and MediaView.

@Jonathan As you mentioned in JDK-8094829 "having a correctly working 
treeVisible property would be immensely useful." And I am completely agree and 
I would like to add that having in the public API would be even better :-).

Thank you,
Diego

-Original Message-
From: Jonathan Giles [mailto:jonathan.gi...@oracle.com] 
Sent: Sonntag, 28. Februar 2016 22:54
To: Cirujano Cuesta, Diego; openjfx-dev@openjdk.java.net
Subject: Re: ProgressIndicator indeterminate transition bugs

If you can, are you able to file bug reports for these?

-- Jonathan

On 29/02/16 10:49 AM, Cirujano Cuesta, Diego wrote:
> Hi all,
>
> We found two important bugs in ProgressIndicator that are related with the 
> following tickets:
>
> https://bugs.openjdk.java.net/browse/JDK-8094829
> https://bugs.openjdk.java.net/browse/JDK-8094078
>
> Now are quite critical because in a 4K monitor may cause OutOfMemoryException.
>
> Using the following example:
> "
> public class JFXMain extends Application{
>
>  @Override
>  public void start(Stage primaryStage) throws Exception {
>  HBox root = new HBox();
>  ToggleButton toggleButton = new ToggleButton();
>  ProgressIndicator progressIndicator = new 
> ProgressIndicator(ProgressIndicator.INDETERMINATE_PROGRESS);
>  StackPane stackPane = new StackPane(progressIndicator);
>  stackPane.visibleProperty().bind(toggleButton.selectedProperty());
>  root.getChildren().addAll(toggleButton, stackPane);
>  primaryStage.setScene(new Scene(root));
>  primaryStage.show();
>  }
> }
> "
>
> ** First bug **
>
> Starting the Progress Indicator with indeterminate progress will 
> trigger: rebuildTimeline by ProgressIndicatorSkin and in line 599 
> start the animation even is not shown already: 
> indeterminateTransition.playFromStart();
>
> ** Second bug **
>
> With the last commits in ProgressIndicator, as commented in JDK-8094829, the 
> listeners do not care about the real visibility of the node(before it was 
> used impl_treeVisibleProperty()). The consequence is that the 
> ProgressIndicator in the example won´t be stopped.
>
> I can imagine that impl_treeVisibleProperty() should not be used and Jonathan 
> G. said: " but I can't reliably fix that without an API such as what I expect 
> the treeVisible API should do." But we did not find such alternative property.
>
> The solution we though is the usage of internal tree visible property like 
> this:
>
> 1. Modify method:
> "
>   protected void updateAnimation(boolean isTreeVisible) { "
> 2. Remove current calls to method in
> "
>   @Override protected void handleControlPropertyChanged(String p) {
>  super.handleControlPropertyChanged(p);
>
>  if ("INDETERMINATE".equals(p)) {
>  initialize();
>  } else if ("PROGRESS".equals(p)) {
>  updateProgress();
>  }
>   }
> "
> 3. Add listener at the end of the IndeterminateSpinner contructor the 
> visibility listener:
> "
>  private IndeterminateSpinner(boolean spinEnabled, Paint 
> fillOverride) {
>   [...]
>  impl_treeVisibleProperty().addListener((obs, oldVal, newVal) ->{
>  updateAnimation(newVal);
>  });
> }
> "
>
> What do you think?
>
> Additional note: I would like to add one more thing. I think that could be 
> very good a property ReadOnlyBooleanProperty treeVisibleProperty() available 
> in all Nodes.
>
> Please let me know if we can do something else.
>
> Diego