Comments on: Shape vs. Sprite

By: Gonçalo

Gonçalo — Fri, 23 Mar 2012 19:33:51 +0000

Thank you! I enjoyed this article, just what I was looking for.

By: jackson

jackson — Wed, 07 Mar 2012 23:14:56 +0000

You mean a comparison between Bitmap and Shape + beginBitmapFill?

By: Arby

Arby — Wed, 07 Mar 2012 22:19:40 +0000

I know I’m late to the party here, but can I point out that you should also be testing a sprite bitmap, VS a shape with a bitmap fill !

Please email me if you try this.

By: 2012提升as3程序性能的十大要点 | Flash开发者大会

2012提升as3程序性能的十大要点 | Flash开发者大会 — Tue, 06 Mar 2012 09:19:02 +0000

[...] 7.使用专用的函数或者类，而不是通用的 Sprite比MovieClip省内存，Shape比Sprite省内存，BitmapData的copyPixels方法比draw方法更快。 8.尽量少的使用静态访问 [...]

By: RR

RR — Tue, 20 Sep 2011 14:16:56 +0000

Thank you for posting this analysis, I was looking all over for such comparisons and tests and also wanted to understand the differences between shape and sprite – your’s was the most thorough and lucid. Thanks!

By: Destroy Today / Blog Archive » DisplayObjectUtil class added to DestroyFramework

Fri, 04 Dec 2009 16:02:48 +0000

[...] benefit from fSprite’s methods, such as the Shape class. After seeing Jackson Dunstan’s comparison of the two, I realized I could be saving a solid amount memory and instantiation speed by using Shape instead [...]

By: jackson

jackson — Sun, 01 Nov 2009 02:10:01 +0000

Yes, Sprites clearly have more functionality. Hence my conclusion:

So if you’re in need of better performance and can live with the limited feature set of Shapes…

As for your disagreement about Shapes not being buttons at all, I think differently. While they would be very poor buttons directly given that they are not InteractiveObjects and thus have no mouse events, you could use a stage event listener, derive which shape was clicked, and respond as you would. This makes them poor buttons in my view.

Thank you for the lengthy comment! It’s good to see others are passionate about such things. :)

By: gio

gio — Sun, 01 Nov 2009 01:55:10 +0000

Without considering the differences in memory dimensions of the single properties Sprite is three level down the hierarchy so it has more than 50% more properties than Shape.
28 (number of Shape Properties)

+6 (added InteractiveObject Properties)
+4 (added DisplayObjectContainer Properties)
+6 (added Sprite Properties)

About the rendering differences.
does the comparison make sense?
As you noted at the beginning of your post “Shapes are more limited than Sprites in many ways”
A shape rendering performance can be evaluated and measured only in relation to the type of graphics used inside it…
Shapes don’t make poor buttons, they don’t make buttons at all…
Shape exist almost exclusively to use the ‘graphics’ inside them…

A Sprite rendering performance depend not only on the graphics but on all the added stuff…
A Sprite being a DisplayObjectContainer has children to take care of…
A sprite being an InteractiveObject may have to take care of ‘interactivity’ issues.
A Sprite rendering performance can be evaluated and measured only in relation to the type of children and interactive events used inside it.

imho it’s like comparing weight and performance of a pair of legs and an entire body:

- you don’t need to create 100000 of legs and the same number of bodies to confirm that it takes more time to create a body than a pair of legs…
- they both run, and (without the upper body doing anything else) they run the same.
- legs are clearly lighter, it’s pretty obvious that they weight less than a body that normally contains them. (read ‘legs’ as ‘graphics’ property here)

By: Weekly Shared Items – 27. October, 2009 | TOXIN LABS - weblog of a german design student from wuerzburg

Tue, 27 Oct 2009 05:05:20 +0000

[...] Shape vs. Sprite [...]

By: jackson

jackson — Mon, 26 Oct 2009 16:24:12 +0000

You’re very welcome. I too am thinking of adding a BaseShape class to my own framework based on these results. By the way, check out my updated memory findings. It’s not quite double the memory on Windows XP.