Re: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException [v6]
On Tue, 30 Jun 2020 23:05:40 GMT, Kevin Rushforth wrote: >> Robert Lichtenberger has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8176270: Adding ChangeListener to TextField.selectedTextProperty causes >> StringOutOfBoundsException >> >> Move replaceSelectionAtEndWithListener test to general test class. >> Add a more general test for selection/text properties and >> replace/undo/redo operations. > > modules/javafx.controls/src/main/java/javafx/scene/control/TextInputControl.java > line 186: > >> 185: int length = txt.length(); >> 186: if (end > start + length) end = length; >> 187: if (start > length-1) start = end = 0; > > As I mentioned in [this comment in PR > #73](https://github.com/openjdk/jfx/pull/73#discussion_r376528686), I think > this > test is wrong. The value of `start` has no impact on whether `end` is out of > range. So... shouldn't this simply be `if > (end > length) end = length;` ? You're right. The whole point of the fix was to remove the need for any clamping by preventing the "in-between" updates of the selected text property. I've checked that the condition in line 186 is never fulfilled now anymore and removed it. I've also removed the clamping in the line below, because the only case where start > length-1 is now that start == length in which case also end == length and txt.substring(length, length) will be just as empty as txt.substring(0, 0). - PR: https://git.openjdk.java.net/jfx/pull/138
Re: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException [v7]
> This PR fixes JDK-8176270 by clamping the end index of the selected text to > the length of the text. Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException Clamping is no longer needed, removed it. - Changes: - all: https://git.openjdk.java.net/jfx/pull/138/files - new: https://git.openjdk.java.net/jfx/pull/138/files/660335bf..bf9e08d7 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/138/webrev.06 - incr: https://webrevs.openjdk.java.net/jfx/138/webrev.05-06 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/138.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/138/head:pull/138 PR: https://git.openjdk.java.net/jfx/pull/138
Re: MacOS Big Sur and OpenJFX on Arm Macs
JavaFX already runs on some Arm-based devices like the Raspberry Pi, so I expect an Arm-based port for new Macs won’t be that big of a job (relatively speaking) Hopefully by that time there will be a Metal-base rendering pipeline as well. The Metal-based pipeline for Swing seems to be coming along nicely. I don’t know if Oracle has access to one of the early developer boxes that runs macOS on arm or not. If they don’t, then a Java/Java FX port may not be available on day 1. That being said, perhaps Rosetta 2 will run the JDK/JRE until a proper port is available. I don’t know if the JIT compiler will work with Rosetta though. If it doesn’t then that certainly makes a proper port more urgent. Scott > On Jul 1, 2020, at 2:13 PM, Danny Gonzalez > wrote: > > Hi All, > > Not sure if this is the correct place to direct this conversation but here > goes. > > With the imminent arrival of Arm Macs in late 2020 running MacOS Big Sur, > what are the plans to ensure that OpenJFX and Java will run on this platform? > > Are there plans to get the Developer Transition Kit to test on real hardware > prior to the release of consumer hardware? > Are there testers testing on MacOs beta? > > Will OpenJFX and Java be able to run natively in this new Arm Mac environment? > Will OpenJFX and Java be able to run in the Rosetta emulator? > > We have many MacOS customers, many of whom will be early adopters and upgrade > to the new Arm Macs so this could be a big issue for us. > > Thanks > > Danny > >
Re: RFR: 8247963: Update SQLite to version 3.32.3
On Wed, 1 Jul 2020 17:14:30 GMT, Arun Joseph wrote: > We currently use SQLite version 3.31.1. We should update to the latest stable > release version 3.32.3 released on > 2020-06-18. https://www.sqlite.org/index.html Looks good. Tested on all three platforms. - Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/261
Integrated: 8238954: Improve performance of tiled snapshot rendering
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 openjfx14. The fix, based around > the idea of capturing as many tiles of the maximum possible size and > re-compositing the final snapshot out of these, is > currently only attempted after the original, non-tiled, strategy has already > failed. This was decided to avoid any risk > of regressions, either in terms of performances and correctness, while still > offering some relief to the original > issue. This follow-on issue aims to propose a fix to the original issue, > that is able to correctly decide on the best > snapshot strategy (tiled or not) to adopt before applying it and ensure best > performances possible when tiling is > necessary while still introducing no regressions compared to the original > solution. This pull request has now been integrated. Changeset: 32584dba Author:Frederic Thevenet Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/32584dba Stats: 395 lines in 3 files changed: 64 ins; 313 del; 18 mod 8238954: Improve performance of tiled snapshot rendering Reviewed-by: arapte, kcr - PR: https://git.openjdk.java.net/jfx/pull/112
Re: RFR: 8244212: Optionally download media and webkit libraries from latest openjfx EA build
On Wed, 1 Jul 2020 17:58:10 GMT, Nir Lisker wrote: >> Marked as reviewed by jvos (Reviewer). > > Do the build instructions need to be updated? The build instruction can indeed refer to WEBKIT-MEDIA-STUBS.md now. - PR: https://git.openjdk.java.net/jfx/pull/202
Re: RFR: 8238954: Improve performance of tiled snapshot rendering [v16]
On Wed, 1 Jul 2020 17:54:29 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 openjfx14. The fix, based around >> the idea of capturing as many tiles of the maximum possible size and >> re-compositing the final snapshot out of these, is >> currently only attempted after the original, non-tiled, strategy has already >> failed. This was decided to avoid any risk >> of regressions, either in terms of performances and correctness, while still >> offering some relief to the original >> issue. This follow-on issue aims to propose a fix to the original issue, >> that is able to correctly decide on the best >> snapshot strategy (tiled or not) to adopt before applying it and ensure best >> performances possible when tiling 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 Verified On Mac and Windows10, looks good to me. - Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/112
Re: RFR: 8238954: Improve performance of tiled snapshot rendering [v16]
> 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 size and > re-compositing the final snapshot out of these, is > currently only attempted after the original, non-tiled, strategy has already > failed. This was decided to avoid any risk > of regressions, either in terms of performances and correctness, while still > offering some relief to the original > issue. This follow-on issue aims to propose a fix to the original issue, > that is able to correctly decide on the best > snapshot strategy (tiled or not) to adopt before applying it and ensure best > performances possible when tiling 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 - Changes: - all: https://git.openjdk.java.net/jfx/pull/112/files - new: https://git.openjdk.java.net/jfx/pull/112/files/d8083075..58cc2000 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/112/webrev.15 - incr: https://webrevs.openjdk.java.net/jfx/112/webrev.14-15 Stats: 37 lines in 1 file changed: 3 ins; 14 del; 20 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112
Re: RFR: 8244212: Optionally download media and webkit libraries from latest openjfx EA build
On Mon, 29 Jun 2020 11:23:01 GMT, Johan Vos wrote: >> I have tested on Linux (Fedora 31) only. >> It works as intended (with one test failure due to 15-ea+4 being too old >> now). >> >> UPDATE_STUB_CACHE suggests there is some magic available to help manage the >> stub cache. >> But as I could not find anything about it, that section in the documentation >> may need some love. > > Marked as reviewed by jvos (Reviewer). Do the build instructions need to be updated? - PR: https://git.openjdk.java.net/jfx/pull/202
Re: RFR: 8238954: Improve performance of tiled snapshot rendering [v16]
On Wed, 1 Jul 2020 16:20:53 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 openjfx14. The fix, based around >> the idea of capturing as many tiles of the maximum possible size and >> re-compositing the final snapshot out of these, is >> currently only attempted after the original, non-tiled, strategy has already >> failed. This was decided to avoid any risk >> of regressions, either in terms of performances and correctness, while still >> offering some relief to the original >> issue. This follow-on issue aims to propose a fix to the original issue, >> that is able to correctly decide on the best >> snapshot strategy (tiled or not) to adopt before applying it and ensure best >> performances possible when tiling 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 Looks good. Sanity tested on all three platforms. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1589: > 1588: int mTileWidth = computeTileSize(w, > maxTextureSize); > 1589: int mTileHeight = computeTileSize(h, > maxTextureSize); > 1590: IntBuffer buffer = > IntBuffer.allocate(mTileWidth * mTileHeight); I'll test it soon. Since these variables no longer change, maybe you could make them `final`? - Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/112
Re: RFR: 8238954: Improve performance of tiled snapshot rendering [v15]
On Wed, 1 Jul 2020 14:29:55 GMT, Frederic Thevenet wrote: > Someone will still need to run the tests on macOS, I'm afraid. I'll do a quick sanity test on all three platforms. - PR: https://git.openjdk.java.net/jfx/pull/112
RFR: 8247963: Update SQLite to version 3.32.3
We currently use SQLite version 3.31.1. We should update to the latest stable release version 3.32.3 released on 2020-06-18. https://www.sqlite.org/index.html - Commit messages: - 8247963: Update SQLite to version 3.32.3 Changes: https://git.openjdk.java.net/jfx/pull/261/files Webrev: https://webrevs.openjdk.java.net/jfx/261/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247963 Stats: 4409 lines in 4 files changed: 2488 ins; 1057 del; 864 mod Patch: https://git.openjdk.java.net/jfx/pull/261.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/261/head:pull/261 PR: https://git.openjdk.java.net/jfx/pull/261
Re: RFR: 8247963: Update SQLite to version 3.32.3
On Wed, 1 Jul 2020 17:14:30 GMT, Arun Joseph wrote: > We currently use SQLite version 3.31.1. We should update to the latest stable > release version 3.32.3 released on > 2020-06-18. https://www.sqlite.org/index.html @guruhb @bhaweshkc can one of you review this as well? - PR: https://git.openjdk.java.net/jfx/pull/261
MacOS Big Sur and OpenJFX on Arm Macs
Hi All, Not sure if this is the correct place to direct this conversation but here goes. With the imminent arrival of Arm Macs in late 2020 running MacOS Big Sur, what are the plans to ensure that OpenJFX and Java will run on this platform? Are there plans to get the Developer Transition Kit to test on real hardware prior to the release of consumer hardware? Are there testers testing on MacOs beta? Will OpenJFX and Java be able to run natively in this new Arm Mac environment? Will OpenJFX and Java be able to run in the Rosetta emulator? We have many MacOS customers, many of whom will be early adopters and upgrade to the new Arm Macs so this could be a big issue for us. Thanks Danny
Re: RFR: 8238954: Improve performance of tiled snapshot rendering [v15]
On Wed, 1 Jul 2020 14:29:55 GMT, Frederic Thevenet wrote: >> Marked as reviewed by arapte (Reviewer). > > I have read Ambarish's code more closely and I am now convinced it is indeed > easier to understand; beyond the change > from "while" to "for" loops, it introduces an extra set of variables which > avoids the same "m/b/rTileWidth/Height" vars > to have to designate different things depending in which loop they're used > (M, B, or R). In hindsight, this is why I > had such a hard time naming them. I have run the automated tests on Windows > and Ubuntu (w/ forceGPU=true) and it > passes. The benchmark I made also produces similar results. Someone will > still need to run the tests on macOS, I'm > afraid. If it's not too much of a problem now that the PR's been approved, I > think it would beneficial to make the > change, especially considering that this bit of code might be used as a > starting point for other issues requiring > tiling. That would be fine with me. - PR: https://git.openjdk.java.net/jfx/pull/112
Re: RFR: 8238954: Improve performance of tiled snapshot rendering [v15]
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 QuantumToolkit >> - Only initialize RTT cache if needed > > Marked as reviewed by arapte (Reviewer). I have read Ambarish's code more closely and I am now convinced it is indeed easier to understand; beyond the change from "while" to "for" loops, it introduces an extra set of variables which avoids the same "m/b/rTileWidth/Height" vars to have to designate different things depending in which loop they're used (M, B, or R). In hindsight, this is why I had such a hard time naming them. I have run the automated tests on Windows and Ubuntu (w/ forceGPU=true) and it passes. The benchmark I made also produces similar results. Someone will still need to run the tests on macOS, I'm afraid. If it's not too much of a problem now that the PR's been approved, I think it would beneficial to make the change, especially considering that this bit of code might be used as a starting point for other issues requiring tiling. - PR: https://git.openjdk.java.net/jfx/pull/112
Re: RFR: 8201570: Get two bytes for the Linux input event type, not four
On Mon, 29 Jun 2020 11:31:41 GMT, Johan Vos wrote: >> Fixes [JDK-8201570](https://bugs.openjdk.java.net/browse/JDK-8201570). > > This fixes a bug that currently didn't cause any harm > (https://bugs.openjdk.java.net/browse/JDK-8201570?focusedCommentId=14172176) > , but it's better to fix it now. @jgneff you can proceed with this and integrate it. Once you do that, I'll sponsor the commit. - PR: https://git.openjdk.java.net/jfx/pull/257
Integrated: 8244212: Optionally download media and webkit libraries from latest openjfx EA build
On Thu, 30 Apr 2020 18:56:40 GMT, Jesper Skov wrote: > I have tested on Linux (Fedora 31) only. > It works as intended (with one test failure due to 15-ea+4 being too old now). > > UPDATE_STUB_CACHE suggests there is some magic available to help manage the > stub cache. > But as I could not find anything about it, that section in the documentation > may need some love. This pull request has now been integrated. Changeset: 869ea404 Author:Jesper Skov Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/869ea404 Stats: 106 lines in 2 files changed: 3 ins; 97 del; 6 mod 8244212: Optionally download media and webkit libraries from latest openjfx EA build Reviewed-by: kcr, jvos - PR: https://git.openjdk.java.net/jfx/pull/202
Re: RFR: 8238954: Improve performance of tiled snapshot rendering [v15]
On Wed, 1 Jul 2020 09:44:05 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 openjfx14. The fix, based around >> the idea of capturing as many tiles of the maximum possible size and >> re-compositing the final snapshot out of these, is >> currently only attempted after the original, non-tiled, strategy has already >> failed. This was decided to avoid any risk >> of regressions, either in terms of performances and correctness, while still >> offering some relief to the original >> issue. This follow-on issue aims to propose a fix to the original issue, >> that is able to correctly decide on the best >> snapshot strategy (tiled or not) to adopt before applying it and ensure best >> performances possible when tiling 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 QuantumToolkit > - Only initialize RTT cache if needed Marked as reviewed by arapte (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/112
FINAL REMINDER: JavaFX 15 RDP1 starts tomorrow [was: Proposed schedule for JavaFX 15]
As a reminder, RDP1 starts tomorrow. I will fork the 'jfx15' branch at 16:00 UTC. -- Kevin On 6/18/2020 9:38 AM, Kevin Rushforth wrote: As a reminder, RDP1 for JavaFX 15 starts on July 2, 2020 at 16:00 UTC (09:00 Pacific time), which is two weeks from today. Please allow sufficient time for any feature that needs a CSR. New features should be far enough along in the review process that you can finalize the CSR before Thursday, June 25, or it is likely to miss the window for this release, in which case it can be targeted for JavaFX 16. During rampdown of JavaFX 15, the "master" branch of the jfx repo will be open for JavaFX 16 fixes. We will follow the same process as previous releases for getting fixes into JavaFX 15 during rampdown. I'll send a message with detailed information later, but candidates for fixing during RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc bugs of any priority. Some small enhancements might be considered during RDP1, but they require explicit approval; the bar will be high for such requests. -- Kevin On 3/12/2020 10:11 AM, Kevin Rushforth wrote: Here is the proposed schedule for JavaFX 15. RDP1: Jul 2, 2020 (aka “feature freeze”) RDP2: Jul 30, 2020 Freeze: Aug 20, 2020 GA: September 8, 2020 We plan to fork a jfx15 stabilization branch at RDP1. The GA date is expected to be one week ahead of JDK 15, matching what we did for 14. As a slight change from previous releases, the start of RDP1, the start of RDP2, and the code freeze will be 16:00 UTC on the respective dates. Please let Johan or me know if you have any questions. -- Kevin
Re: RFR: 8238954: Improve performance of tiled snapshot rendering [v15]
On Wed, 1 Jul 2020 09:44:05 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 openjfx14. The fix, based around >> the idea of capturing as many tiles of the maximum possible size and >> re-compositing the final snapshot out of these, is >> currently only attempted after the original, non-tiled, strategy has already >> failed. This was decided to avoid any risk >> of regressions, either in terms of performances and correctness, while still >> offering some relief to the original >> issue. This follow-on issue aims to propose a fix to the original issue, >> that is able to correctly decide on the best >> snapshot strategy (tiled or not) to adopt before applying it and ensure best >> performances possible when tiling 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 QuantumToolkit > - Only initialize RTT cache if needed Marked as reviewed by kcr (Lead). - PR: https://git.openjdk.java.net/jfx/pull/112
Re: RFR: 8238954: Improve performance of tiled snapshot rendering [v14]
On Wed, 1 Jul 2020 09:17:16 GMT, Frederic Thevenet
wrote:
>> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java
>> line 1638:
>>
>>> 1637: renderWholeImage(x, y, w, h, rf, pImage);
>>> 1638: }
>>> 1639: params.platformImage = pImage;
>>
>> I tried to write this code using for loop to make it little easy for reader
>> to understand. This is just a suggestion, I
>> leave it to you to whether replace it or not,
>> int mTileWidth = computeTileSize(w, maxTextureSize);
>> int mTileHeight = computeTileSize(h, maxTextureSize);
>> IntBuffer buffer = IntBuffer.allocate(mTileWidth * mTileHeight);
>>
>> int mTileXOffset = 0;
>> int mTileYOffset = 0;
>> for (mTileXOffset = 0; (mTileXOffset + mTileWidth) <= w; mTileXOffset +=
>> mTileWidth) {
>> for (mTileYOffset = 0; (mTileYOffset + mTileHeight) <= h; mTileYOffset
>> += mTileHeight) {
>> renderTile(x, mTileXOffset, y, mTileYOffset, mTileWidth,
>> mTileHeight,
>> buffer, rf, tileRttCache, pImage);
>> }
>> }
>>
>> int rTileXOffset = mTileXOffset;
>> int rTileWidth = w - rTileXOffset;
>> if (rTileWidth > 0) {
>> for (int rTileYOffset = 0; (rTileYOffset + mTileHeight) <= h;
>> rTileYOffset += mTileHeight) {
>> renderTile(x, rTileXOffset, y, rTileYOffset, rTileWidth,
>> mTileHeight,
>> buffer, rf, tileRttCache, pImage);
>> }
>> }
>>
>> int bTileYOffset = mTileYOffset;
>> int bTileHeight = h - bTileYOffset;
>> if (bTileHeight > 0) {
>> for (int bTileXOffset = 0; (bTileXOffset + mTileWidth) <= w;
>> bTileXOffset += mTileWidth) {
>> renderTile(x, bTileXOffset, y, bTileYOffset, mTileWidth,
>> bTileHeight,
>> buffer, rf, tileRttCache, pImage);
>> }
>> }
>>
>> if (rTileWidth > 0 && bTileHeight > 0) {
>> renderTile(x, rTileXOffset, y, bTileYOffset, rTileWidth, bTileHeight,
>> buffer, rf, tileRttCache, pImage);
>> }
>
> Thanks for you suggestion.
>
> The original code is still too fresh in my mind for me to really be able to
> say which version is easier to understand,
> so I'll let others with a fresh pair of eyes be the judge of that. However I
> think your code is arguably more concise -
> and overall more elegant - so I'd be happy to swap my version for yours,
> provided it is considered at least as readable
> as the original. WDYT?
We'll leave it up to you, but I note that it will require retesting if you
adopt the suggested change.
-
PR: https://git.openjdk.java.net/jfx/pull/112
Re: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened
On Mon, 29 Jun 2020 18:49:33 GMT, John Neffenger
wrote:
>> The rationale makes sense (open/open/close) instead of (open/close/open)
>
> Based on my notes below, I believe this change is safe for any Linux input
> device driver because the driver shouldn't
> receive the intermediate *open* and *close* calls at all.
> Nonetheless, it would be reassuring if someone could try [this
> change](https://github.com/openjdk/jfx/pull/258/files)
> just once on a mainstream device, such as the Raspberry Pi with a touchscreen
> LCD panel. I only have six obscure ARM
> devices and a headless QEMU ARM virtual machine for testing. @johanvos or
> @dellgreen - Is that something you could
> test? If you think it's overkill and not worth it, that's fine, too.
> Notes
> The Linux kernel documentation about [opening and
> closing](https://www.kernel.org/doc/html/latest/input/input-programming.html#dev-open-and-dev-close)
> input devices
> states:
>> Note that input core keeps track of number of users for the device and makes
>> sure that dev->open() is called only when
>> the first user connects to the device and that dev->close() is called when
>> the very last user disconnects. Calls to
>> both callbacks are serialized.
>
> Also, the Linux Programmer's Manual for the *close* system call (`man 2
> close`) states:
>
>> If *fd* is the last file descriptor referring to the underlying open file
>> description (see **open**(2)), the resources
>> associated with the open file description are freed.
>
> Running a JavaFX program with `strace -f -e trace=open,close -o strace.log`
> shows the one *open* for the *event0*
> keyboard, and the *open, open, close* for the *event1* touchscreen:
> 5847 open("/dev/input/event0", O_RDONLY) = 11
> ...
> 5847 open("/dev/input/event1", O_RDONLY) = 12
> 5847 open("/dev/input/event1", O_RDONLY) = 13
> 5847 close(13) = 0
>
> Both devices are actually closed by the kernel when the JavaFX program ends.
I don't have access to a Pi right now, so I can't test this (I'll be able to
test in about 10 days from now though)
-
PR: https://git.openjdk.java.net/jfx/pull/258
Re: RFR: 8248317: Change JavaFX release version to 16
On Tue, 30 Jun 2020 15:30:31 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 16. I will integrate this immediately > after forking the `jfx15` stabilization > branch. Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/260
Re: RFR: 8238954: Improve performance of tiled snapshot rendering [v15]
> 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 size and > re-compositing the final snapshot out of these, is > currently only attempted after the original, non-tiled, strategy has already > failed. This was decided to avoid any risk > of regressions, either in terms of performances and correctness, while still > offering some relief to the original > issue. This follow-on issue aims to propose a fix to the original issue, > that is able to correctly decide on the best > snapshot strategy (tiled or not) to adopt before applying it and ensure best > performances possible when tiling 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 QuantumToolkit - Only initialize RTT cache if needed - Changes: - all: https://git.openjdk.java.net/jfx/pull/112/files - new: https://git.openjdk.java.net/jfx/pull/112/files/c0f7d14f..d8083075 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/112/webrev.14 - incr: https://webrevs.openjdk.java.net/jfx/112/webrev.13-14 Stats: 10 lines in 2 files changed: 3 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112
Re: RFR: 8238954: Improve performance of tiled snapshot rendering [v14]
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.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java
> line 1638:
>
>> 1637: renderWholeImage(x, y, w, h, rf, pImage);
>> 1638: }
>> 1639: params.platformImage = pImage;
>
> I tried to write this code using for loop to make it little easy for reader
> to understand. This is just a suggestion, I
> leave it to you to whether replace it or not,
> int mTileWidth = computeTileSize(w, maxTextureSize);
> int mTileHeight = computeTileSize(h, maxTextureSize);
> IntBuffer buffer = IntBuffer.allocate(mTileWidth * mTileHeight);
>
> int mTileXOffset = 0;
> int mTileYOffset = 0;
> for (mTileXOffset = 0; (mTileXOffset + mTileWidth) <= w; mTileXOffset +=
> mTileWidth) {
> for (mTileYOffset = 0; (mTileYOffset + mTileHeight) <= h; mTileYOffset
> += mTileHeight) {
> renderTile(x, mTileXOffset, y, mTileYOffset, mTileWidth,
> mTileHeight,
> buffer, rf, tileRttCache, pImage);
> }
> }
>
> int rTileXOffset = mTileXOffset;
> int rTileWidth = w - rTileXOffset;
> if (rTileWidth > 0) {
> for (int rTileYOffset = 0; (rTileYOffset + mTileHeight) <= h;
> rTileYOffset += mTileHeight) {
> renderTile(x, rTileXOffset, y, rTileYOffset, rTileWidth,
> mTileHeight,
> buffer, rf, tileRttCache, pImage);
> }
> }
>
> int bTileYOffset = mTileYOffset;
> int bTileHeight = h - bTileYOffset;
> if (bTileHeight > 0) {
> for (int bTileXOffset = 0; (bTileXOffset + mTileWidth) <= w;
> bTileXOffset += mTileWidth) {
> renderTile(x, bTileXOffset, y, bTileYOffset, mTileWidth,
> bTileHeight,
> buffer, rf, tileRttCache, pImage);
> }
> }
>
> if (rTileWidth > 0 && bTileHeight > 0) {
> renderTile(x, rTileXOffset, y, bTileYOffset, rTileWidth, bTileHeight,
> buffer, rf, tileRttCache, pImage);
> }
Thanks for you suggestion.
The original code is still too fresh in my mind for me to really be able to say
which version is easier to understand,
so I'll let others with a fresh pair of eyes be the judge of that. However I
think your code is arguably more concise -
and overall more elegant - so I'd be happy to swap my version for yours,
provided it is considered at least as readable
as the original. WDYT?
-
PR: https://git.openjdk.java.net/jfx/pull/112
