How to learn the identity of the graphics card?

[Mike Hearn]

The card isn't bad per se, it's just the HD4000 integrated graphics chip
that older MacBook's ship with. It's just that I'm very picky about my
framerates :)


On Wed, Aug 6, 2014 at 6:49 PM, Chien Yang <chien.yang at oracle.com> wrote:

> There isn't a public Java API support for what you want to do. However if
> you are willing to patch JavaFX in your own build, you can add the bad card
> to the GLGPUInfo blackList[] in the GLFactory class of the specific
> platform if you are using the es2 pipe. You will need to dig down into the
> native C++ code if you need to support Windows d3d pipe. This will be a
> little more work see D3DBadHardware.h for the entries. Hope this helps.
>
> - Chien
>
>
> On 8/5/2014 11:39 PM, Peter Penzov wrote:
>
>> Hi All,
>>     I'm interested how I can get the model of the GPU card using Java. Can
>> you show me some basic example?
>>
>> BR,
>> Peter
>>
>>
>> On Wed, Aug 6, 2014 at 3:02 AM, Jim Graham <james.graham at oracle.com>
>> wrote:
>>
>>  If there is a card that can't keep up with what we want it to do then we
>>> should probably be dealing with that on our end as well, whether by
>>> disabling 3D on that card or by black listing it and just falling back to
>>> sw pipeline.  We already do that with a number of embedded GPUs...
>>>
>>>                          ...jim
>>>
>>> On 8/1/14 2:27 AM, Mike Hearn wrote:
>>>
>>>  Scott is correct about the determining of the SW pipeline. To add to
>>>>> that,
>>>>> if knowing whether you are running on SW is sufficient
>>>>>
>>>>>
>>>>>  Unfortunately for the Intel HD4000 card that some older laptops have,
>>>> it
>>>> technically supports 3D but struggles to do basic shader effects at
>>>> 60fps
>>>> when running at high pixel densities. I think I posted about this
>>>> problem
>>>> before. Simpler animations work better (just) but I'd prefer to only
>>>> fall
>>>> back to that when necessary.
>>>>
>>>>
>>>>   I think the suggestion about starting out assuming that animation
>>>> will be
>>>>
>>>>> OK and then backing off is a good one, if it is practical for your
>>>>> application.
>>>>>
>>>>>
>>>>>  Given that I'll be bundling a JVM with the app anyway I think it'd be
>>>> easier and give a better UX to just patch JavaFX to expose this data
>>>> using
>>>> an API specific to my app. It obviously has it because when running with
>>>> Prism debug logging the info is printed.
>>>>
>>>>
>>>>
>