GBear Posted March 18, 2016 Share Posted March 18, 2016 hi... hi i tested with under image code like this <<draw 50000's buunys>> Quote for(var i = 0; i < 50000; ++i) { var spr = PIXI.Sprite.fromImage('assets/bunnys.png'); spr.position.set(Math.random()*1200 + 200, Math.random()*400 + 100); spr.scale.set(2, 2); stage.addChild(spr); <<draw 50000's buunys_big >> Quote for(var i = 0; i < 50000; ++i) { var spr = PIXI.Sprite.fromImage('assets/bunnys_big.png'); spr.position.set(Math.random()*1200 + 200, Math.random()*400 + 100); stage.addChild(spr); } this two code has same performance.. T-T Isn't Texture size related of performance? is only related by scale of sprite size(of vertex size)? bunnys.png bunnys_big.png Quote Link to comment Share on other sites More sharing options...
ivan.popelyshev Posted March 18, 2016 Share Posted March 18, 2016 Welcome to webgl. Fragment shader is one of the most slow things there, and it directly depends on how many pixels do you draw. Quote Link to comment Share on other sites More sharing options...
GBear Posted March 18, 2016 Author Share Posted March 18, 2016 @ivan.popelyshev TOT hi Ivan.. Quote Welcome to webgl. Fragment shader is one of the most slow things there, and it directly depends on how many pixels do you draw. Is this meaning One Big UI that only one texture like (1280*400) is better performance than generated UI(1280*400) by small pieces ? Quote Link to comment Share on other sites More sharing options...
ivan.popelyshev Posted March 18, 2016 Share Posted March 18, 2016 @GBear only a bit, if there are 100 pieces then noo, its not if there are 1000 then we'll have problem with too many updateTransform() but that will be fixed in next pixi version. If 10000 then we'll have problem with uploading large vertex buffers very frame. So you can assume that it depends heavily on the area, and every time you use a filter, you have to add an area equal to filter bounds. Quote Link to comment Share on other sites More sharing options...
totor Posted March 18, 2016 Share Posted March 18, 2016 iirc texture is loaded in texture buffer which has a fixed size let"s say 1000, so if if your big texture fits in the buffer there is no difference in rendering small or big but if your texture is for example 1001, ie 1 more than the buffer size then the texture is split so you need two buffer calls (+ switching). That's how it worked at driver level in GL but it has been years since i walked this path. Quote Link to comment Share on other sites More sharing options...
ivan.popelyshev Posted March 18, 2016 Share Posted March 18, 2016 And if you use mipmaps and render big texture into small area, it will actually use smaller texture for it - and again, area will be more important parameter than texture size Quote Link to comment Share on other sites More sharing options...
GBear Posted March 19, 2016 Author Share Posted March 19, 2016 Quote and again, area will be more important parameter than texture size what is this meaning? Quote Link to comment Share on other sites More sharing options...
ivan.popelyshev Posted March 19, 2016 Share Posted March 19, 2016 6 hours ago, GBear said: what is this meaning? area. as a number of pixels you draw on screen. Quote Link to comment Share on other sites More sharing options...
GBear Posted March 20, 2016 Author Share Posted March 20, 2016 @ivan.popelyshev hi~~ Quote And if you use mipmaps and render big texture into small area, it will actually use smaller texture for it - and again, area will be more important parameter than texture size is using mipmap good for performance with v3? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.