Jump to content

Poor Performance on Ultrabook vs. Phone


Recommended Posts

Hi all, I have been working on a game. It's unoptimized in many respects, but I noticed something truly strange about its performance: 

On my Pixel 2 phone, the performance is acceptable (30-60 fps), but on my HP Spectre x360 ultrabook, the performance is a virtual slideshow, around 5 fps. The performance is better on my Nexus 5X, and on my powerful desktop PC it's fine as well. The slowness on the Ultrabook is irrespective of browser (though Chrome performs best).

The ultrabook has Intel HD Graphics 620. Other WebGL demos seem to run fine (pixi, 2D and 3D). It profiles much higher than my Pixel 2 for WebGL.

About the game:

It is a roguelike style RPG with tiled maps with a 1-2 sprites for each tile. Because of this I initially expected number of draw calls as the culprit, so I set all tiles that are not yet seen or are offscreen to `visible = false`. However, the ultrabook was still a slideshow.

Next I downloaded the extension WebGL Insight. I noticed that under Resources -> Buffers -> Buffer2, the Buffer is an array with 24,000 elements. I don't know the inner workings of WebGL, and so I don't know the exact significance of this array, but the length seemed suspicious.

Under Resources -> Textures, there are 205 textures.

In the Chrome profiler, 87% of total time (20% of self time) is used by `Function Call -> Animation Frame Fired`. Next is Composite Layers (6.6% self / 6.6% total). Then renderWebGL (5.3% self / 27.5% total). Then updateTransform (5.2% self / 5.8% total).

Does anyone have any ideas? Is there a precedent for these kinds of platform inconsistencies?

Link to comment
Share on other sites

Welcome to the forums!

Good report!

If only you read other threads about tilemaps ;) 

1. You need spritesheets, not single frames. Put it with TexturePacker or use . This subforum contains many threads about this. Main tutorial https://github.com/kittykatattack/learningPixi explains it too.

2. You can organize your map into chunks, every chunk is PIXI.Graphics with lots of beginTextureFill's. That way you'll save time on refilling dynamic buffer each frame

3. https://github.com/pixijs/pixi-tilemap/ is more suited for tiles than Graphics.

4. Culling: if your map is 400x400 tiles you really dont need all of them  fitting in buffer each frame. In "lesson1_5" of non-finished project https://github.com/ivanpopelyshev/pixi-starfighter there is tilemap implementation that uses graphics , but you can use same technique for sprites. Basically, refill the tilemap each time camera touches side of "calculated" screen.

Maybe you need only 1. . If its not enough, try 2,3 and 4 :)

Link to comment
Share on other sites

I like it when people first spend some time debugging and then report at forum. Its much easier to work with them.

Also, switch off "antialias:true" if you use it. Its trashing performance on slow devices.

Resources -> Buffers -> Buffer2, the Buffer is an array with 24,000 elements

that's fine, its our usual multitexturing buffer. 

Resources -> Textures, there are 205 textures.

Do you use spritesheets?

Link to comment
Share on other sites

Thanks for the tips, Ivan. I'm not using spritesheets yet, because not using them made it simpler to prototype new content for the game. But it seems that the scales have tipped and it's time for me to implement them. I'll give that a shot, and if that fails, I'll see if tilemaps make a difference.

Link to comment
Share on other sites

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.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...