Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8238954: Improve performance of tiled snapshot rendering #112

Closed
wants to merge 20 commits into from

Conversation

@fthevenet
Copy link
Member

fthevenet commented Feb 12, 2020

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.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8238954: Improve performance of tiled snapshot rendering

Reviewers

  • Ambarish Rapte (arapte - Reviewer)
  • Kevin Rushforth (kcr - Reviewer)

Download

$ git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112
$ git checkout pull/112

fthevenet added 2 commits Jan 31, 2020
…ger than max texture size"

This reverts commit 1823f6e
…arger than max texture size
@bridgekeeper
Copy link

bridgekeeper bot commented Feb 12, 2020

👋 Welcome back fthevenet! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request.

@fthevenet
Copy link
Member Author

fthevenet commented Feb 12, 2020

I've marked this PR as a WIP for the time being because I've only tested it on the d3d rendering pipeline so far, so I think it is too early to call for a formal review yet.
Still, I welcome feedback if someone wants to have a look at it already.

In a nutshell, this is what this PR does:

  • Reverts changes from 8088198
  • Implements tiling within QuantumToolkit::renderToImage instead
  • Gets the maxTextureSize directly from the ResourceFactory instance instead of relying on PrismSettings.maxTextureSize (which may be wrong in the event the maxTexture size supported by the hardware is less than the clamped value set in PrismSettings)
  • Tries to align the PixelFomat for the target WritableImage with that of the RTTexture when possible, since converting IntARGB to ByteBGRA (or the other way round) is a major cost factor when copying large amounts of pixels.
  • Avoids as much as possible having to resize the tile in between subsequent calls to RTTexture::readPixels, as it is another major cost factor, under the d3d rendering pipeline at least. (Native method D3DResourceFactory_nReadPixels attempts to reuse the same surface in between calls but is forced to create a new one if dimensions are not exactly the same, which is quite costly).

