Re: Proposal for Enhancement to PixelBuffer/WritableImage to support pixelScale
ok answering my own question it is quite simple using setFitWidth/setFitHeight already today. ImageView renderingView renderingView.setFitWidth(width / scaleFactor); renderingView.setFitHeight(height / scaleFactor); I already tested that before sending out this mail but unfortunately it did not work because I had a reflection effect on the parent node and it took the whole day to track down that I run a bug with the Reflection-Effect I documented at [1]. Tom [1] https://bugs.openjdk.java.net/browse/JDK-8278170 Am 02.12.21 um 11:35 schrieb Tom Schindl: Hi, I'm try to get a HiDPI-Image produced by an external application into JavaFX using WritableImage. In the end the situation is comparable to what you get today when loading an image from an URL (eg sam...@2.png) where JavaFX sets the appropriate image pixelScale on "com.sun.prism.Image". If I'm not completely mistaken I would need an new API on PixelBuffer to containing the pixelScale who is used QuantumImage to create an appropriate "com.sun.prism.Image" who has eg the pixelScale = 2.0 because I fed in a HiDPI-Image already. Before filing an ehancement I wanted to bring this up here because maybe I'm missing something obvious or maybe my proposal makes totally no sense. Tom
Re: RFR: 8276313: ScrollPane scroll delta incorrectly depends on content height [v3]
> This PR fixes an issue where the scroll delta of ScrollPane incorrectly > depends on the size of its content. > This leads to extremely slow scrolling when the content is only slightly > larger than the ScrollPane. Michael Strauß has updated the pull request incrementally with one additional commit since the last revision: Changes per review - Changes: - all: https://git.openjdk.java.net/jfx/pull/660/files - new: https://git.openjdk.java.net/jfx/pull/660/files/147858d7..6b8985f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=660=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx=660=01-02 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/660.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/660/head:pull/660 PR: https://git.openjdk.java.net/jfx/pull/660
Re: RFR: 8276313: ScrollPane scroll delta incorrectly depends on content height [v2]
On Thu, 2 Dec 2021 21:51:59 GMT, Kevin Rushforth wrote: >> Michael Strauß has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Handle division by zero > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ScrollPaneSkin.java > line 895: > >> 893: double vRange = >> getSkinnable().getVmax()-getSkinnable().getVmin(); >> 894: double vPixelValue = vRange / (nodeHeight - >> contentHeight); >> 895: vPixelValue = Double.isFinite(vPixelValue) ? >> vPixelValue : 0.0; > > I liked the previous logic better and would have just changed the comparison > to check `(nodeHeight - contentHeight) > 0.0` (possibly saving the adjusted > width or height in a local various to avoid doing it twice). As it is, this > is replacing an explicit check on the source values with an out of range > check on the result, which seems less intuitive. Also, the previous code did > a `> 0` test and the new code effectively does a `!= 0` test. I changed it to check the denominator values instead. - PR: https://git.openjdk.java.net/jfx/pull/660
Re: RFR: 8276170: Create Sources when publishing to Maven
On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote: > Create sources.jars and attach they to the publish task, so that they can be > uploaded to the (e.g. maven) repository automatically. As discussed in the bug report, it isn't at all clear that we should do this. @johanvos can make the call on this. - PR: https://git.openjdk.java.net/jfx/pull/657
Re: RFR: 8276167: fixing VirtualFlow.scrollToTop(int)
On Fri, 29 Oct 2021 12:19:40 GMT, eduardsdv wrote: > Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last > element but to the bottom of the last element. Hi, please send me an e-Mail at dalibor.to...@oracle.com and I can help with the verification process. - PR: https://git.openjdk.java.net/jfx/pull/656
RFR: 8276167: fixing VirtualFlow.scrollToTop(int)
Fix VirtualFlow.scrollToTop(int) doesn't scroll to the top of the last element but to the bottom of the last element. - Commit messages: - JDK-8276167: fixing VirtualFlow.scrollToTop(int) Changes: https://git.openjdk.java.net/jfx/pull/656/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=656=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276167 Stats: 3 lines in 3 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/656.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/656/head:pull/656 PR: https://git.openjdk.java.net/jfx/pull/656
Re: RFR: 8276170: Create Sources when publishing to Maven
On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote: > Create sources.jars and attach they to the publish task, so that they can be > uploaded to the (e.g. maven) repository automatically. I wonder how the sources for the official maven release are generated? https://repo1.maven.org/maven2/org/openjfx/javafx-graphics/17/ The official release contains all the sources, but when we build it from source, these files are missing. - PR: https://git.openjdk.java.net/jfx/pull/657
RFR: 8276170: Create Sources when publishing to Maven
Create sources.jars and attach they to the publish task, so that they can be uploaded to the (e.g. maven) repository automatically. - Commit messages: - 8276170: Remove trailing whitespaces - JDK-8276170: Create Sources when publishing to Maven Changes: https://git.openjdk.java.net/jfx/pull/657/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=657=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276170 Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/657.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/657/head:pull/657 PR: https://git.openjdk.java.net/jfx/pull/657
Integrated: 8272118: ListViewSkin et al: must not cancel edit on scrolling
On Thu, 25 Nov 2021 15:46:01 GMT, Jeanette Winzenburg wrote: > Issue was that mouse pressed on the scrollbars of all virtualized controls > cancelled the edit. That's inconsistent with other scroll triggers > (mouseWheel, programmatic). Fixed by removing the cancel. > > Added tests that failed/passed before/after the fix. Also added tests that > passed both before/after to guarantee that required functionality of the > mouse pressed (= requesting focus on the control if needed) is still working. This pull request has now been integrated. Changeset: aa045c5e Author:Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/aa045c5e60f9566748b55d745d162d0c94ba5e59 Stats: 594 lines in 6 files changed: 566 ins; 28 del; 0 mod 8272118: ListViewSkin et al: must not cancel edit on scrolling Reviewed-by: aghaisas, kcr - PR: https://git.openjdk.java.net/jfx/pull/682
Re: RFR: 8272118: ListViewSkin et al: must not cancel edit on scrolling
On Thu, 2 Dec 2021 00:18:37 GMT, Kevin Rushforth wrote: >> Issue was that mouse pressed on the scrollbars of all virtualized controls >> cancelled the edit. That's inconsistent with other scroll triggers >> (mouseWheel, programmatic). Fixed by removing the cancel. >> >> Added tests that failed/passed before/after the fix. Also added tests that >> passed both before/after to guarantee that required functionality of the >> mouse pressed (= requesting focus on the control if needed) is still working. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/EditAndScrollTest.java > line 408: > >> 406: >> 407: >> 408: //- Utility methods (TODO: move into infrastructure) > > Can you file a follow-up issue for this? yeah, sure - was undecided whether to do it here or later (locally, there are more that will be added for fixing related issues) - [JDK-8278134](https://bugs.openjdk.java.net/browse/JDK-8278134) - PR: https://git.openjdk.java.net/jfx/pull/682
Proposal for Enhancement to PixelBuffer/WritableImage to support pixelScale
Hi, I'm try to get a HiDPI-Image produced by an external application into JavaFX using WritableImage. In the end the situation is comparable to what you get today when loading an image from an URL (eg sam...@2.png) where JavaFX sets the appropriate image pixelScale on "com.sun.prism.Image". If I'm not completely mistaken I would need an new API on PixelBuffer to containing the pixelScale who is used QuantumImage to create an appropriate "com.sun.prism.Image" who has eg the pixelScale = 2.0 because I fed in a HiDPI-Image already. Before filing an ehancement I wanted to bring this up here because maybe I'm missing something obvious or maybe my proposal makes totally no sense. Tom
