Understanding Hardware Acceleration on Mobile Browsers http://www.sencha.com/blog/understanding-hardware-acceleration-on-mobile-browsers Our own WebKit genius, Ariya Hidayat, is back to explain what happens behind the scenes with mobile browsers, vector graphics, and shed light on interactions with the GPU. en-us ariya@sencha.com Copyright 2011 2011-07-15T17:00:23+00:00 Comment by Iris Another great post from you, Ariya!  You’re always so informative Another great post from you, Ariya!  You’re always so informative smile

]]> Wed, 17 Aug 2011 20:42 GMT http://www.sencha.com/blog//understanding-hardware-acceleration-on-mobile-browsers#id:25436#date:20:42 Comment by engineer Bravo, me parece, es la frase admirable   file Bravo, me parece, es la frase admirable

 
file

]]> Tue, 16 Aug 2011 19:50 GMT http://www.sencha.com/blog//understanding-hardware-acceleration-on-mobile-browsers#id:25392#date:19:50 Comment by Ariya Hidayat That’s the outside of the scope of this blog entry, but the short answer is “it depends”. For example, some old-generation GPU may have problem with complicated glyphs used to render the text and thus the CPU needs to provide some assistance, e.g. performing path breakdown and simplification. Dual- or quad-core processor, with support for vectorized or data-level parallelism, can perform some initial operations on various graphics algorithm, which would help the GPU a lot. That’s the outside of the scope of this blog entry, but the short answer is “it depends”. For example, some old-generation GPU may have problem with complicated glyphs used to render the text and thus the CPU needs to provide some assistance, e.g. performing path breakdown and simplification. Dual- or quad-core processor, with support for vectorized or data-level parallelism, can perform some initial operations on various graphics algorithm, which would help the GPU a lot.

]]> Mon, 08 Aug 2011 18:02 GMT http://www.sencha.com/blog//understanding-hardware-acceleration-on-mobile-browsers#id:25027#date:18:02 Comment by Mobile Money Machines This is a great explanation on quite a tricky topic so thanks for sharing. I have one quick question if that’s OK. You mention that when building a browser, MOST of the primitive drawing is delegated to the GPU. Are there any examples of where this is not the case and it is in fact it makes sense to leave the CPU to do the work? Thanks This is a great explanation on quite a tricky topic so thanks for sharing.

I have one quick question if that’s OK. You mention that when building a browser, MOST of the primitive drawing is delegated to the GPU. Are there any examples of where this is not the case and it is in fact it makes sense to leave the CPU to do the work?

Thanks

]]> Sat, 06 Aug 2011 00:50 GMT http://www.sencha.com/blog//understanding-hardware-acceleration-on-mobile-browsers#id:24930#date:00:50 Comment by Gaurav Mishra Very Robust! explanation I think need to read that again :- ) Very Robust! explanation
I think need to read that again :- )

]]> Tue, 02 Aug 2011 07:40 GMT http://www.sencha.com/blog//understanding-hardware-acceleration-on-mobile-browsers#id:24769#date:07:40 Comment by Trygve Lie @Ariya I see. It would be nice if the device / OS vendors would provide some more insight into these subjects. I must say I would like to see more live crash tests related to these topics. That might give us some more insight to where the limitations are. @Ariya I see. It would be nice if the device / OS vendors would provide some more insight into these subjects.

I must say I would like to see more live crash tests related to these topics. That might give us some more insight to where the limitations are.

]]> Tue, 19 Jul 2011 10:52 GMT http://www.sencha.com/blog//understanding-hardware-acceleration-on-mobile-browsers#id:24242#date:10:52 Comment by Ariya @Trygve I don’t know the answer to your question. One thing I omitted from the blog entry is the role of the underlying graphics stack. In the case of iOS, CoreAnimation also plays an important role. If it has support for swapping the texture as needed (which I suspect it is the case, though it’s hard to verify it since CA is not open-source), then it may push and pop the textures as needed, making it more difficult to find out whether a certain textured layer (associated with your element) is eating the GPU memory or not. The way I describe it is usually as follows: all the trick with translate3d/scale3d/opacity just gives a hint (albeit a strong one) to the graphics stack to keep the layer as long as possible in the GPU. Whether it is guaranteed to be the case of not is different story. @Trygve I don’t know the answer to your question. One thing I omitted from the blog entry is the role of the underlying graphics stack. In the case of iOS, CoreAnimation also plays an important role. If it has support for swapping the texture as needed (which I suspect it is the case, though it’s hard to verify it since CA is not open-source), then it may push and pop the textures as needed, making it more difficult to find out whether a certain textured layer (associated with your element) is eating the GPU memory or not. The way I describe it is usually as follows: all the trick with translate3d/scale3d/opacity just gives a hint (albeit a strong one) to the graphics stack to keep the layer as long as possible in the GPU. Whether it is guaranteed to be the case of not is different story.

]]> Mon, 18 Jul 2011 18:14 GMT http://www.sencha.com/blog//understanding-hardware-acceleration-on-mobile-browsers#id:24206#date:18:14 Comment by Andrea Cammarata Great post! Great post!

]]> Mon, 18 Jul 2011 15:36 GMT http://www.sencha.com/blog//understanding-hardware-acceleration-on-mobile-browsers#id:24200#date:15:36 Comment by Trygve Lie Very good post. It’s pretty clear that using the GPU does come with a price (memory allocation) as you point out. Is there a good way to / thumb of rule on how to keep control of this memory allocation? Let’s take a simple example: Let’s say we have a document with 20 elements (think flip board) with added translate3d. These elements are intended to be moved from position A to B and we only move one element from A to B at a time. Will all 20 elements allocate memory in the GPU or will memory be allocated only during the animation of a element from A to B? I would expect that all 20 elements will allocate memory. If so; would an approach where we apply translate3d to the element moved from A to B only during movement be a memory saving approach? Very good post.

It’s pretty clear that using the GPU does come with a price (memory allocation) as you point out. Is there a good way to / thumb of rule on how to keep control of this memory allocation?

Let’s take a simple example: Let’s say we have a document with 20 elements (think flip board) with added translate3d. These elements are intended to be moved from position A to B and we only move one element from A to B at a time. Will all 20 elements allocate memory in the GPU or will memory be allocated only during the animation of a element from A to B?

I would expect that all 20 elements will allocate memory. If so; would an approach where we apply translate3d to the element moved from A to B only during movement be a memory saving approach?

]]> Mon, 18 Jul 2011 09:25 GMT http://www.sencha.com/blog//understanding-hardware-acceleration-on-mobile-browsers#id:24194#date:09:25 Comment by David Kaneda Awesome post! Awesome post!

]]> Mon, 18 Jul 2011 01:19 GMT http://www.sencha.com/blog//understanding-hardware-acceleration-on-mobile-browsers#id:24184#date:01:19 Comment by Jamie Avins Nice post Ariya! Nice post Ariya!

]]> Mon, 18 Jul 2011 00:27 GMT http://www.sencha.com/blog//understanding-hardware-acceleration-on-mobile-browsers#id:24183#date:00:27