swpalmer at gmail.com
Wed Jul 31 07:42:44 PDT 2013
Interesting. The problem outlined in RT-31025 does involve GridPane with
ColumnConstraints. I will try to dig up the code.
On Wed, Jul 31, 2013 at 4:47 AM, Diego Cirujano-Cuesta <
diego.cirujano-cuesta at zeiss.com> wrote:
> Hi Scott,
> I have a component quite similar to the one you described and I also had
> problems like the ones that you mentioned with the same workarounds. BUT I
> found out that the problem was of my understanding. One of the problems
> was, I was using invalidation listeners and I wasn't getting always the
> value and another problem was a gridPane with column constraints.
> I had a look deeply and I fix them, now they work perfect.
> I saw in Jira you sent your code to Eva. If you want, you can send me the
> problem also(with the isolated code) I can have a look or much better, Eva
> could publish the code in Jira. I am interested.
> >(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.)
> This message is intended for a particular addressee only and may contain
> business or company secrets. If you have received this email in error,
> please contact the sender and delete the message immediately. Any use of
> this email, including saving, publishing, copying, replication or
> forwarding of the message or the contents is not permitted.
More information about the openjfx-dev