TODO:

  • Make sure chosen PixelFormat is optimum when using es2 pipeline.
  • Consider using subtexture pixel read with es2 (SW and d3d don't support it) as a better alternative to relying on same size tiles to avoid surface thrashing.
@kevinrushforth
Copy link
Member

kevinrushforth commented Feb 12, 2020

/reviewers 2

@openjdk
Copy link

openjdk bot commented Feb 12, 2020

@kevinrushforth
The number of required reviews for this PR is now set to 2 (with at least 1 of role reviewers).

@fthevenet fthevenet changed the title WIP: 8238954: Improve performance of tiled snapshot rendering 8238954: Improve performance of tiled snapshot rendering Feb 28, 2020
@openjdk openjdk bot added the rfr label Feb 28, 2020
@fthevenet
Copy link
Member Author

fthevenet commented Feb 28, 2020

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 swapping around pixel components, like under d3d.
I've also verified than the patch's behaviour is correct when a writable image is provided as a parameter to Node.snapshot, whether the underlying image is actually a PlatformImage or a wrapper for a PixelBuffer, which corrects another limitation of the previous implementation.

…set to false if needed.
@arapte
Copy link
Member

arapte commented Mar 10, 2020

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 for previous PR

@fthevenet
Copy link
Member Author

fthevenet commented Mar 10, 2020

14-ea+9


1024 2048 3072 4096 5120 6144 7168 8192 9216
1024 5.607827 9.380503 13.835523 17.514362 21.776304 27.918815 36.929480 35.647317 74.274598
2048 11.271960 17.774451 26.468146 34.555745 42.699573 52.027568 74.481450 68.349699 135.902502
3072 13.953309 26.320822 42.652327 51.534650 65.202531 78.406419 103.512338 109.125337 214.305998
4096 17.776236 35.800101 57.483720 70.221125 98.024908 106.510784 109.940266 150.731465 265.632840
5120 22.756799 44.809926 69.324931 85.589418 106.649450 137.122404 146.470563 149.845737 371.508604
6144 26.218716 53.103478 78.157447 122.467283 129.644202 162.408603 160.861559 172.865197 460.078507
7168 31.095109 60.251328 91.299751 133.693702 143.813523 154.496892 171.049670 186.519441 527.541763
8192 34.609033 71.258569 107.084557 143.252194 163.108854 165.619014 178.134480 220.085044 514.600669
9216 69.133873 135.713363 198.200679 277.606301 355.598066 480.710904 450.875668 577.701980 623.690198

14-ea+9

@fthevenet
Copy link
Member Author

fthevenet commented Mar 10, 2020

14-internal


1024 2048 3072 4096 5120 6144 7168 8192 9216
1024 5.740508 9.337537 13.489849 17.611105 38.898909 48.165735 53.596876 49.449740 66.032570
2048 9.845097 17.799415 26.109529 34.607728 79.345622 94.082500 107.777644 100.901349 135.826890
3072 14.654498 26.183649 39.781191 51.871491 113.010307 143.613631 184.883820 167.076202 200.852633
4096 18.706278 36.115871 51.477296 68.457649 156.240888 186.159272 222.876505 237.387683 290.125942
5120 50.566276 106.465632 140.506406 161.687151 203.644875 237.260330 279.108632 311.002566 371.704115
6144 53.501341 106.726656 160.191733 216.969484 264.996201 287.375425 335.294473 365.035267 419.995978
7168 66.422026 110.882355 187.978455 239.014528 308.817056 335.838550 394.270828 445.987300 506.974069
8192 60.315442 108.770069 164.424088 205.330331 305.201833 343.846336 392.867668 454.540147 503.808112
9216 71.070811 132.708328 188.411172 256.130225 320.028449 400.748559 471.542252 595.355103 589.240851

14-internal

@fthevenet
Copy link
Member Author

fthevenet commented Mar 10, 2020

15-internal:


1024 2048 3072 4096 5120 6144 7168 8192 9216
1024 5.381051 9.261115 14.033219 20.608201 26.159817 33.599632 36.669261 43.042338 46.086088
2048 9.752862 17.698869 27.004541 38.437578 52.297443 60.757880 68.101838 80.162117 93.852856
3072 15.564961 27.304138 40.255866 56.636476 80.472402 86.346635 105.154089 121.048263 130.458981
4096 19.436113 35.556343 53.277865 71.623899 95.814932 122.543003 136.833771 160.199834 178.356125
5120 27.246498 65.875784 73.171492 103.380029 126.486761 147.666102 165.833885 199.005331 220.659671
6144 31.843301 62.101937 93.646729 125.531512 150.914608 175.553034 209.835003 241.114596 253.512648
7168 40.507918 70.843435 101.075064 137.284040 165.808501 197.015259 254.286955 304.928104 299.992601
8192 43.206941 80.290957 121.946965 157.016439 193.509481 243.514969 268.151933 359.562281 352.102850
9216 49.529493 90.895186 149.422784 179.512616 217.260338 267.610592 309.706685 354.950852 383.275751

15-internal

@fthevenet
Copy link
Member Author

fthevenet commented Mar 10, 2020

I've uploaded 3 sets of results, from 3 different implementations:

  1. 14-ea+9 is the implementation merged into openjfx14 following #68; it only use tiling if the original implementation fails; on Windows that would typically be when the snapshot dimensions are larger than 8192 pixels.

  2. 14-internal uses the same tiling implementation than the above, but start using tiling as soon as snapshot dimensions are larger than PrismSettings.maxTextureSize; i.e. typically 4096 pixels.
    NB: This implementation was never merged into openJFX; results are only provided for comparison's sake.

  3. 15-internal uses the tiling implementation proposed in the PR. Compared to the ones above, it attempt to align pixel formats to avoid the cost of transformation from one format to another (e.g. ByteBRGA to IntARGB) and it tries to divide up the final snapshots into tiles of the same dimensions to prevent creating a new GPU surface for every tile.
    Please note that these results are for the best possible scenario with regard to the above optimizations; in the worst case scenario (a user provided image with a different pixel format and no way to divide the snapshot into equal size tiles), then the performances are the same as that of implementation 2

My conclusion from the above results is twofold:

  • Tiling does have a cost in terms of performance, but as far as I can tell it remains the only practical way to work around the underlying issue (i.e. taking snapshot larger than the supported texture size).
    Also, the optimizations proposed in this PR arguably do help in mitigating that cost, even if it is only true in some of the cases.

  • The original implementation, which is preserved in 14-ea+9, ignores texture clamping to 4096 which means it doesn't has to resort to tiling until the target snapshot size is >8192 on d3d or 16384 on es2.
    If ignoring clamping is an incorrect behaviour on the part of the original implementation (which I'm led to believe is the case), it gives it an unfair advantage in this benchmark, i.e. it is faster because is does things it shouldn't do.
    If however it turns out it is actually safe to ignore clamping when taking snapshot, then it would make sense to do so in the implementation proposed by this PR as well.

@fthevenet
Copy link
Member Author

fthevenet commented Mar 10, 2020

By the way, the code for the above benchmark is available here: https://github.com/fthevenet/snapshot-perf-meter

Would it make sense to include it into the OpenJFX repo, maybe under jfx/apps/performance ?

Copy link
Member

arapte left a comment

The change seems good to me. Suggested few minor corrections and a query.

pImage.setImage(com.sun.prism.Image.fromIntArgbPreData(IntBuffer.allocate(w * h), w, h));
}
// Find out it is is possible to divide up the image in tiles of the same size
AtomicBoolean exactWidthDivFound = new AtomicBoolean(false);

This comment has been minimized.

@arapte

arapte Mar 13, 2020 Member

exactWidthDivFound is unused, may be can skip creating a named variable and just pass a unnamed AtomicBoolean in next call to computeOptimumTileSize

This comment has been minimized.

@fthevenet

fthevenet Mar 14, 2020 Author Member

I've made a change so that null can be passed to the method if the AtomicBoolean instance is not needed.

Copy link
Member

arapte left a comment

The PR looks good to me, Please revert the changes in import.

@nlisker
Copy link
Collaborator

nlisker commented Mar 17, 2020

Now that the tiling is done in the QuantumRenderer level, I'll bring back JDK-8189082. Can't this tiling be used to fix that?

@fthevenet
Copy link
Member Author

fthevenet commented Mar 17, 2020

Now that the tiling is done in the QuantumRenderer level, I'll bring back JDK-8189082. Can't this tiling be used to fix that?

It won't help with things in their current state, as the RenderToImage method that is modified in this PR is currently called only by the snapshot feature in Scene
But of course I suspect the same technique could also be used to solve JDK-8189082 and now is indeed a good time to investigate it further.
I'll have a look to see if it is possible to factorize the tiling implementation for both classes of issues, in which case it would make sense to do prior to merging this PR.
If it is different enough that the implementation cannot be shared but only the general idea, then I suggest we address it in a different PR.

What do you all think ?

@fthevenet
Copy link
Member Author

fthevenet commented Mar 17, 2020

At first glance, the NPE in JDK-8189082 occurs in the Prism layer, which is one level below Quantum where the tiling is currently implemented, so I'm not sure tit is reachable from there; if we want the code to be shared, it looks like it would need to be moved even further down (maybe in the ResourceFactory?)

Also, while reusing code is generally the way to go, in such lower layers, very closely intertwined with the actual rendering, I'm afraid that insisting on having a "one-size-fits-all" implementation might get in the way of necessary case-by-case optimizations, so I'd like to have someone with a deeper knowledge of the code base to weight in before starting work in that direction. Maybe @kevinrushforth could advise?

@fthevenet
Copy link
Member Author

fthevenet commented Apr 15, 2020

Hi everyone,

This PR hasn't seen much activity in a while, so I though I would give it a gentle kick to hopefully get it moving again ;)
As explained above, I feel a little stalled at the moment, as we need to decide whether or not it is a good idea to try and address all or part of JDK-8189082 within the scope of this PR, and I don't feel like I can settle that on my own.

Thanks.

@kevinrushforth
Copy link
Member

kevinrushforth commented Apr 15, 2020

Sorry for the delay. This is on my review queue, which has been growing of late. I'll take a look at it soon.

To answer one of your questions:

we need to decide whether or not it is a good idea to try and address all or part of JDK-8189082 within the scope of this PR

I think your idea of addressing the other similar cases (Canvas and SubScene in particular) in a follow-up PR seems fine. If, at that time, you find you can refactor this to share some of the implementation, that would be good.

@kevinrushforth kevinrushforth self-requested a review Apr 28, 2020
@kevinrushforth
Copy link
Member

kevinrushforth commented Jun 29, 2020

Actually, it also fails the same way on Ubuntu 20.04 as it does on macOS if I force HW acceleration on Ubuntu. It's off by default when running in a VM, so is using the SW pipeline, which doesn't have a hard limit (so that could explain the heap problem you were facing).

Ensuring that the tile size is > 0 fixes it on Linux and Mac.

@fthevenet
Copy link
Member Author

fthevenet commented Jun 30, 2020

I've pushed the changes discussed above, and verified that the tests now pass on a Ubuntu 20.04 VM with prism.forceGpu=true (and that they indeed failed prior to those changes).

Copy link
Member

kevinrushforth left a comment

I've finished my testing on 4 platforms: Windows 10, macOS 10.15, Ubuntu 16.10 (physical), Ubuntu 20.04 (VM with forceGPU set to true). All looks good.

The code looks good too with a couple questions below.

Copy link
Member

arapte left a comment

The code looks good to me too, suggested minor change.

fthevenet added 2 commits Jul 1, 2020
- Fixed comments in QuantumToolkit
- Only initialize RTT cache if needed
@arapte
arapte approved these changes Jul 1, 2020
@openjdk
Copy link

openjdk bot commented Jul 1, 2020

@fthevenet This change now passes all automated pre-integration checks. When the change also fulfills all project specific requirements, type /integrate in a new comment to proceed. After integration, the commit message will be:

8238954: Improve performance of tiled snapshot rendering

Reviewed-by: arapte, kcr
  • If you would like to add a summary, use the /summary command.
  • To credit additional contributors, use the /contributor command.
  • To add additional solved issues, use the /issue command.

Since the source branch of this PR was last updated there have been 131 commits pushed to the master branch:

  • 869ea40: 8244212: Optionally download media and webkit libraries from latest openjfx EA build
  • 62f8cee: 8247947: Build DirectShow Samples (Base Classes) from source checked into repo
  • 527cc2b: 8248551: [TestBug] Ignore two failing FXML unit tests which use Nashorn script engine
  • 45c9854: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts
  • 15f97ed: 8240264: iOS: Unnecessary logging on every pulse when GL context changes
  • 2ca509a: 8193800: TreeTableView selection changes on sorting
  • a5878e0: 8214699: Node.getPseudoClassStates must return the same instance on every call
  • 8440b64: 8208169: can not print selected pages of web page
  • 1727dfa: 8247163: JFXPanel throws exception on click when no Scene is set
  • 54e2507: 8247360: Add missing license file for Microsoft DirectShow Samples
  • ... and 121 more: https://git.openjdk.java.net/jfx/compare/e98645932d0d7765988f21b09d6d121202281e02...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid automatic rebasing, please merge master into your branch, and then specify the current head hash when integrating, like this: /integrate 869ea404133f0251a0dcb8d9e7204646dadf43c6.

As you are not a known OpenJDK Author, an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@arapte, @kevinrushforth) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the ready label Jul 1, 2020
@fthevenet
Copy link
Member Author

