Please review the fix for: JDK -8220012 Accordion control doesn't keeps
reference to child pane after it is removed
https://bugs.openjdk.java.net/browse/JDK-8220012
https://github.com/javafxports/openjdk-jfx/issues/391
Hi,
A change was introduced In JDK-8264770 that swaps the use of
ChangeListeners to InvalidationListeners within the internal
implementation of BidirectionalBinding [1].
While this change shouldn't normally affect third party applications, it
turned out to break the scrolling facilities used
On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strauß wrote:
> This PR fixes a bug that was introduced in #454.
>
> Since this fix might impact the performance considerations in the original
> PR, I ran a performance benchmark against the previous `ChangeListener`-based
> implementation, which stil
On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strauß wrote:
> This PR fixes a bug that was introduced in #454.
>
> Since this fix might impact the performance considerations in the original
> PR, I ran a performance benchmark against the previous `ChangeListener`-based
> implementation, which stil
On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strauß wrote:
> This PR fixes a bug that was introduced in #454.
>
> Since this fix might impact the performance considerations in the original
> PR, I ran a performance benchmark against the previous `ChangeListener`-based
> implementation, which stil
In this precise case, it is kCGLPFAAccelerated
Regards
Frederic Thevenet
-Original Message-
From: Sergey Bylokhov [mailto:[email protected]]
Sent: 03 December 2019 21:20
To: [email protected]; openjfx-dev
Subject: Re: Blank stages when running JavaFX app in a macOS virtual
https://bugs.openjdk.java.net/browse/JDK-8235627
-
Commits:
- 73523680: 8235627: Fixed blank stage when running in macOS guest VM
Changes: https://git.openjdk.java.net/jfx/pull/65/files
Webrev: https://webrevs.openjdk.java.net/jfx/65/webrev.00
Issue: https://bugs.openjdk.java.net
This PR aims to address the following issue: JDK-8088198 Exception thrown from
snapshot if dimensions are larger than max texture size
In order to do that, it simply captures snapshots in multiple tiles of
maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the
tiles into
On Fri, 20 Dec 2019 09:55:18 GMT, Ambarish Rapte wrote:
>> modules/javafx.graphics/src/main/native-glass/mac/GlassView3D.m line 97:
>>
>>> 96: if (pix == NULL)
>>> 97: {
>>> 98: const CGLPixelFormatAttribute attributes2[] =
>>
>> The change looks good.
>> I would sug
On Fri, 20 Dec 2019 10:05:48 GMT, Ambarish Rapte wrote:
>> As mentioned in the description of
>> [JDK-8235627](https://bugs.openjdk.java.net/browse/JDK-8235627), following
>> error is printed
>> CGLChoosePixelFormat error: 10002
>>
>> According to the documentation at [CGL Error
>> Codes](ht
On Fri, 20 Dec 2019 13:50:16 GMT, Kevin Rushforth wrote:
>> From the documentation, the check `pix == NULL` seems sufficient, but the
>> `err != kCGLNoError` was used before, so I just want to keep it safe. If the
>> issue occurs without error getting printed it will be difficult to trace. As
On Fri, 20 Dec 2019 14:06:30 GMT, Kevin Rushforth wrote:
>> It looks good then, please update PR without `err != kCGLNoError`
>
> Something like this, maybe?
>
> if (pix == NULL) {
> NSLog(@"CGLChoosePixelFormat: unable to find a pixel format, trying
> again with reduced capabiliti
> This is a PR for
> [JDK-8235627](https://bugs.openjdk.java.net/browse/JDK-8235627).
>
> When running a JavaFX application in macOS guest VM, the main stage is
> completely blank, with the following errors: CGLChoosePixelFormat error:
> 10002, CGLCreateContext error: 10002
> This behavior was
> This is a PR for
> [JDK-8235627](https://bugs.openjdk.java.net/browse/JDK-8235627).
>
> When running a JavaFX application in macOS guest VM, the main stage is
> completely blank, with the following errors: CGLChoosePixelFormat error:
> 10002, CGLCreateContext error: 10002
> This behavior was
On Fri, 20 Dec 2019 17:37:36 GMT, Kevin Rushforth wrote:
>> This PR aims to address the following issue: JDK-8088198 Exception thrown
>> from snapshot if dimensions are larger than max texture size
>>
>> In order to do that, it simply captures snapshots in multiple tiles of
>> maxTextureSize^2
> This PR aims to address the following issue: JDK-8088198 Exception thrown
> from snapshot if dimensions are larger than max texture size
>
> In order to do that, it simply captures snapshots in multiple tiles of
> maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the
>
On Fri, 20 Dec 2019 17:55:04 GMT, Frederic Thevenet
wrote:
>> This will need two reviewers. I want to review it, and I request @arapte to
>> also review.
>>
>> I won't have time to do a detailed review until the new year. One quick
>> comment: in addition
On Thu, 16 Jan 2020 11:56:10 GMT, Michael Paus wrote:
>> Assuming `Nb` in `verticalTileNb` stands for number, I would recommend to
>> change the names as `numVerticalTiles` and `numHorizontalTiles`
>
> I think the proposed code changes are wrong in case that `height /
> maxTextureSize` is an e
> This PR aims to address the following issue: JDK-8088198 Exception thrown
> from snapshot if dimensions are larger than max texture size
>
> In order to do that, it simply captures snapshots in multiple tiles of
> maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the
>
On Thu, 16 Jan 2020 10:58:12 GMT, Ambarish Rapte wrote:
>> The pull request has been updated with 1 additional commit.
>
> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1312:
>
>> 1311: int tileWidth = Math.min(maxTextureSize, width -
>> xOffset);
>> 13
On Thu, 16 Jan 2020 10:47:26 GMT, Ambarish Rapte wrote:
>> The pull request has been updated with 1 additional commit.
>
> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1303:
>
>> 1302: if (height > maxTextureSize || width > maxTextureSize) {
>> 1303: //
On Thu, 16 Jan 2020 14:26:24 GMT, Kevin Rushforth wrote:
>> I think it is not worth it.
>
> I agree. I do like the suggestion to rename the variables, though.
done in 501917284e0490d16b1831fcd854e31a779449b9
-
PR: https://git.openjdk.java.net/jfx/pull/68
On Thu, 16 Jan 2020 17:00:32 GMT, Nir Lisker wrote:
>> The pull request has been updated with 2 additional commits.
>
> I tested this fix against the repro code in
> https://github.com/javafxports/openjdk-jfx/issues/433 (which is
> [JDK-838](https://bugs.openjdk.java.net/browse/JDK-838
> This PR aims to address the following issue: JDK-8088198 Exception thrown
> from snapshot if dimensions are larger than max texture size
>
> In order to do that, it simply captures snapshots in multiple tiles of
> maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the
>
On Thu, 16 Jan 2020 16:08:05 GMT, Nir Lisker wrote:
>> The pull request has been updated with 2 additional commits.
>
> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1316:
>
>> 1315: }
>> 1316: }
>> 1317: } else {
>
> I would extract thi
On Fri, 17 Jan 2020 11:28:03 GMT, Frederic Thevenet
wrote:
>> I tested this fix against the repro code in
>> https://github.com/javafxports/openjdk-jfx/issues/433 (which is
>> [JDK-838](https://bugs.openjdk.java.net/browse/JDK-838)), but there
>> is still an N
On Mon, 20 Jan 2020 05:06:50 GMT, Ambarish Rapte wrote:
>> The pull request has been updated with 2 additional commits.
>
> Looks good to me.
> Below is just an observation about time taken by the API,
> Platform: Windows10, `maxTextureSize`: 4096
> For a snapshot of (4096 * n, 4096 * n): each
On Tue, 21 Jan 2020 21:53:29 GMT, Kevin Rushforth wrote:
>>>
>>>
>>> Looks good to me.
>>> Below is just an observation about time taken by the API,
>>> Platform: Windows10, `maxTextureSize`: 4096
>>> For a snapshot of (4096 * n, 4096 * n): each call to `doSnapshotTile()`
>>> takes ~100 ms, an
On Fri, 24 Jan 2020 15:55:50 GMT, Frederic Thevenet
wrote:
>> I haven't done any testing yet, but I have two comments on the patch:
>>
>> 1. Using the clamped texture size as the upper limit is the right thing to
>> do, but `Prism.maxTexture` isn'
On Fri, 24 Jan 2020 16:03:39 GMT, Frederic Thevenet
wrote:
>> I've put together a small benchmark to measure the time it takes to
>> snapshots into images of sizes varying from 1024*1024 to 8192*8192, by
>> increment of 1024 in each dimension, which you can find here:
On Fri, 24 Jan 2020 16:34:29 GMT, Nir Lisker wrote:
>> And here are the results with the change in this PR, on the same machine
>> under Windows 10:
>>
>> || 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |
>> |---|---|---|---|---|---|---|---|---|
>> | 1024 | 6.957774 | 10.461498 | 14.72102
On Fri, 24 Jan 2020 16:55:47 GMT, Frederic Thevenet
wrote:
>>> Here are the results when running JavaFX 14-ea+7.
>>> The columns of the table correspond the width of the target snapshot, while
>>> the rows correspond to the height and the content of the cells is t
On Sat, 25 Jan 2020 20:24:54 GMT, Nir Lisker wrote:
>>> profiling a run of the benchmark shows that a lot of time is spent into
>>> `IntTo4ByteSameConverter::doConvert`
>>
>> This is a bit naive, but what if you parallelize the code there? I didn't
>> test that this produces the correct result
On Sun, 26 Jan 2020 11:40:06 GMT, Frederic Thevenet
wrote:
>>> the `WriteableImage` used to collate the tiles and the tiles returned from
>>> the `RTTexture` have different pixel formats (`IntARGB` for the tile and
>>> `byteBGRA` for the `WriteableImage`).
>
On Mon, 27 Jan 2020 15:30:27 GMT, Kevin Rushforth wrote:
>> I would be very cautious of using multi-threading here. In any case, I think
>> that the issues around absolute performance could be handled separately.
>>
>> Having said that, given my review comments, along with the concerns over
>>
> This PR aims to address the following issue: JDK-8088198 Exception thrown
> from snapshot if dimensions are larger than max texture size
>
> In order to do that, it simply captures snapshots in multiple tiles of
> maxTextureSize^2 dimensions (or less, as needed), and then recomposes all the
>
On Mon, 27 Jan 2020 18:45:17 GMT, Frederic Thevenet
wrote:
>> I thought of one possibility that might be worth looking into for a short
>> term fix (i.e., could still go into openjfx14). Rather than relying on
>> `PrismSettings.maxTextureSize` you could instead try to
On Wed, 29 Jan 2020 16:33:16 GMT, Nir Lisker wrote:
>> The code changes look good to me. As long as you are willing to address the
>> follow-on issues for openjfx15, I'll approve this PR for openjfx14, once I
>> run my last test.
>>
>> I did a fair bit of testing of the functionality, which re
On Thu, 30 Jan 2020 08:15:39 GMT, Ambarish Rapte wrote:
>> The pull request has been updated with 1 additional commit.
>
> With my basic testing, the change looks good, scaled up and scaled down
> snapshots seem correct visually.
>
> After this change the tiled snapshot will be limited by dime
On Fri, 31 Jan 2020 13:01:51 GMT, Kevin Rushforth wrote:
>> Since @kevinrushforth and @arapte have completed their review, is this ready
>> to integrate?
>> I'm a little confused by the fact this has both `rfr` and `ready` labels
>> attached; is this an expected behaviour?
>
> Yes, this is rea
On Wed, 12 Feb 2020 13:21:03 GMT, Frederic Thevenet
wrote:
> Issue JDK-8088198, where an exception would be thrown when trying to capture
> a snapshot whose final dimensions would be larger than the running platform's
> maximum supported texture size, was addressed in openjf
Issue JDK-8088198, where an exception would be thrown when trying to capture a
snapshot whose final dimensions would be larger than the running platform's
maximum supported texture size, was addressed in openjfx14.
The fix, based around the idea of capturing as many tiles of the maximum
possible
On Wed, 12 Feb 2020 14:57:33 GMT, Frederic Thevenet
wrote:
>> Issue JDK-8088198, where an exception would be thrown when trying to capture
>> a snapshot whose final dimensions would be larger than the running
>> platform's maximum supported texture size, was addressed i
> Issue JDK-8088198, where an exception would be thrown when trying to capture
> a snapshot whose final dimensions would be larger than the running platform's
> maximum supported texture size, was addressed in openjfx14.
> The fix, based around the idea of capturing as many tiles of the maximum
On Fri, 6 Mar 2020 08:28:34 GMT, Ambarish Rapte wrote:
>> The pull request has been updated with 1 additional commit.
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java
> line 1527:
>
>> 1526: private int computeOptimumTileSize(int size, int maxS
On Sun, 8 Mar 2020 12:47:52 GMT, Nir Lisker wrote:
>> The pull request has been updated with 1 additional commit.
>
> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1296:
>
>> 1295: int width = Math.max(xMax - xMin, 1);
>> 1296: int height = Math.max(yMax - yM
> Issue JDK-8088198, where an exception would be thrown when trying to capture
> a snapshot whose final dimensions would be larger than the running platform's
> maximum supported texture size, was addressed in openjfx14.
> The fix, based around the idea of capturing as many tiles of the maximum
On Tue, 10 Mar 2020 06:05:53 GMT, Ambarish Rapte wrote:
>> I finally got a chance to do some more extensive testing when running this
>> patch with the es2 pipeline on Linux.
>> It works as expected, and from what I saw, using a IntARGB pixelBuffer when
>> no WritableImage is provided avoids
>>
On Tue, 10 Mar 2020 10:29:11 GMT, Frederic Thevenet
wrote:
>> On My windows10 machine, I can observe 20 to 30 % reduction in time to take
>> snapshot.
>> Can you please capture the time the way you did
>> [here](https://github.com/openjdk/jfx/pull/68#issuecomment-57819
On Tue, 10 Mar 2020 10:29:31 GMT, Frederic Thevenet
wrote:
>> ### 14-ea+9
>>
>>
>> || 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |9216 |
>> |---|---|---|---|---|---|---|---|---|---|
>> | 1024 | 5.607827 | 9.380503 | 13.835523 | 17.514362 | 2
On Tue, 10 Mar 2020 10:29:38 GMT, Frederic Thevenet
wrote:
>> ### 14-internal
>>
>>
>> || 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |9216 |
>> |---|---|---|---|---|---|---|---|---|---|
>> | 1024 | 5.740508 | 9.337537 | 13.489849
On Tue, 10 Mar 2020 11:13:54 GMT, Frederic Thevenet
wrote:
>> ### 15-internal:
>>
>>
>> || 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |9216 |
>> |---|---|---|---|---|---|---|---|---|---|
>> | 1024 | 5.381051 | 9.261115 | 14.033219
iling is
> necessary while still introducing no regressions compared to the original
> solution.
Frederic Thevenet has updated the pull request incrementally with one
additional commit since the last revision:
Fixed code style and typo following review.
-
Changes:
-
On Fri, 13 Mar 2020 17:26:35 GMT, Ambarish Rapte wrote:
>> Frederic Thevenet has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Avoid useless width and height calculation
>
> modules/javafx.graphics/src/main/
On Fri, 13 Mar 2020 17:24:02 GMT, Ambarish Rapte wrote:
>> Frederic Thevenet has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Avoid useless width and height calculation
>
> modules/javafx.graphics/src/main/
iling is
> necessary while still introducing no regressions compared to the original
> solution.
Frederic Thevenet has updated the pull request incrementally with one
additional commit since the last revision:
Revert changes in import statements
-
Changes:
- all: https://g
On Tue, 17 Mar 2020 13:28:57 GMT, Nir Lisker wrote:
>
>
> Now that the tiling is done in the `QuantumRenderer` level, I'll bring back
> [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082). Can't this
> tiling be used to fix that?
It won't help with thing in their current state, as
On Tue, 17 Mar 2020 14:19:45 GMT, Frederic Thevenet
wrote:
>> Now that the tiling is done in the `QuantumRenderer` level, I'll bring back
>> [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082). Can't this
>> tiling be used to fix that?
>
>>
On Tue, 17 Mar 2020 15:31:20 GMT, Frederic Thevenet
wrote:
>>>
>>>
>>> Now that the tiling is done in the `QuantumRenderer` level, I'll bring back
>>> [JDK-8189082](https://bugs.openjdk.java.net/browse/JDK-8189082). Can't this
>>> tilin
On Mon, 11 May 2020 15:30:28 GMT, Nir Lisker wrote:
>> Frederic Thevenet has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert changes in import statements
>
> modules/javafx.graphics/src/main/
On Sat, 9 May 2020 17:28:52 GMT, Kevin Rushforth wrote:
>> Frederic Thevenet has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert changes in import statements
>
> modules/javafx.graphics/src/main/
iling is
> necessary while still introducing no regressions compared to the original
> solution.
Frederic Thevenet has updated the pull request incrementally with three
additional commits since the last revision:
- Use boolean[] instead of AtomicBoolean to effec pass-by-reference
- Fixed
iling is
> necessary while still introducing no regressions compared to the original
> solution.
Frederic Thevenet has updated the pull request incrementally with one
additional commit since the last revision:
Revert changes to import statements
-
Changes:
- all: https://g
iling is
> necessary while still introducing no regressions compared to the original
> solution.
Frederic Thevenet has updated the pull request incrementally with one
additional commit since the last revision:
Changed tile walking logic
-
Changes:
- all: https://g
On Sat, 16 May 2020 14:20:10 GMT, Kevin Rushforth wrote:
>>>
>>>
>>> Overall, this looks quite good. In particular the tiled rendering, as
>>> implemented by the `renderTile` method, should be
>>> reasonably efficient.
>>> My only high-level comment is that I'm somewhat skeptical of
>>> `comp
On Sat, 9 May 2020 17:43:08 GMT, Kevin Rushforth wrote:
> [...] I'd like to see some additional system tests that cover all of the
> cases of X and Y fitting/not-fitting exactly
> (and if you stick with your current approach, X or Y as the inner loop).
What kind of tests do you have in mind? Mo
iling is
> necessary while still introducing no regressions compared to the original
> solution.
Frederic Thevenet has updated the pull request incrementally with one
additional commit since the last revision:
Added tiled snapshots tests
-
Changes:
- all: https://g
On Mon, 15 Jun 2020 15:55:25 GMT, Frederic Thevenet
wrote:
>> Overall, this looks quite good. In particular the tiled rendering, as
>> implemented by the `renderTile` method, should be
>> reasonably efficient.
>> My only high-level comment is that I
iling is
> necessary while still introducing no regressions compared to the original
> solution.
Frederic Thevenet has updated the pull request incrementally with one
additional commit since the last revision:
Removed trailing whitespaces
-
Changes:
- all: https://g
iling is
> necessary while still introducing no regressions compared to the original
> solution.
Frederic Thevenet has updated the pull request incrementally with one
additional commit since the last revision:
Changed wrong value for image size (for these tests we *don't* want it to
iling is
> necessary while still introducing no regressions compared to the original
> solution.
Frederic Thevenet has updated the pull request incrementally with one
additional commit since the last revision:
Crawling pixels in writableImage with parallel stream is a bad idea.
On Mon, 29 Jun 2020 14:02:11 GMT, Ambarish Rapte wrote:
>> I went ahead and wrote a bunch of tests that:
>> 1. Setup a scene to display an `ImageView` of a selected dimensions chosen
>> to trigger tiling in different ways when
>> taking snapshots. 2. Fill up the image with noise.
>> 3. Take a sn
iling is
> necessary while still introducing no regressions compared to the original
> solution.
Frederic Thevenet has updated the pull request incrementally with one
additional commit since the last revision:
Fill test image with a bilinear gradient instead of random noise.
On Mon, 29 Jun 2020 14:35:00 GMT, Frederic Thevenet
wrote:
>> I observed that the added tests are failing on mac machine(Mojave 10.14.6),
>> but they do pass on windows10. Can you
>> please verify ? Timeout and Unrecognized Image loader errors from the log,
>> test.ja
On Mon, 29 Jun 2020 16:16:58 GMT, Frederic Thevenet
wrote:
>> Thanks for your review.
>>
>> I don't have access to a Mac so I can't check that directly.
>> The tests pass on both my Windows 10 and Ubuntu 20.04 environments and the
>> stack isn&#x
On Mon, 29 Jun 2020 21:32:33 GMT, Kevin Rushforth wrote:
>> Frederic Thevenet has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fill test image with a bilinear gradient instead of random noise.
>
> modules
On Mon, 29 Jun 2020 22:46:26 GMT, Kevin Rushforth wrote:
>> I think I found the problem in the tiling logic that leads to the macOS
>> failures. You need to check that the remainder
>> width or height is > 0. Also, it looks like you have the "B" and "R" loops
>> backwards, which is a bit confus
ing no regressions compared to the original
> solution.
Frederic Thevenet has updated the pull request incrementally with one
additional commit since the last revision:
Prevent attempt to render tiles with a 0 sized dimension.
-
Changes:
- all: https://git.openjdk.java.net/jf
On Tue, 30 Jun 2020 21:22:14 GMT, Ambarish Rapte wrote:
>> Frederic Thevenet has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Prevent attempt to render tiles with a 0 sized dimension.
>
> modules/javafx.
iling is
> necessary while still introducing no regressions compared to the original
> solution.
Frederic Thevenet has updated the pull request incrementally with one
additional commit since the last revision:
- Removed unused imports in Snapshot2Test
- Fixed comments in Q
On Wed, 1 Jul 2020 13:42:12 GMT, Ambarish Rapte wrote:
>> Frederic Thevenet has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> - Removed unused imports in Snapshot2Test
>> - Fixed comments in QuantumTool
iling is
> necessary while still introducing no regressions compared to the original
> solution.
Frederic Thevenet has updated the pull request incrementally with two
additional commits since the last revision:
- Mark variables as final
- Using for loops instead of while
On Wed, 12 Feb 2020 13:21:03 GMT, Frederic Thevenet
wrote:
> Issue JDK-8088198, where an exception would be thrown when trying to capture
> a snapshot whose final dimensions would be
> larger than the running platform's maximum supported texture size, was
> addressed in o
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 (an
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%,
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
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
>>
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 trans
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.jav
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
>> in
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
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
endering glitches, though I'm not yet familiar enough with the code to
> see if it is really the case.
Frederic Thevenet has updated the pull request incrementally with two
additional commits since the last revision:
- Fixed region doesn't account for screen scalling when enforcing
On Wed, 16 Dec 2020 00:42:24 GMT, Kevin Rushforth wrote:
>> 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
>>
On Wed, 16 Dec 2020 12:55:49 GMT, Frederic Thevenet
wrote:
>> 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}`
>
> I agree that it is better to separate the scrollpane is
On Wed, 16 Dec 2020 13:36:27 GMT, Kevin Rushforth wrote:
>> I was thinking, while I'm at it I might as well update the copyright notice
>> for Region.java; should it be 2020 or 2021 (or left alone)?
>
> That file was modified earlier in the year without the copyright year being
> updated, so it
On Wed, 16 Dec 2020 16:39:37 GMT, Kevin Rushforth wrote:
>
>
> Good catch. Yes, `TextFlow` has the same problem, and ought to be fixed as
> part of this, probably by deleting that method and using the public methods
> in Region. It seems wholly unnecessary to use the copied method, since the
On Wed, 16 Dec 2020 17:24:10 GMT, Kevin Rushforth wrote:
>>>
>>>
>>> Good catch. Yes, `TextFlow` has the same problem, and ought to be fixed as
>>> part of this, probably by deleting that method and using the public methods
>>> in Region. It seems wholly unnecessary to use the copied method,
endering glitches, though I'm not yet familiar enough with the code to
> see if it is really the case.
Frederic Thevenet has updated the pull request incrementally with one
additional commit since the last revision:
computeChildArea methods in TextFlow should take screen scalin
On Wed, 16 Dec 2020 18:14:42 GMT, Frederic Thevenet
wrote:
>> Region is part of the public API, so any change to increase the visibility
>> of fields or methods would require a new enhancement with a CSR and
>> justification as to why it is needed as public API. We wou
1 - 100 of 114 matches
Mail list logo
