On Tue, 10 Nov 2020 13:24:21 GMT, Erik Joelsson <er...@openjdk.org> wrote:
>> This is a review request for the bug particularly fixed some time ago: >> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html >> >> In that review request it was found that the old fix does not work well in >> all cases, see: >> https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html >> >> The current fix updates an embedded plist.info, so the java will not require >> discrete graphics by default, same as for any other applications. >> >> The discrete card will be used: >> 1. If macOS decided to enable it for some reason >> 2. If the java app sets/uses a full-screen window >> 3. If the user disable "automatic graphics switching" in the system >> preferences >> 4. If an external monitor is connected to the laptop >> >> In other cases, the integrated graphics will be used, which should be fine >> in most cases since this graphic is used/tested in the mbp 13/etc. This is >> not only about rendering performance but also about startup performance, on >> my current new laptop mbp 16 + Cataline 10.15.7 the switching >> discrete/integrated causes unexpected delays up to 10 seconds. >> >> >> Note that the new "metal" pipeline also does not require discrete graphics. >> >> The documentation for NSSupportsAutomaticGraphicsSwitching: >> https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching >> >> I'll create a release note after approval. >> >> Performance numbers: >> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html >> Old review request: >> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html > > Change looks ok from a build point of view, but I can't comment on the > validity and implications of using this key. I ran a 3D lighting test that is designed to be a GPU stress test. It's a worst case, to be sure, but it take 10 times as long to render with the integrated GPU as it does with the discrete GPU: **attenuation.LightingSample: 500 large quads** discrete GPU: 23.5 fps integrated GPU: 2.34 fps In a more realistic example of drawing a large number of 2D vectors, it runs 35% slower with the integrated GPU: **Vector charting test, oval clip** discrete GPU: 41.1 fps integrated GPU: 26.6 fps I see similar results in the performance numbers you listed above. An application developer who packages up their JDK, for example, using jpackage, can make the decision for themselves. Application developers who rely on the JDK as delivered will get whatever we choose as the default. So we need to be sure that the benefit of doing this justifies the performance hit. ------------- PR: https://git.openjdk.java.net/jdk/pull/1139