fthevenet commented Jul 1, 2020

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.

@kevinrushforth
Copy link
Member

kevinrushforth commented Jul 1, 2020

That would be fine with me.

@kevinrushforth
Copy link
Member

kevinrushforth commented Jul 1, 2020

Someone will still need to run the tests on macOS, I'm afraid.

I'll do a quick sanity test on all three platforms.

@openjdk openjdk bot removed the ready label Jul 1, 2020
Copy link
Member

kevinrushforth left a comment

Looks good. Sanity tested on all three platforms.

@arapte
arapte approved these changes Jul 1, 2020
Copy link
Member

arapte left a comment

Verified On Mac and Windows10, looks good to me.

@openjdk openjdk bot added the ready label Jul 1, 2020
@fthevenet
Copy link
Member Author

fthevenet commented Jul 1, 2020

/integrate

@openjdk
Copy link

openjdk bot commented Jul 1, 2020

@fthevenet
Your change (at version 58cc200) is now ready to be sponsored by a Committer.

@openjdk openjdk bot added the sponsor label Jul 1, 2020
@kevinrushforth
Copy link
Member

kevinrushforth commented Jul 1, 2020

/sponsor

@openjdk openjdk bot closed this Jul 1, 2020
@openjdk openjdk bot added integrated and removed sponsor ready rfr labels Jul 1, 2020
@openjdk
Copy link

