4 ms·
Nope, it is a great idea on mobile, at least for iDevices and I imagine most Android devices. Especially with high dpi screens, leaving everything on the CPU is
by DougBTX 13y ago
Nope, it is a great idea on mobile, at least for iDevices and I imagine most Android devices. Especially with high dpi screens, leaving everything on the CPU is too slow.
- wnevets 13y agoI think in one of the web performance talks by Addy Osmani he said it should be used sparely at best. Maybe I'll look it up to check
- DougBTX 13y agoI'm coming at this from a native development perspective, so there are large gaps in my knowledge. In particular, I've not done any benchmarks, so take what I say with a large grain of salt. Any real performance advice will come down to comparing alternative ways of implementing a particular effect, rather than a blanket, "do this." My understanding is that when a browser renders a page, the output bitmap is kept in a render buffer, which then gets composited with other buffers when being written out to the display. Filling the render buffers is slow (largely on the CPU), and compositing is fast (largely on the GPU). Using the 3D transform effects moves elements on the page into separate buffers. Performance would be improved by having fewer buffers, and by re-drawing buffers less frequently. Best case is to have a single buffer rendered once, I think that's what you're referring to by Addy's suggestion. But, if you're going to have elements moving relative to each other, it is faster to render them both once, then re-composit multiple times on the GPU, rather than re-render the whole scene on the CPU each time there is a change. That at least is what I mean by, "moving computation to the GPU."