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