Yes, we know that it is a perfectly fine entry level GPU capable of
supporting JavaFX graphics requirements. I shouldn't use the word "bad"
card. What I'm saying is that you will have to add it to your blacklist
if you don't want JavaFX to use it for rendering due to poor framerate.
- Chien
On 8/6/2014 9:57 AM, Mike Hearn wrote:
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.y...@oracle.com
<mailto:chien.y...@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.gra...@oracle.com <mailto:james.gra...@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.
