-
Notifications
You must be signed in to change notification settings - Fork 146
WIP: synchronize sceneState on scale-factor change #99
base: develop
Are you sure you want to change the base?
Conversation
@@ -155,6 +155,7 @@ public void setPixelScaleFactors(float scalex, float scaley) { | |||
renderScaleX = scalex; | |||
renderScaleY = scaley; | |||
entireSceneNeedsRepaint(); | |||
sceneState.update(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not thread-safe. This method must only be called on the JavaFX event thread, and with the render lock held. You will need a different solution to the problem you are trying to solve.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok I see in SWT this is called from the correct Thread but in Swing is is called from EDT. The problem is that sceneState update is ONLY called when the scene is dirty and there's not even internal API to call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
even if called on the correct thread it will need the renderlock, and I don't know if this is an OK place to acquire that lock (it might be, but that would need to be explored).
I looked a bit in the codebase and WindowStage calls GlassScene.updateSceneState() (eg in setBounds) in a similar context and I don't see them getting a lock. If not mistaken this one gets called by a TkPulseListener registered in Window at line 1081. In contrast to that the dispose-method in EmbeddedScene calls it with a lock. |
I'll take a closer look when I get time. |
I've pushed a different solution using a TkPulseListener (borrowing the scheme from WindowStage/Window) |
Conceptually that seems like the right idea (and one I was thinking to suggest), so I'll review it. |
This will need to be tested with both Swing interop (JFXPanel) and SWT interop (FXCanvas). Two questions:
I'll do some testing (might not be this week, since I am reviewing more urgent fixes with a tighter deadline). I'll also review the changes in more detail. |
Also, can you file a JBS bug for this? |
On 1. I‘ve tested FXCanvas moving it between HiDPI and normal DPI screens on OS X and Windows - I‘ll try JFXPanel On 2. I remove the listener upon dispose so I can‘t see how I could introduce a memory leak with this change |
Need to correct - I only tested on OS X - as the hidpi fix on windows was not yet available |
JBS bug: JDK-8204676 |
Have you had a chance to test on Windows yet? I can review it later this week if you are ready. Please send a review request to openjfx-dev so others can see it, too. |
Unfortunately no I need to bring back up my windows toolchain after changing laptops |
As announced in this message, the official This sandbox repository is being retired on 1-Oct-2019. You will need to migrate your WIP pull request to the openjdk/jfx repo if you want to continue working on it. Here are instructions for migrating your pull request. The updated CONTRIBUTING.md doc has additional information on how to proceed. Once you have done this, it would be helpful to add a comment with a pointer to the new PR. The new openjdk/jfx repo will be open for pull requests on Wednesday, 2-Oct-2019. I will send email to the openjfx-dev mailing list announcing this. |
refs #98