4 ms·
How often does a native developer "trick" their framework to trigger an implementation detail to get performance gains? That's really I can think about when I h
by Me1000 13y ago
How often does a native developer "trick" their framework to trigger an implementation detail to get performance gains? That's really I can think about when I hear web developers talk about "hardware accelerated CSS".
- talmand 13y agoHow is using a CSS feature "tricking" the framework? If it's a trick then native developers are using the same trick when they use the device's video hardware, for the same reasons, instead of relying on the software renderer.
- Me1000 13y agoIt's a trick because you set a 3D property on a style and _sometimes_ the the browser will use the GPU instead. We've actually seen browsers (Safari on iOS) turn off this implementation detail in same cases where it used to be enabled. Your video example is interesting, but for a Cocoa developer they'd just create a video player object and give it a file to play. Cocoa doesn't make any guarantee it will be hardware accelerated (neither does the HTML5 spec for that matter), but you can be assured that if Cocoa says it can play a video it will be able to play it properly; you, as the person using the framework, never have to worry about any implementation details.
- talmand 13y agoWhat 3D property are you speaking of? Maybe you're meaning that using a 2 dimensional transition corresponds to a 3D property that causes the hardware to kick in then I suppose you make sense. But the thing is, I fail to see how that's a "trick" when it's an implemented feature of CSS. Also, if a browser vendor turns off the feature then that's a problem of the vendor and not CSS. Again, you are labeling a feature as a "trick" to paint a negative picture of web apps. Believe me, there's plenty of room for improvement in the area of web apps but your example isn't holding up. I wasn't speaking of playing videos to the screen. I was referring to the hardware in the device that renders pixels to the display, specifically the hardware accelerated part. That's the PC gamer side of me referring to that hardware as video cards or video hardware. But to combine your Safari and Cocoa examples. If Safari says that it doesn't have hardware accelerated CSS features enabled then you know that the feature doesn't work as nicely as you would want, but the transition will still happen. If Safari says that it is enabled... nah, never mind. Regardless of hardware support or not; you, as the person using CSS, never have to worry about any implementation details. In fact, since CSS isn't a framework, it's far more efficient to use CSS over a Javascript framework anyway, regardless of hardware support.
- ihsw 13y agoSome things aren't tricks, they're just different. This has lots of information on jQuery and performance choices: http://learn.jquery.com/performance/ http://learn.jquery.com/performance/ Some ways of going about things are more verbose, but the difference in performance isn't negligible. There will always be a balance between verbosity and performance. Granted this page specifically pertains to jQuery, but most libraries expose ways for developers to start going down the long road of performance tuning.
- paulirish 13y agoAs the original author of those 7 performance tips, I suggest you ignore them. :) Spending 10 minutes with the DevTools timeline (or network waterfall) will give you way better insight on your perf issues than following these microptimizations.