Missed "pulse"?

Scott Palmer swpalmer at gmail.com
Tue Jul 30 17:29:35 PDT 2013

(I'm talking JavaFX2.x, but this happens in 8 as well.)

In my application I occasionally see a situation where the rendering
doesn't jive with what it should. For example I have implemented my own
scroll pane (ironically enough I did this to workaround manifestations of a
problem similar to what I am about to describe in the stock ScrollPane)
using clipping and translations, but sometimes I see the clipped content at
the wrong location. So my clipped content is offset from the edge of my
pane, or rendered over top of things outside my pane, even though it is
impossible for the clipping and translating to not be set together.  If I
mouse over the offending area it suddenly snaps to the way it should be
(CSS rules on the content would have forced it to redraw).

In other situations, I may need to coax a proper rendering of certain
layouts by nudging the size of something to force another layout.

Obviously things should just paint correctly the first time.  In these
situations, the variables appear to be set to the correct values, but
somehow that didn't get to the screen.

I'm not certain, but I suspect I might be able to work around these issues
if I could force a "pulse" or mark things as dirty some way to trigger one.
 The thing is, there doesn't seem to be a publicly accessible way to do
this, presumably because it isn't supposed to be necessary in the first
Platform.runLater(... requestLayout ...) was one workaround that I started
to use, in the cases where things were particularly bad, but it isn't the
sort of things I want to have to scatter throughout my code..

With recent testing on JavaFX 8 I had to remove some of my workarounds
because they caused a stack overflow doing layout. In requestLayout, I
would call requestLayout directly on some specific child nodes (without a
runLater) that seemed to misbehave - somehow this got back to call
requestLayout again in my class and a quick attempt to break the cycle
didn't work.

I'm sure you can appreciate the frustration in trying to ship a
professional quality application with this sort of instability in the
rendering system.

Since I suspect these issues aren't going to be fixed before 7u40 ships,
and 8 is a long way off, what is the best thing to do?  I have already
filed bugs for issues in a few specific cases. E.g.
RT-31025<https://javafx-jira.kenai.com/browse/RT-31025> (In
some cases from a long time ago I was unsure if I was doing something wrong
so I may not have isolated things into a test case and reported a bug.)



More information about the openjfx-dev mailing list