Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Wed, 16 Dec 2020 00:35:08 GMT, Kevin Rushforth wrote:
>>> I am wondering; is it ok to potentially address both sub-issues discussed
>>> here (Scrollpane snaping vs cache rendering) under the same JBS bug? Or
>>> would it be better to address them under separate issues?
>>
>> Since both issues -- the snap-to-pixel bug and the rendering of the cached
>> image -- are causing blurriness, it could be OK _in principle_ to address
>> both of them as part of the same bug fix.
>>
>> However, in this instance the snap-to-pixel bug has a simple,
>> well-understood, and safe solution, while the cached rendering bug isn't
>> nearly as simple; there are a couple ways it could be fixed, each with their
>> own implications. Given that, I would prefer to address the snap-to-pixel
>> bug here (which can easily make jfx16), and file a follow-up bug for the
>> cached rendering.
>>
>>> the JBS issue title is in fact misleading, as the issue appears to be not
>>> specific to Windows; what's the best practice in such cases; rename the
>>> issue? Open a new one? Leave it as is?
>>
>> This is easily fixed by renaming the JBS issue, and then updating the PR
>> title to match. I'll update the JBS issue now, after which you can update
>> the PR title.
>>
>> Here are some thoughts about the cached rendering, which should find their
>> way into the new issue:
>>
>> Whatever we do to fix this, the end result should be that rendering a shape
>> or control into a cache and then rendering that cached image should match
>> rendering that shape or control directly. This should be true the first time
>> it is rendered, and should remain true as long as the transform is unchanged
>> (or differs only by a translation delta of whole pixel values) from when the
>> cache was rendered into. This is clearly broken for rendering text if the
>> translation is not on a pixel boundary.
>>
>> Which leads into a question you asked.
>>
>>> What is the legitimate result to expect here; should
>>> root.setSnapToPixel(true); override setLayoutX(0.5); and align everything
>>> for crisp rendering? Or am I misunderstanding the scope of setSnapToPixel
>>> and it has no effect when layout is set explicitly?
>>
>> A Pane will not force layoutX and layoutY to be on an integer boundary,
>> since it is documented to not alter the position of any of its children. The
>> subclasses of Pane do layout their children, so snap-to-pixel will take
>> effect. So the fact that the controls in your most recent example are being
>> rendered on a non-pixel boundary is not a bug. The fact that the text is so
>> blurry when rendered from a cached image is a bug (as mentioned above).
>
> For completeness, here is the patch for the snap-to-pixel issue:
>
> diff --git
> a/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java
> b/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java
> index 565d52b516..00c0f6da61 100644
> --- a/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java
> +++ b/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java
> @@ -989,17 +989,11 @@ public class Region extends Parent {
> /** Called to update the cached snapped insets */
> private void updateSnappedInsets() {
> final Insets insets = getInsets();
> -if (_snapToPixel) {
> -snappedTopInset = Math.ceil(insets.getTop());
> -snappedRightInset = Math.ceil(insets.getRight());
> -snappedBottomInset = Math.ceil(insets.getBottom());
> -snappedLeftInset = Math.ceil(insets.getLeft());
> -} else {
> -snappedTopInset = insets.getTop();
> -snappedRightInset = insets.getRight();
> -snappedBottomInset = insets.getBottom();
> -snappedLeftInset = insets.getLeft();
> -}
> +final boolean snap = isSnapToPixel();
> +snappedTopInset = snapSizeY(insets.getTop(), snap);
> +snappedRightInset = snapSizeX(insets.getRight(), snap);
> +snappedBottomInset = snapSizeY(insets.getBottom(), snap);
> +snappedLeftInset = snapSizeX(insets.getLeft(), snap);
> }
>
> /**
>
> We will need a test case for this. You can see
> [UIRenderSceneTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/UIRenderSceneTest.java)
> for an example of a test that forces Hi-DPI scaling.
In looking at the other instances where snap-to-pixel is done correctly for
Insets, the above should use `snapSpace{X,Y}` rather than `snapSize{X,Y}`
-
PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Wed, 16 Dec 2020 00:25:15 GMT, Kevin Rushforth wrote:
>> Thanks for that.
>>
>> I am wondering; is it ok to potentially address both sub-issues discussed
>> here (Scrollpane snaping vs cache rendering) under the same JBS bug? Or
>> would it be better to address them under separate issues?
>>
>> Speaking of which, the JBS issue title is in fact misleading, as the issue
>> appears to be not specific to Windows; what's the best practice in such
>> cases; rename the issue? Open a new one? Leave it as is?
>
>> I am wondering; is it ok to potentially address both sub-issues discussed
>> here (Scrollpane snaping vs cache rendering) under the same JBS bug? Or
>> would it be better to address them under separate issues?
>
> Since both issues -- the snap-to-pixel bug and the rendering of the cached
> image -- are causing blurriness, it could be OK _in principle_ to address
> both of them as part of the same bug fix.
>
> However, in this instance the snap-to-pixel bug has a simple,
> well-understood, and safe solution, while the cached rendering bug isn't
> nearly as simple; there are a couple ways it could be fixed, each with their
> own implications. Given that, I would prefer to address the snap-to-pixel bug
> here (which can easily make jfx16), and file a follow-up bug for the cached
> rendering.
>
>> the JBS issue title is in fact misleading, as the issue appears to be not
>> specific to Windows; what's the best practice in such cases; rename the
>> issue? Open a new one? Leave it as is?
>
> This is easily fixed by renaming the JBS issue, and then updating the PR
> title to match. I'll update the JBS issue now, after which you can update the
> PR title.
>
> Here are some thoughts about the cached rendering, which should find their
> way into the new issue:
>
> Whatever we do to fix this, the end result should be that rendering a shape
> or control into a cache and then rendering that cached image should match
> rendering that shape or control directly. This should be true the first time
> it is rendered, and should remain true as long as the transform is unchanged
> (or differs only by a translation delta of whole pixel values) from when the
> cache was rendered into. This is clearly broken for rendering text if the
> translation is not on a pixel boundary.
>
> Which leads into a question you asked.
>
>> What is the legitimate result to expect here; should
>> root.setSnapToPixel(true); override setLayoutX(0.5); and align everything
>> for crisp rendering? Or am I misunderstanding the scope of setSnapToPixel
>> and it has no effect when layout is set explicitly?
>
> A Pane will not force layoutX and layoutY to be on an integer boundary, since
> it is documented to not alter the position of any of its children. The
> subclasses of Pane do layout their children, so snap-to-pixel will take
> effect. So the fact that the controls in your most recent example are being
> rendered on a non-pixel boundary is not a bug. The fact that the text is so
> blurry when rendered from a cached image is a bug (as mentioned above).
For completeness, here is the patch for the snap-to-pixel issue:
diff --git
a/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java
b/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java
index 565d52b516..00c0f6da61 100644
--- a/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java
+++ b/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java
@@ -989,17 +989,11 @@ public class Region extends Parent {
/** Called to update the cached snapped insets */
private void updateSnappedInsets() {
final Insets insets = getInsets();
-if (_snapToPixel) {
-snappedTopInset = Math.ceil(insets.getTop());
-snappedRightInset = Math.ceil(insets.getRight());
-snappedBottomInset = Math.ceil(insets.getBottom());
-snappedLeftInset = Math.ceil(insets.getLeft());
-} else {
-snappedTopInset = insets.getTop();
-snappedRightInset = insets.getRight();
-snappedBottomInset = insets.getBottom();
-snappedLeftInset = insets.getLeft();
-}
+final boolean snap = isSnapToPixel();
+snappedTopInset = snapSizeY(insets.getTop(), snap);
+snappedRightInset = snapSizeX(insets.getRight(), snap);
+snappedBottomInset = snapSizeY(insets.getBottom(), snap);
+snappedLeftInset = snapSizeX(insets.getLeft(), snap);
}
/**
We will need a test case for this. You can see
[UIRenderSceneTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/UIRenderSceneTest.java)
for an example of a test that forces Hi-DPI scaling.
-
PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Tue, 15 Dec 2020 07:50:53 GMT, Frederic Thevenet wrote: > I am wondering; is it ok to potentially address both sub-issues discussed > here (Scrollpane snaping vs cache rendering) under the same JBS bug? Or would > it be better to address them under separate issues? Since both issues -- the snap-to-pixel bug and the rendering of the cached image -- are causing blurriness, it could be OK _in principle_ to address both of them as part of the same bug fix. However, in this instance the snap-to-pixel bug has a simple, well-understood, and safe solution, while the cached rendering bug isn't nearly as simple; there are a couple ways it could be fixed, each with their own implications. Given that, I would prefer to address the snap-to-pixel bug here (which can easily make jfx16), and file a follow-up bug for the cached rendering. > the JBS issue title is in fact misleading, as the issue appears to be not > specific to Windows; what's the best practice in such cases; rename the > issue? Open a new one? Leave it as is? This is easily fixed by renaming the JBS issue, and then updating the PR title to match. I'll update the JBS issue now, after which you can update the PR title. Here are some thoughts about the cached rendering, which should find their way into the new issue: Whatever we do to fix this, the end result should be that rendering a shape or control into a cache and then rendering that cached image should match rendering that shape or control directly. This should be true the first time it is rendered, and should remain true as long as the transform is unchanged (or differs only by a translation delta of whole pixel values) from when the cache was rendered into. This is clearly broken for rendering text if the translation is not on a pixel boundary. Which leads into a question you asked. > What is the legitimate result to expect here; should > root.setSnapToPixel(true); override setLayoutX(0.5); and align everything for > crisp rendering? Or am I misunderstanding the scope of setSnapToPixel and it > has no effect when layout is set explicitly? A Pane will not force layoutX and layoutY to be on an integer boundary, since it is documented to not alter the position of any of its children. The subclasses of Pane do layout their children, so snap-to-pixel will take effect. So the fact that the controls in your most recent example are being rendered on a non-pixel boundary is not a bug. The fact that the text is so blurry when rendered from a cached image is a bug (as mentioned above). - PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Tue, 15 Dec 2020 02:02:37 GMT, Kevin Rushforth wrote:
>>>
>>>
>>> One more comment: given the quality problems that necessarily arise when
>>> the translation of a cached image is not on an integer boundary, part of
>>> the solution might be to snap the cached image to a pixel boundary as is
>>> done in this PR, but we would need to ensure that this doesn't impact
>>> smooth scrolling of a TextArea.
>>
>> I've done some quick tests with the minimal sample below, and could not
>> notice any performance impact with this patch compared to 15.0.1.
>>
>> java
>> public class TextScroll extends Application {
>>
>> @Override
>> public void start(Stage stage) throws Exception {
>> var textArea = new TextArea();
>> var txt = new
>> File(getClass().getResource("/Scrollpane.java").getFile());
>> textArea.setText(Files.readString(txt.toPath(),
>> StandardCharsets.UTF_8));
>> var root = new ScrollPane(textArea);
>> root.setFitToHeight(true);
>> root.setFitToWidth(true);
>> Scene scene;
>> scene = new Scene(root, 800, 600);
>> stage.setTitle("Scroll test");
>> stage.setScene(scene);
>> stage.show();
>> }
>>
>> public static void main(String[] args) {
>> launch(args);
>> }
>> }
>
> Actually, when I mentioned smooth scrolling, it wasn't performance I was
> thinking of, it was the ability to scroll by fractional pixel amounts, but
> with the default snap-to-pixel enabled, that won't happen anyway.
>
> I'll look into the other questions you raised tomorrow, specifically what we
> might want to do about rendering the cache, and also your question about
> snapToPixel.
>
> As for the specific problem with ScrollPane, I found the cause of that one.
> There is a (long-standing from the look of it) bug in
> [`Region::updateSnappedInsets`](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java#L990).
> It attempts to account for snap-to-pixel, but does so incorrectly, using
> `Math.ceil` without taking screen scaling into account (that is, without
> calling the `snapXxxx` methods). The correct code should be something like:
>
> final boolean snap = isSnapToPixel();
> snappedTopInset = snapSizeY(insets.getTop(), snap);
> snappedRightInset = snapSizeX(insets.getRight(), snap);
> snappedBottomInset = snapSizeY(insets.getBottom(), snap);
> snappedLeftInset = snapSizeX(insets.getLeft(), snap);
>
> This fixes the ScrollPane problem without needing to modify the cached
> rendering code.
Thanks for that.
I am wondering; is it ok to potentially address both sub-issues discussed here
(Scrollpane snaping vs cache rendering) under the same JBS bug? Or would it be
better to address them under separate issues?
Speaking of which, the JBS issue title is in fact misleading, as the issue
appears to be not specific to Windows; what's the best practice in such cases;
rename the issue? Open a new one? Leave it as is?
-
PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Mon, 14 Dec 2020 12:06:37 GMT, Frederic Thevenet
wrote:
>> One more comment: given the quality problems that necessarily arise when the
>> translation of a cached image is not on an integer boundary, part of the
>> solution might be to snap the cached image to a pixel boundary as is done in
>> this PR, but we would need to ensure that this doesn't impact smooth
>> scrolling of a TextArea.
>
>>
>>
>> One more comment: given the quality problems that necessarily arise when the
>> translation of a cached image is not on an integer boundary, part of the
>> solution might be to snap the cached image to a pixel boundary as is done in
>> this PR, but we would need to ensure that this doesn't impact smooth
>> scrolling of a TextArea.
>
> I've done some quick tests with the minimal sample below, and could not
> notice any performance impact with this patch compared to 15.0.1.
>
> java
> public class TextScroll extends Application {
>
> @Override
> public void start(Stage stage) throws Exception {
> var textArea = new TextArea();
> var txt = new
> File(getClass().getResource("/Scrollpane.java").getFile());
> textArea.setText(Files.readString(txt.toPath(),
> StandardCharsets.UTF_8));
> var root = new ScrollPane(textArea);
> root.setFitToHeight(true);
> root.setFitToWidth(true);
> Scene scene;
> scene = new Scene(root, 800, 600);
> stage.setTitle("Scroll test");
> stage.setScene(scene);
> stage.show();
> }
>
> public static void main(String[] args) {
> launch(args);
> }
> }
Actually, when I mentioned smooth scrolling, it wasn't performance I was
thinking of, it was the ability to scroll by fractional pixel amounts, but with
the default snap-to-pixel enabled, that won't happen anyway.
I'll look into the other questions you raised tomorrow, specifically what we
might want to do about rendering the cache, and also your question about
snapToPixel.
As for the specific problem with ScrollPane, I found the cause of that one.
There is a (long-standing from the look of it) bug in
[`Region::updateSnappedInsets`](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java#L990).
It attempts to account for snap-to-pixel, but does so incorrectly, using
`Math.ceil` without taking screen scaling into account (that is, without
calling the `snapXxxx` methods). The correct code should be something like:
final boolean snap = isSnapToPixel();
snappedTopInset = snapSizeY(insets.getTop(), snap);
snappedRightInset = snapSizeX(insets.getRight(), snap);
snappedBottomInset = snapSizeY(insets.getBottom(), snap);
snappedLeftInset = snapSizeX(insets.getLeft(), snap);
This fixes the ScrollPane problem without needing to modify the cached
rendering code.
-
PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Sat, 12 Dec 2020 22:31:56 GMT, Kevin Rushforth wrote:
>
>
> One more comment: given the quality problems that necessarily arise when the
> translation of a cached image is not on an integer boundary, part of the
> solution might be to snap the cached image to a pixel boundary as is done in
> this PR, but we would need to ensure that this doesn't impact smooth
> scrolling of a TextArea.
I've done some quick tests with the minimal sample below, and could not notice
any performance impact with this patch compared to 15.0.1.
java
public class TextScroll extends Application {
@Override
public void start(Stage stage) throws Exception {
var textArea = new TextArea();
var txt = new
File(getClass().getResource("/Scrollpane.java").getFile());
textArea.setText(Files.readString(txt.toPath(),
StandardCharsets.UTF_8));
var root = new ScrollPane(textArea);
root.setFitToHeight(true);
root.setFitToWidth(true);
Scene scene;
scene = new Scene(root, 800, 600);
stage.setTitle("Scroll test");
stage.setScene(scene);
stage.show();
}
public static void main(String[] args) {
launch(args);
}
}
-
PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Sat, 12 Dec 2020 22:31:56 GMT, Kevin Rushforth wrote:
>> I spent a bit of time looking at this. I think the root cause of the problem
>> is in ScrollPane itself. It is attempting to layout its children by doing a
>> snap to pixel (meaning that the final scaled translation should be an
>> integer value), but it is failing to do so. This is mostly not a problem
>> when caching is disabled, since our text rendering does sub-pixel
>> antialiasing that looks crisp even at non-integer boundaries. However,
>> translating an already-rendered image by a non-integer boundary will cause
>> the blurriness we are seeing. There is another issue with the Y translation
>> which isn't 0 even when not using a ScrollPane.
>>
>> I'll continue looking at this in the coming week.
>
> One more comment: given the quality problems that necessarily arise when the
> translation of a cached image is not on an integer boundary, part of the
> solution might be to snap the cached image to a pixel boundary as is done in
> this PR, but we would need to ensure that this doesn't impact smooth
> scrolling of a TextArea.
Further investigations on my part raised one more question, which hopefully you
can answer:
To which extend should `setSnapToPixel` ensure children of a region are indeed
snap to whole pixel coordinates?
To make it clearer, please consider the following sample:
java
public class Blur extends Application {
@Override
public void start(final Stage stage) throws Exception {
var root = new Pane();
root.setSnapToPixel(true);
var ctrl = new CheckBox("Cached");
ctrl.setLayoutX(0.5);
ctrl.setLayoutY(0.5);
ctrl.cacheProperty().bind(ctrl.selectedProperty());
ctrl.setSelected(true);
var ctrl2 = new Button("Foo");
ctrl2.setLayoutX(0.5);
ctrl2.setLayoutY(30.5);
ctrl2.cacheProperty().bind(ctrl.selectedProperty());
var ctrl3 = new Button("Bar");
ctrl3.setLayoutY(60);
ctrl3.cacheProperty().bind(ctrl.selectedProperty());
root.getChildren().addAll(ctrl, ctrl2, ctrl3);
Scene scene;
scene = new Scene(root, 200, 200);
stage.setTitle("Blur test");
stage.setScene(scene);
stage.show();
}
public static void main(String[] args) {
launch(args);
}
}
In this sample, LayoutX and Y properties are deliberately set to non integer
values for the first two controls (the last one serves as a visual baseline,
but `snapToPixel` is set to true. Also clicking the check box toggles caching
for all controls.
Here's what it looks looks **at 100% scaling**, (OpenJFX 15.0.1), with cache
enabled:
and with cache disabled:
What is the legitimate result to expect here; should
`root.setSnapToPixel(true);` override `setLayoutX(0.5);` and align everything
for crisp rendering (as is my understanding)? Or am I misunderstanding the
scope of `setSnapToPixel` and it has no effect when layout is set explicitly?
-
PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Sat, 12 Dec 2020 14:57:05 GMT, Kevin Rushforth wrote: >>> >>> >>> I hope to take a look at this, along with other pending reviews, early next >>> week. There is still some time to get this into 16 if we can find a robust >>> fix. >> >> That's great news, thanks! > > I spent a bit of time looking at this. I think the root cause of the problem > is in ScrollPane itself. It is attempting to layout its children by doing a > snap to pixel (meaning that the final scaled translation should be an integer > value), but it is failing to do so. This is mostly not a problem when caching > is disabled, since our text rendering does sub-pixel antialiasing that looks > crisp even at non-integer boundaries. However, translating an > already-rendered image by a non-integer boundary will cause the blurriness we > are seeing. There is another issue with the Y translation which isn't 0 even > when not using a ScrollPane. > > I'll continue looking at this in the coming week. One more comment: given the quality problems that necessarily arise when the translation of a cached image is not on an integer boundary, part of the solution might be to snap the cached image to a pixel boundary as is done in this PR, but we would need to ensure that this doesn't impact smooth scrolling of a TextArea. - PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Sat, 5 Dec 2020 11:33:46 GMT, Frederic Thevenet wrote: >> I hope to take a look at this, along with other pending reviews, early next >> week. There is still some time to get this into 16 if we can find a robust >> fix. > >> >> >> I hope to take a look at this, along with other pending reviews, early next >> week. There is still some time to get this into 16 if we can find a robust >> fix. > > That's great news, thanks! I spent a bit of time looking at this. I think the root cause of the problem is in ScrollPane itself. It is attempting to layout its children by doing a snap to pixel (meaning that the final scaled translation should be an integer value), but it is failing to do so. This is mostly not a problem when caching is disabled, since our text rendering does sub-pixel antialiasing that looks crisp even at non-integer boundaries. However, translating an already-rendered image by a non-integer boundary will cause the blurriness we are seeing. There is another issue with the Y translation which isn't 0 even when not using a ScrollPane. I'll continue looking at this in the coming week. - PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Fri, 4 Dec 2020 23:41:38 GMT, Kevin Rushforth wrote: > > > I hope to take a look at this, along with other pending reviews, early next > week. There is still some time to get this into 16 if we can find a robust > fix. That's great news, thanks! - PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Fri, 4 Dec 2020 10:46:27 GMT, Frederic Thevenet wrote: >> Not yet. I took a quick look, and this is helpful in pointing out where the >> problem is, but I don't know whether it is the right solution to simply >> round the transform values when rendering the cache to the screen. > > Hi, > > Is there anything I can do to help get this moving forward again? > > As mentioned before, I agree the proposed fix might be simply be addressing > the symptoms rather than the root cause and I'm willing to keep working on it > but I'd really appreciate a second opinion and some insights as to where to > direct my attention if this fix proves to be not enough. > > For what it's worth, I've been living with this fix on my dev machine for a > while now, and it does provide the expected relief to the underlying issue, > without me noticing any obvious regressions, neither visually nor > performance-wise (I haven't run any targeted benchmarks, though). > > With JDK-8199592 fixed, I think it'd be great if we could tackle all of the > scaling issues in 16 (might be getting a bit late now, though) I hope to take a look at this, along with other pending reviews, early next week. There is still some time to get this into 16 if we can find a robust fix. - PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Wed, 21 Oct 2020 12:35:34 GMT, Kevin Rushforth wrote: >> Hello, >> Did anyone get a chance to look into this? >> Thanks! > > Not yet. I took a quick look, and this is helpful in pointing out where the > problem is, but I don't know whether it is the right solution to simply round > the transform values when rendering the cache to the screen. Hi, Is there anything I can do to help get this moving forward again? As mentioned before, I agree the proposed fix might be simply be addressing the symptoms rather than the root cause and I'm willing to keep working on it but I'd really appreciate a second opinion and some insights as to where to direct my attention if this fix proves to be not enough. For what it's worth, I've been living with this fix on my dev machine for a while now, and it does provide the expected relief to the underlying issue, without me noticing any obvious regressions, neither visually nor performance-wise (I haven't run any targeted benchmarks, though). With JDK-8199592 fixed, I think it'd be great if we could tackle all of the scaling issues in 16 (might be getting a bit late now, though) - PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Wed, 21 Oct 2020 07:01:46 GMT, Frederic Thevenet wrote: >>> >>> >>> The visual representation corresponds with digits, so there can be tests >>> that check if the numbers are what we expect them to be. >>> It's good that this is not windows-only, so that it can be tackled on linux >>> as well. But what is not clear to me: does this require a physical HiDPI >>> screen, or is setting the scale factor manually good enough to reproduce >>> the bug? >> >> The issue will appear consistently as long as the conditions I listed are >> met, regardless of the actual number of pixels the physical screen can >> display. >> For instance you'll see the problem, if you apply a 125% scaling on 1080p >> screen (a common configuration on 13'' laptops). >> Also, it will occur regardless of whether the scaling is applied at the OS >> level and picked up by javafx or if it is only set for a single application >> using the `glass.xxx.uiScale` property. > > Hello, > Did anyone get a chance to look into this? > Thanks! Not yet. I took a quick look, and this is helpful in pointing out where the problem is, but I don't know whether it is the right solution to simply round the transform values when rendering the cache to the screen. - PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Fri, 25 Sep 2020 09:32:46 GMT, Frederic Thevenet wrote: >> The visual representation corresponds with digits, so there can be tests >> that check if the numbers are what we expect >> them to be. It's good that this is not windows-only, so that it can be >> tackled on linux as well. But what is not clear >> to me: does this require a physical HiDPI screen, or is setting the scale >> factor manually good enough to reproduce the >> bug? > >> >> >> The visual representation corresponds with digits, so there can be tests >> that check if the numbers are what we expect >> them to be. It's good that this is not windows-only, so that it can be >> tackled on linux as well. But what is not clear >> to me: does this require a physical HiDPI screen, or is setting the scale >> factor manually good enough to reproduce the >> bug? > > The issue will appear consistently as long as the conditions I listed are > met, regardless of the actual number of > pixels the physical screen can display. For instance you'll see the problem, > if you apply a 125% scaling on 1080p > screen (a common configuration on 13'' laptops). Also, it will occur > regardless of whether the scaling is applied at > the OS level and picked up by javafx or if it is only set for a single > application using the `glass.xxx.uiScale` > property. Hello, Did anyone get a chance to look into this? Thanks! - PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Fri, 25 Sep 2020 07:47:41 GMT, Johan Vos wrote: > > > The visual representation corresponds with digits, so there can be tests that > check if the numbers are what we expect > them to be. It's good that this is not windows-only, so that it can be > tackled on linux as well. But what is not clear > to me: does this require a physical HiDPI screen, or is setting the scale > factor manually good enough to reproduce the > bug? The issue will appear consistently as long as the conditions I listed are met, regardless of the actual number of pixels the physical screen can display. For instance you'll see the problem, if you apply a 125% scaling on 1080p screen (a common configuration on 13'' laptops). Also, it will occur regardless of whether the scaling is applied at the OS level and picked up by javafx or if it is only set for a single application using the `glass.xxx.uiScale` property. - PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Fri, 25 Sep 2020 07:47:41 GMT, Johan Vos wrote: >> Also, I don't really have an idea on how this could be tested other than >> visually, so I'm open to suggestions. > > The visual representation corresponds with digits, so there can be tests that > check if the numbers are what we expect > them to be. It's good that this is not windows-only, so that it can be > tackled on linux as well. But what is not clear > to me: does this require a physical HiDPI screen, or is setting the scale > factor manually good enough to reproduce the > bug? FYI: there is another bug [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592) that *reads* somewhat similar even though the issues are very different. It is also marked as a "Windows" bug. Maybe the root of both issues is the same... - PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Thu, 24 Sep 2020 19:09:19 GMT, Frederic Thevenet wrote: >> This PR aims to fix the blurriness to sometimes affects some controls (such >> as TextArea) in a scene when rendered with >> a scaling factor that is not an integer (typically when viewed on a HiDPI >> screen with a 125%, 150% or 175% output >> scaling). Please note that regardless of what the JBS issue (and therefore >> the title of this PR) states, this does not >> appear to be a Windows only issue as I have observed the same issue on Linux >> (Ubuntu 20.04). >> The following conditions are necessary for the blurriness to appear, but do >> not guarantee that it will: >> >> - The node, or one of its parents, must have set `Node::cacheProperty` to >> `true` >> >> - The scaling factor (as detected automatically or explicitly set via >> glass.win/gtk.uiScale) must be a non integer number >> (e.g. 1.25, 1.5, 175) >> >> - The effective layout X or Y coordinates for the cached node must be != 0; >> >> Under these conditions, the translate coordinates for the transform used >> when the cached image for a node is rendered >> to the screen may be non integer numbers, which is the cause for the >> blurriness. >> Based on these observations, this PR fixes the issue by simply rounding the >> translate coordinates (using `Math.round`) >> before the transform is applied in `renderCacheToScreen()` and as far as I >> can tell, it fixes the blurriness in all the >> previously affected applications (both trivial test cases or with complex >> scenegraphs) and does not appear to introduce >> other noticeable visual artifacts. Still, there might be a better place >> somewhere else higher up in the call chain >> where this should be addressed as it could maybe be the root cause for other >> rendering glitches, though I'm not yet >> familiar enough with the code to see if it is really the case. > > Also, I don't really have an idea on how this could be tested other than > visually, so I'm open to suggestions. The visual representation corresponds with digits, so there can be tests that check if the numbers are what we expect them to be. It's good that this is not windows-only, so that it can be tackled on linux as well. But what is not clear to me: does this require a physical HiDPI screen, or is setting the scale factor manually good enough to reproduce the bug? - PR: https://git.openjdk.java.net/jfx/pull/308
Re: RFR: 8211294: [windows] TextArea content is blurry with 125% scaling
On Thu, 24 Sep 2020 18:57:13 GMT, Frederic Thevenet wrote: > This PR aims to fix the blurriness to sometimes affects some controls (such > as TextArea) in a scene when rendered with > a scaling factor that is not an integer (typically when viewed on a HiDPI > screen with a 125%, 150% or 175% output > scaling). Please note that regardless of what the JBS issue (and therefore > the title of this PR) states, this does not > appear to be a Windows only issue as I have observed the same issue on Linux > (Ubuntu 20.04). > The following conditions are necessary for the blurriness to appear, but do > not guarantee that it will: > > - The node, or one of its parents, must have set `Node::cacheProperty` to > `true` > > - The scaling factor (as detected automatically or explicitly set via > glass.win/gtk.uiScale) must be a non integer number > (e.g. 1.25, 1.5, 175) > > - The effective layout X or Y coordinates for the cached node must be != 0; > > Under these conditions, the translate coordinates for the transform used when > the cached image for a node is rendered > to the screen may be non integer numbers, which is the cause for the > blurriness. > Based on these observations, this PR fixes the issue by simply rounding the > translate coordinates (using `Math.round`) > before the transform is applied in `renderCacheToScreen()` and as far as I > can tell, it fixes the blurriness in all the > previously affected applications (both trivial test cases or with complex > scenegraphs) and does not appear to introduce > other noticeable visual artifacts. Still, there might be a better place > somewhere else higher up in the call chain > where this should be addressed as it could maybe be the root cause for other > rendering glitches, though I'm not yet > familiar enough with the code to see if it is really the case. Also, I don't really have an idea on how this could be tested other than visually, so I'm open to suggestions. - PR: https://git.openjdk.java.net/jfx/pull/308
