Starling Forum

1. 

   BladePoint
   

   Competent Bird
   Joined: Jan '13
   Posts: 68

   

   BladePoint

   Competent Bird
   Joined: Jan '13
   Posts: 68

   I have a quad with a large rectangular texture made of several linear gradients. What if I created the same thing visually using several smaller, texture-less quads lined up next to each other and used setVertexColor to make the color gradients? I would save a lot of video memory since none of the quads have textures, but then there are more vertices to render. Which way would be better performance-wise?

   I'm in a similar situation with a large, oval-textured quad which is a mask for another quad. Would it be better to use a Canvas, which would not use a texture? But I noticed the larger the dimensions you pass into drawEllipse, the more vertices the Canvas will have.

   Posted 6 months ago #
2. 

   JohnBlackburne
   

   Moderating Owl
   Joined: Apr '15
   Posts: 813

   

   JohnBlackburne

   Moderating Owl
   Joined: Apr '15
   Posts: 813

   There’s nothing obviously wrong with either approach. There is no performance benefit to saving a lot of video memory, unless you are concerned you might not have enough, in which case it won’t so much run slow as not run at all. The GPU memory limits were increased with AIR 29.

   Apart from that there is no problem at all using lots of smaller Quads, i.e. lots of vertices, to describe it. Starling copes very well with tens of thousands of vertices, though there are a couple of things to look out for. First look out for anything that stops them being batched, as you don’t want to use hundreds or thousands of draw calls.

   Second the main cost of drawing lots of vertices is uploading the vertex data. If you are doing this every frame, e.g. if the vertices are being updated every frame, it might be costly. Ideally find some other way of updating them, such as setting the x and y of a containing Sprite to move them.

   Posted 6 months ago #
3. 

   BladePoint
   

   Competent Bird
   Joined: Jan '13
   Posts: 68

   

   BladePoint

   Competent Bird
   Joined: Jan '13
   Posts: 68

   Hmm, that's interesting. Thanks for the info. I'm actually not using Starling the way it was intended. I don't use a texture atlas and most of my graphic resources are traditional Flash vector art which gets drawn to bitmapdata then gets turned into textures on demand, so most of my draw calls are not batched. I guess that approach wouldn't work as well on mobile, but it seems to work fine on desktop.

   Posted 6 months ago #
4. 

   JohnBlackburne
   

   Moderating Owl
   Joined: Apr '15
   Posts: 813

   

   JohnBlackburne

   Moderating Owl
   Joined: Apr '15
   Posts: 813

   There‘s nothing wrong with that. Starling supports multiple textures, but can’t avoid a draw call for each. If you have a few textures then your draw call count should be at least as high as the number of them.

   If the draw call is still high, it could happen two ways. If it’s because you have a lot of textures, each small, consider combining them into larger textures. You can generate the BitmapData the same way, then use BitmapData.draw or .copyPixels to assemble them into larger BitmapData which get turned into Textures. You then create SubTextures from these using the same coordinates you passed to .draw / .copyPixels

   If your Texture count is small but your draw call number high you might be able to optimise it by drawing them differently. The manual has a good explanation:

   http://manual.starling-framework.org/en/#_minimize_state_changes

   Posted 6 months ago #
5. 

   bwhiting
   

   Expert Bird
   Joined: Dec '12
   Posts: 320

   

   bwhiting

   Expert Bird
   Joined: Dec '12
   Posts: 320

   @BladePoint

   most of my graphic resources are traditional Flash vector art which gets drawn to bitmapdata then gets turned into textures on demand

   Depending on your graphics you could always render them into a spritesheet on the cpu yourself, there are as3 MaxRects implementations out there you could use.
   You can even create the spritesheets on the gpu too using render to texture. If your assets are not too large and don't change too much then you can pack quite a few together.

   Posted 6 months ago #
6. 

   BladePoint
   

   Competent Bird
   Joined: Jan '13
   Posts: 68

   

   BladePoint

   Competent Bird
   Joined: Jan '13
   Posts: 68

   Second the main cost of drawing lots of vertices is uploading the vertex data. If you are doing this every frame, e.g. if the vertices are being updated every frame, it might be costly. Ideally find some other way of updating them, such as setting the x and y of a containing Sprite to move them.

   I just wanted to follow up on this... If I have a quad that slides from the left side of the screen to the right side of the screen, just tweening the quad's x position will be more costly than if I put that quad in a sprite and tween the sprite's x position instead?

   Posted 5 months ago #
7. 

   JohnBlackburne
   

   Moderating Owl
   Joined: Apr '15
   Posts: 813

   

   JohnBlackburne

   Moderating Owl
   Joined: Apr '15
   Posts: 813

   A single quad? I don’t think it will make much difference either way. Tens of thousands of quads and maybe you have to worry about performance and take care of how often you upload the data for them. But if you have so many you have issues like: do they all move together or need to be moved independently? Do they all have the same colour/texture or can these vary?

   Posted 5 months ago #
8. 

   BladePoint
   

   Competent Bird
   Joined: Jan '13
   Posts: 68

   

   BladePoint

   Competent Bird
   Joined: Jan '13
   Posts: 68

   I probably don't have nearly enough stuff moving around on the screen for this to matter, but I was just wondering why the performance would be better by putting the quad inside a sprite. I would think the same number of calculations would have to be made, except they are performed on the sprite instead of the quad.

   Posted 5 months ago #
9. 

   JohnBlackburne
   

   Moderating Owl
   Joined: Apr '15
   Posts: 813

   

   JohnBlackburne

   Moderating Owl
   Joined: Apr '15
   Posts: 813

   You set the x and y of a DisplayObject it updates its Matrix. You set the x and y of a Sprite it updates its Matrix. These get combined to produce the Matrix used to draw the Quad to screen. So there is a tiny amount of overhead in using a Sprite, but the more objects you have inside your Sprite the more benefit you see from only having to update one (x, y) to move them, one r to rotate them etc., as well as gaining better control over when they are drawn.

   Have a look at the Benchmark panel of the demo app

   ( /Starling/samples/demo/src/scenes/BenchmarkScene.as )

   That draws 10,000+ moving textured quads by putting them all in a Sprite and changing its scale and r to move them.

   Posted 5 months ago #

RSS feed for this topic

Reply

You must log in to post.