Webgl On or Off?

Get help using Construct 2

Post » Mon Feb 13, 2017 11:18 am

@Ashley Any suggestions? is a bug or ??

there is a huge difference between WebGL on and off, is not something that we can ignore easily
B
38
S
22
G
50
Posts: 211
Reputation: 29,005

Post » Mon Feb 13, 2017 11:56 am

What is happening on your screen at the time the CPU goes up and FPS goes down?

There has to be some event causing that.
Banned User
B
23
S
6
G
58
Posts: 1,229
Reputation: 34,540

Post » Mon Feb 13, 2017 12:11 pm

So I looked in to this and basically the problem is the CPU measurement isn't always accurate. It's based off timers in JS since the real data isn't actually available.

On a HTC 10 the results were the same between webgl and canvas2d. On an iPad Air 2 though I could see what was being talked about: the FPS is a steady 60 either way, but in canvas2d mode cpu measures around 15-20, and in webgl it generally sticks to about 80. Frankly I don't know why. I am certain WebGL is still faster, and I can prove it: we have performance tests using webgl and canvas2d and the results on the same device are:

webgl: 13472 sprites
canvas2d: 2672 sprites
Therefore, WebGL is ~5x faster on the iPad Air 2. This is the number I trust, because it tests the limits of the device. This is such a huge improvement that I've considered disabling canvas2d mode at some point in future, because there's no reason to deliberately use it. Choosing it is just a huge deoptimisation.

So I'd conclude the problem is the cpu measurement is inaccurate, which I knew anyway. I'm not sure why there is such a big variation though. One aspect is that sometimes browsers just save the list of draw calls and run them on another thread, which means the cpu timer (which only measures the main thread) doesn't include them. Alternatively it can run the draw calls on the main thread and then it does get included in the cpu timer. So if the webgl draw calls happen on the same thread, but canvas2d happens on a different thread, the webgl result includes draw calls but the canvas2d result doesn't. I'm not sure how that could produce such a huge difference though.

Interestingly I did sometimes see the webgl cpu time for the iPad fall down to as low as 15-20, before increasing again. So that shows it is possible to get those results. I think it's just the timer being inaccurate. You should be skeptical of the cpu measurement.
Scirra Founder
B
387
S
230
G
87
Posts: 24,249
Reputation: 192,240

Post » Mon Feb 13, 2017 1:25 pm

Ashley wrote:So I looked in to this and basically the problem is the CPU measurement isn't always accurate. It's based off timers in JS since the real data isn't actually available.

On a HTC 10 the results were the same between webgl and canvas2d. On an iPad Air 2 though I could see what was being talked about: the FPS is a steady 60 either way, but in canvas2d mode cpu measures around 15-20, and in webgl it generally sticks to about 80. Frankly I don't know why. I am certain WebGL is still faster, and I can prove it: we have performance tests using webgl and canvas2d and the results on the same device are:

webgl: 13472 sprites
canvas2d: 2672 sprites
Therefore, WebGL is ~5x faster on the iPad Air 2. This is the number I trust, because it tests the limits of the device. This is such a huge improvement that I've considered disabling canvas2d mode at some point in future, because there's no reason to deliberately use it. Choosing it is just a huge deoptimisation.

So I'd conclude the problem is the cpu measurement is inaccurate, which I knew anyway. I'm not sure why there is such a big variation though. One aspect is that sometimes browsers just save the list of draw calls and run them on another thread, which means the cpu timer (which only measures the main thread) doesn't include them. Alternatively it can run the draw calls on the main thread and then it does get included in the cpu timer. So if the webgl draw calls happen on the same thread, but canvas2d happens on a different thread, the webgl result includes draw calls but the canvas2d result doesn't. I'm not sure how that could produce such a huge difference though.

Interestingly I did sometimes see the webgl cpu time for the iPad fall down to as low as 15-20, before increasing again. So that shows it is possible to get those results. I think it's just the timer being inaccurate. You should be skeptical of the cpu measurement.





Thanks for the info, I think I get what you saying but,

Sorry big Noob question I haven't got any experience on mobile games, until now my approach for doing a game for mobile for what I understand from tutorials, was test continuously on mobile throughout wireless and look very closely the cpu+Fps measurement and the gameplay, then from there determine if that game can run on mobile, so this way I don't spend the time finishing a game that after will not run well on mobiles.
Now with this info that you shared with us I'm a bit confuse, the question is, how will I test mobile games now, I mean what I should I look for or watch out?
what process do you advise to follow, when we testing if the game is worth or not for mobile?
is better I ask to you Ashley because you are the one that knows best of construct2 and you can share valuable tips and tricks.

Thanks a lot for your time, and for finding time to look into this, I really appreciated.
B
38
S
22
G
50
Posts: 211
Reputation: 29,005

Post » Mon Feb 13, 2017 1:27 pm

The FPS is the most important number to look at. The CPU measurement isn't very reliable (as this thread shows). Besides, if the FPS is 60, it is running well, regardless of the CPU measurement. So really you just want to look for a good FPS. Everything else is just to help you diagnose a poor FPS.
Scirra Founder
B
387
S
230
G
87
Posts: 24,249
Reputation: 192,240

Post » Mon Feb 13, 2017 1:31 pm

lamar wrote:What is happening on your screen at the time the CPU goes up and FPS goes down?

There has to be some event causing that.


@lamar there are a few Capx on the first page
B
38
S
22
G
50
Posts: 211
Reputation: 29,005

Post » Mon Feb 13, 2017 1:34 pm

Ashley wrote:The FPS is the most important number to look at. The CPU measurement isn't very reliable (as this thread shows). Besides, if the FPS is 60, it is running well, regardless of the CPU measurement. So really you just want to look for a good FPS. Everything else is just to help you diagnose a poor FPS.



Ho ok, I see now, thanks a lot Ashley, take care 8-)
B
38
S
22
G
50
Posts: 211
Reputation: 29,005

Post » Mon Feb 13, 2017 9:47 pm

Ashley wrote:The FPS is the most important number to look at. The CPU measurement isn't very reliable (as this thread shows). Besides, if the FPS is 60, it is running well, regardless of the CPU measurement. So really you just want to look for a good FPS. Everything else is just to help you diagnose a poor FPS.


that is the problem
i have a very bad fsp (between 7-9)
B
45
S
16
G
8
Posts: 792
Reputation: 8,306

Previous

Return to How do I....?

Who is online

Users browsing this forum: No registered users and 13 guests