Detect Graphics card performance - JS

后端 未结 7 1738
轮回少年
轮回少年 2021-01-30 09:06

This is a longshot - is there anyway to detect poor vs strong graphics card performance via a JS plugin?

We have built a parallax site for a client, it stutters on lower

相关标签:
7条回答
  • 2021-01-30 09:23

    You might consider checking to see if the browser supports window.requestAnimationFrame, which would indicate you are running in a newer browser. Or alternatively consider checking jQuery.fx.interval.

    You could then implement a custom function to gauge the available processing power. You might try using a custom easing function which can then be run through a function like .slideDown() to get an idea of the computation power available.

    See this answer to another question for more ideas on how to check performance in javascript.

    0 讨论(0)
  • 2021-01-30 09:24

    If the browser is ultra-modern and supports requestAnimationFrame, you can calculate the animation frame rate in realtime and drop your animation settings for slower machines. That's IE 10, Firefox 4, Chrome 10, and Safari 6.

    You would essentially create a 'tick' function that runs on a requestAnimationFrame() callback and tracks how many milliseconds pass between each tick. After so many ticks have been registered, you can average it out to determine your overall frame rate. But there are two caveats to this:

    1. When the tab is in the background requestAnimationFrame callbacks will be suspended -- so a single, sudden delay between frames of several seconds to many minutes does not mean it's a slow animation. And:

    2. Simply having a JavaScript gauge running on each animation frame will cause the overall animation to slow down a bit; there's no way to measure something like that without negatively impacting it. Remember, Heisenberg's a bastard.

    For older browsers, I don't know of any way to reliably gauge the frame rate. You may be able to simulate it using setTimeout() but it won't be nearly as accurate -- and might have an even more negative impact on performance.

    0 讨论(0)
  • 2021-01-30 09:25

    This might be the risk/benefit based decision. I think that you will have to make important, but tough decision here.

    1) If you decide to have two verions, you will have to spend some time to:

    • figure out fast, non intrusive test
    • spend time implementing that
    • roll it into production

    and you will most probably end up with incorrect implementation, for example at the moment my computer is running 70 chrome tabs, VLC with 1080p anime, and IntellijIDEA

    The probability the my MBP, 2012 model will be detected as "slow" computer is high, at least now.

    False positives are really hard to figure out.

    2) If you go for one version you will have to choose between HD and Lo-Fi, as @Patrick mentioned, which is again mistake in my opinion.

    What i will suggest is that you go to Google Analytics, figure out browser distribution (yes, i know that it can be misleading, but so can any other test) and based on that (if majority of users are Chrome + modern IE/FF go with HD version, BUT spend some time figuring out optimisation strategy.

    There are always things that could be done better and faster. Get one older laptop, and optimise until you get decent FPS rate. And thats it, yo as a developer need to make that decision, that is your duty.

    3) If from the Browser distribution you figure out that you absolutely must go with Lo-Fi version, well, try to think is the "downgrade" worth it, and implement it only if that is your last resort.

    0 讨论(0)
  • 2021-01-30 09:32

    requestAnimationFrame (rAF) can help with this.

    You could figure out your framerate using rAF. Details about that here: calculate FPS in Canvas using requestAnimationFrame. In short, you figure out the time difference between frames then divide 1 by it (e.g. 1/.0159s ~= 62fps ).

    Note: with any method you choose, performance will be arbitrarily decided. Perhaps anything over 24 frames per second could be considered "high performance."

    0 讨论(0)
  • 2021-01-30 09:45

    This is where "old school" loading screens came in useful, you could render something complex either in the foreground (or hidden away) that didn't matter if it looked odd or jurky -- and by the time you had loaded your resources you could decide on what effects to enable or disable.

    Basically you would use what jcage mentioned for this, testing of frame-rate (i.e. using a setInterval in conjuction with a timer). This isn't always 100% reliable however because if their machine decides in that instance to do a triple-helix-backward-somersault (or something more likely) you'd get a dodgy reading. It is possible, depending on the animations involved, to upgrade and downgrade the effects in realtime — but this is always more tricky to code, plus your own analysis of the situation can actually sometimes cause dropped performance.

    0 讨论(0)
  • 2021-01-30 09:45

    Firefox has a build in list of graphic cards which are not supported: https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers the related help acrticle.

    But you only can indirectly test them when accessing WebGL features...

    http://get.webgl.org/troubleshooting/ leads you to the corresponding browser provider when there are problems. When checking the JS code you will see that they test via

    if (window.WebGLRenderingContext) {
        alert('Your browser does not support WebGL');
    }
    

    if you have an up to date graphic card.

    0 讨论(0)
提交回复
热议问题