openjdk bot commented Jul 1, 2020

@kevinrushforth @fthevenet The following commits have been pushed to master since your change was applied:

  • 869ea40: 8244212: Optionally download media and webkit libraries from latest openjfx EA build
  • 62f8cee: 8247947: Build DirectShow Samples (Base Classes) from source checked into repo
  • 527cc2b: 8248551: [TestBug] Ignore two failing FXML unit tests which use Nashorn script engine
  • 45c9854: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts
  • 15f97ed: 8240264: iOS: Unnecessary logging on every pulse when GL context changes
  • 2ca509a: 8193800: TreeTableView selection changes on sorting
  • a5878e0: 8214699: Node.getPseudoClassStates must return the same instance on every call
  • 8440b64: 8208169: can not print selected pages of web page
  • 1727dfa: 8247163: JFXPanel throws exception on click when no Scene is set
  • 54e2507: 8247360: Add missing license file for Microsoft DirectShow Samples
  • fb962ac: 8244418: MenuBar: IOOB exception on requestFocus on empty bar
  • bf2e972: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars
  • b200891: 8244824: TableView : Incorrect German translation
  • b2b46eb: 8242892: SpinnerValueFactory has an implicit no-arg constructor
  • afa805f: 8245575: Show the ContextMenu of input controls with long press gesture on iOS
  • 5304266: 8245635: GlassPasteboard::getUTFs fails on iOS
  • ba501ef: 8246357: Allow static build of webkit library on linux
  • a02e09d: 8246195: ListViewSkin/Behavior: misbehavior on switching skin
  • 9749982: 8246204: No 3D support for newer Intel graphics drivers on Linux
  • 6bd0e22: 8239095: Upgrade libFFI to the latest 3.3 version
  • 853ac78: 8245282: Button/Combo Behavior: memory leak on dispose
  • a78b3fb: 8242523: Update the animation and clip envelope classes
  • 1ab653c: 8244657: ChoiceBox/ToolBarSkin: misbehavior on switching skin
  • 804ccce: 8244195: [TEST_BUG] Convert the system tests TabPanePermuteGetTabsTest to unit test
  • 9edba9c: 8243110: SVGTest.testSVGRenderingWithPattern fails intermittently
  • 168b7f7: 8246099: Intermittent test failures in SandboxAppTest
  • c41777e: 8245634: [TestBug] Enable and fix tests ignored with message "impl_cssSet API removed"
  • 3ceee69: 8245499: Text input controls should show handles on iOS
  • 8914bd2: 8234540: javafx.web LeakTest.testGarbageCollectability fails intermittently
  • 16f446a: 8234876: Unit test classes should not extend Application
  • 2d98fe6: 8245601: TESTBUG] Disable TabPaneDragPolicyTest on Mac until JDK-8213136 is fixed and fix ISE
  • f3190db: 8244531: Tests: add support to identify recurring issues with controls et al
  • 1971c70: 8245457: TestBug] Enable and fix ignored tests in ButtonBaseTest & ButtonTest
  • 6e0b45a: 8245183: Two fxml unit tests log warnings about deprecated escape sequences
  • a13a642: 8244579: Windows "User Objects" leakage with WebView
  • 37b5edc: 8245456: MacPasteboard throws ClassCastException on static builds
  • 6e03930: 8237602: TabPane doesn't respect order of TabPane.getTabs() list
  • bb24322: 8244112: Skin implementations: must not violate contract of dispose
  • dbb6437: 8244647: Wrong first layout pass of Scrollbar controls on touch supported devices
  • 7b06190: 8242548: Wrapped labeled controls using -fx-line-spacing cut text off
  • 435671e: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events.
  • c14cc44: 8244417: support static build for Windows
  • b14e085: 8244735: Error on iOS passing keys with unicode values greater than 255
  • b0d66d0: 8242508: Upgrade to Visual Studio 2019 version 16.5.3
  • 0f87d20: 8244487: One Windows 10 SDK file missing from FX build
  • 4ec163d: 8242001: ChoiceBox: must update value on setting SelectionModel, part2
  • 236e2d6: 8244421: Wrong scrollbar position on touch enabled devices
  • 0385563: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi
  • 2e90076: 8242507: Add support for Visual Studio 2019
  • 39d9c3b: 8244110: NPE in MenuButtonSkinBase change listener
  • 99f7747: 8241999: ChoiceBox: incorrect toggle selected for uncontained
  • 1cae6a8: 8176499: Dependence on java.util.Timer freezes screen when OS time resets backwards
  • 2b9eb52: 8237504: Update copyright header for files modified in 2020
  • 3130fc8: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles()
  • 8ad5805: 8191758: Match WebKit's font weight rendering with JavaFX
  • 66c3b38: 8227425: Add support for e-paper displays on i.MX6 devices
  • e30049f: 8242077: Add information about HTTP/2 and HttpClient usage in WebEngine
  • e0ffca3: 8242505: Some WebKit tests might fail because Microsoft libraries are not loaded
  • ceb3fce: 8087555: [ChoiceBox] uncontained value not shown
  • 818ac00: 8175358: Memory leak when moving MenuButton into another Scene
  • 91d4c8b: 8241737: TabPaneSkin memory leak on replacing selectionModel
  • 48476eb: 8241582: Infinite animation does not start from the end when started with a negative rate
  • dedf7cb: 8242490: Upgrade to gcc 9.2 on Linux
  • 5e9fb82: 8242577: Cell selection fails on iOS most of the times
  • 69e4266: 8242489: ChoiceBox: initially toggle not sync'ed to selection
  • 1d88180: 8243112: Skip failing test SVGTest.testSVGRenderingWithPattern
  • ec8608f: 8223298: SVG patterns are drawn wrong
  • e82046e: 8242530: [macos] Some audio files miss spectrum data when another audio file plays first
  • 7044cef: 8241476: Linux build warnings issued on gcc 9
  • 9d50c4c: Merge
  • 4d69a0d: 8241629: [macos10.15] Long startup delay playing media over https on Catalina
  • b1fdc45: 8242209: Increase web native thread stack size for x86 mode
  • e1cb191: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina
  • c154538: 8242106: [macos] Remove obsolete GlassView2D.m class
  • 3f663e3: 8240262: iOS refresh rate is capped to 30 Hz
  • 231879a: 8241710: NullPointerException while entering empty submenu with "arrow right"
  • 470c7d0: 8230809: HTMLEditor formatting lost when selecting all (CTRL-A)
  • fda015c: 8242167: ios keyboard handling
  • 844460b: 8242163: Android keyboard integration fails
  • 364c64a: 8241249: NPE in TabPaneSkin.perfromDrag
  • 418675a: 8236840: Memory leak when switching ButtonSkin
  • 247a65d: 8236971: [macos] Gestures handled incorrectly due to missing events
  • 560ef17: 8241455: Memory leak on replacing selection/focusModel
  • ef37669: Merge
  • 5906521: 8241370: Crash in JPEGImageLoader after fix for JDK-8212034
  • 159f651: 8240542: Switch FX build to use JDK 14 as boot JDK
  • 6d098fe: 8234959: FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV
  • d7f13f4: 8089828: RTL Orientation, the flag of a mnemonic is not placed under the mnemonic letter.
  • 9ecc107: 8240539: Upgrade gradle to version 6.3
  • f3a3ea0: 8234471: Canvas in webview displayed with wrong scale on Windows
  • d12e71c: 8241474: Build failing on Ubuntu 20.04
  • 2a7ab36: 8089134: [2D traversal, RTL] TraversalEngine only handles left/right key traversal correctly in RTL for top-level engine in ToolBar
  • 2aa8218: 8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation
  • e9c6119: 8240692: Cleanup of the javafx property objects
  • f2bca9f: Merge
  • 90289a2: 8239107: Update libjpeg to version 9d
  • b81cf32: 8236259: MemoryLeak in ProgressIndicator
  • 9ea7f96: 8240832: Remove unused applecoreaudio.md third-party legal file
  • 0fc1420: Merge
  • 50e15fc: 8240466: AppJSCallback* apps launched by ModuleLauncherTest intermittently hang
  • e3026b9: 8240688: Remove the JavaBeanXxxPropertyBuilders constructors
  • f8c235b: 8240631: Create release notes for JavaFX 14
  • cfa1193: 8236685: [macOs] Remove obsolete file dialog subclasses
  • 6900d29: Merge
  • f25e8cf: 8212034: Potential memory leaks in jpegLoader.c in error case
  • b2ac76a: 8240451: JavaFX javadoc build fails with JDK 14
  • cf0bba6: 8240211: Stack overflow on Windows 32-bit can lead to crash
  • 337ed72: 8237926: Potential memory leak of model data in javafx.scene.control.ListView
  • 960f039: 8208761: Update constant collections to use the new immutable collections
  • 10c9528: 8240265: iOS: Unnecessary logging on pinch gestures
  • 4c132cd: 8237889: Update libxml2 to version 2.9.10
  • e91bec4: Merge
  • 20328b3: 8240218: IOS Webkit implementation broken
  • 4c82af8: 8236832: [macos 10.15] JavaFX Application hangs on video play on Cata…
  • 9cd6f79: 8196586: Remove use of deprecated finalize methods from javafx property objects
  • ef2f9ce: 8238755: allow to create static lib for javafx.media on linux
  • c3ee1a3: 8239822: Intermittent unit test failures in RegionCSSTest
  • 3150562: 8235772: Remove use of deprecated finalize method from PiscesRenderer and AbstractSurface
  • 4eaff0d: 8239109: Update SQLite to version 3.31.1
  • 66a8f49: Merge
  • d8e7f85: 8239454: LLIntData : invalid opcode returned for 16 and 32 bit wide instructions
  • 48ddd80: Merge
  • 35a01ca: 8228867: Fix mistakes in FX API docs
  • b5e65ec: 8238434: Ensemble: Update version of Lucene to 7.7.2
  • fde42da: Merge
  • e21fd1f: Merge
  • 443c845: Merge
  • 31e63de: Merge
  • 14c6938: 8236798: Enhance FX scripting support
  • bfb2d0e: Merge
  • 39f6127: Merge

Your commit was automatically rebased without conflicts.

Pushed as commit 32584db.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.