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.
