8238954: Improve performance of tiled snapshot rendering

[fthevenet]

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

[bridgekeeper]

👋 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]

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]

/reviewers 2

[openjdk]

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

[mlbridge]

Webrevs

• 15: Full - Incremental (58cc200)
• 14: Full - Incremental (d808307)
• 13: Full - Incremental (c0f7d14)
• 12: Full - Incremental (efccc4d)
• 11: Full - Incremental (a01aaa2)
• 10: Full - Incremental (4752d83)
• 09: Full - Incremental (8274631)
• 08: Full - Incremental (2951d53)
• 07: Full - Incremental (8f0c2d2)
• 06: Full - Incremental (0642096)
• 05: Full - Incremental (1fb04e5)
• 04: Full - Incremental (7f5f289)
• 03: Full - Incremental (50ac8c2)
• 02: Full - Incremental (9c5b0d4)
• 01: Full - Incremental (9ec2d25)
• 00: Full (e13b5a0)

[fthevenet]

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.

[arapte]

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]

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

[fthevenet]

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

[fthevenet]

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

[fthevenet]

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

1. 14-ea+9 is the implementation merged into openjfx14 following 8088198: Exception thrown from snapshot if dimensions are larger than max texture size #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]

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 ?

[arapte]

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

[arapte]

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

[fthevenet]

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

[arapte]

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

[nlisker]

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]

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]

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]

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]

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]

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]

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).

[kevinrushforth]

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.

[arapte]

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

[openjdk]

@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).

[fthevenet]

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]

That would be fine with me.

[kevinrushforth]

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

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

[kevinrushforth]

Looks good. Sanity tested on all three platforms.

[arapte]

Verified On Mac and Windows10, looks good to me.

[fthevenet]

/integrate

[openjdk]

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

[kevinrushforth]

/sponsor

[openjdk]

@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.