Skip to content
This repository has been archived by the owner on Jun 24, 2021. It is now read-only.

WIP: synchronize sceneState on scale-factor change #99

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

tomsontom
Copy link
Contributor

refs #98

@@ -155,6 +155,7 @@ public void setPixelScaleFactors(float scalex, float scaley) {
renderScaleX = scalex;
renderScaleY = scaley;
entireSceneNeedsRepaint();
sceneState.update();
Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

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

@tomsontom
Copy link
Contributor Author

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.

@kevinrushforth
Copy link
Collaborator

I'll take a closer look when I get time.

@tomsontom
Copy link
Contributor Author

I've pushed a different solution using a TkPulseListener (borrowing the scheme from WindowStage/Window)

@kevinrushforth
Copy link
Collaborator

Conceptually that seems like the right idea (and one I was thinking to suggest), so I'll review it.

@eugener eugener added the bug Something isn't working label Jun 20, 2018
@kevinrushforth
Copy link
Collaborator

This will need to be tested with both Swing interop (JFXPanel) and SWT interop (FXCanvas). Two questions:

  1. Can you say what testing you have done?
  2. Have you confirmed that the listener doesn't cause a memory leak?

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.

@kevinrushforth
Copy link
Collaborator

Also, can you file a JBS bug for this?

@tomsontom
Copy link
Contributor Author

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

@tomsontom
Copy link
Contributor Author

Need to correct - I only tested on OS X - as the hidpi fix on windows was not yet available

@kevinrushforth
Copy link
Collaborator

JBS bug: JDK-8204676

@kevinrushforth
Copy link
Collaborator

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.

@tomsontom
Copy link
Contributor Author

Unfortunately no I need to bring back up my windows toolchain after changing laptops

@kevinrushforth kevinrushforth added the WIP Work In Progress label Feb 16, 2019
@kevinrushforth kevinrushforth changed the title synchronize sceneState on scale-factor change [WIP] synchronize sceneState on scale-factor change Feb 16, 2019
@kevinrushforth kevinrushforth changed the title [WIP] synchronize sceneState on scale-factor change WIP: synchronize sceneState on scale-factor change Oct 1, 2019
@kevinrushforth
Copy link
Collaborator

kevinrushforth commented Oct 1, 2019

As announced in this message, the official jfx repository is moving from hg.openjdk.java.net/openjfx/jfx-dev/rt to github.com/openjdk/jfx.

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working WIP Work In Progress
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants