Integrated vs. Discrete Graphics on OS X

[Sergey Bylokhov]

As a temporary solution you can use gxfCardStatus and block automatic 
activation of discrete GPU.
When I was looking to this area last time(on the jdk side), I found that 
the simple CAOpenGLLayer application activate discrete GPU also, and we 
have no ability to change that. Probably something changed since then.

On 25.05.15 21:03, Scott Palmer wrote:
> Yes, I appreciate that the "magic flag" in the Info.plist would just be a
> signal to do something tricky.
> I tried setting -Dprism.order=sw in the Info.plist, thinking that would
> trick things into not requiring the discrete GPU, but all that happened
> when I did that was that I ended up with a pixel-doubled window instead of
> nice crisp retina graphics.  It still activated the discrete GPU.
>
> Scott
>
>
> On Mon, May 25, 2015 at 12:03 PM, Mike Hearn <mike at plan99.net> wrote:
>
>> I believe the tricky part is not setting the magic flag in your Info.plist
>> file but rather handling the GL context changes on the fly. It
>> requires/would require some code in the Mac GL specific part of JavaFX.
>> Otherwise if you force it to integrated then some other app causes a switch
>> to discrete, the app might die because its GL surface just vanished.
>>
>> On Mon, May 25, 2015 at 5:30 PM, Scott Palmer <swpalmer at gmail.com> wrote:
>>
>>> I've noticed that it is not possible to run a Java GUI app (Swing or
>>> JavaFX) on a MacBook Pro without it activating the discrete graphics and
>>> therefore reducing battery life.
>>>
>>> I believe it is automatically triggered by the use of OpenGL.  Unless you
>>> explicitly code for the integrated adapter, I don't think you can use
>>> OpenGL without the discrete adapter kicking in.  It would be nice if
>>> packaged app bundles done with the javapackager had an entry in the
>>> Info.plist that would signal that the application does not require the
>>> discrete adapter.
>>>
>>> This appears to already be filed as a JDK bug at
>>> https://bugs.openjdk.java.net/browse/JDK-8041900 but it doesn't look like
>>> it is getting much attention.  Is it likely to be addressed for 9 or an
>>> 8uX
>>> release?
>>>
>>>
>>> Regards,
>>>
>>> Scott
>>>
>>


-- 
Best regards, Sergey.