simstratic's Forum Posts

  • Ah sorry didn't realize there's two versions of the Note 10 - yours isn't a Mali GPU - but at least it's further evidence that it's a Mali specific issue.

  • Thanks Ribis - could you please do one more thing on your Note 10 - in Chrome type chrome://gpu in the address bar, scroll down to Driver Information - what is your driver version and GL_RENDERER? Appreciate your help!

  • Ribis would you mind testing his APK on your Samsung Galaxy Note 10? That has a Mali G-series GPU too...

  • Looks like there's good activity at Chromium on this issue. Part of the problem is these issues get reported here, Phaser forums etc., but people don't follow up by reporting it to Chromium, sending their APK etc. and walk away blaming webview, Construct, Cordova etc. So I commend indy2005 for following through on this.

    To me this is looking more and more like a GPU driver specific issue, which might be anti-climatic, and Ashley might sigh a told you so.

    I just tested on the apk on my phone, a low-mid end Nokia 3.2, and no performance issues, 60fps with 25% CPU utilization, GPU metrics not available on my phone. Together with Cascade Games testing that tells us there is no performance issue on the following GPUs:

    - Mali-T830

    - Adreno 505

    - Adreno 504

    But there is a problem with Mali-G71 MP2 (the GPU in the Doogee N20). Mali uses a different renderer (driver) for T series and G series. So the problem is probably specific to Mali G series, if not only G71 MP2 itself. G71 MP2 was released in June 2016, some analytics from Q1 2019 across 36 countries, shows G71 MP2 is 1.51% of the market, and I suspect it would be less again if you were looking at the 'gamer' market. The issue might even be further limited to a specific driver version.

    So if people want to help get to the bottom of this, let's crowdsource it, download and test the APK from the Chromium issue:

    bugs.chromium.org/p/chromium/issues/detail

    Report back here with your phone model, GPU model, and if you see the same performance issue or not. Then we can compile that information and add it to the Chromium ticket. I would especially be interested for people to test on phones with Mali G-series GPUs, including more common phones like Samsung Galaxy S8 and S9, Huawei P10, P20, Honour 10, which are all G-series but a different GPU. And people to test on phones with the exact same GPU (G71 MP2) which include:

    Blackview P10000 Pro

    Cubot King Kong 3

    Doogee BL9000

    Gigaset GS290

    Gigaset GX290

    Oukitel K10

    Oukitel U23

    Oukitel WP1

    Poptel P60

    Samsung Galaxy A10

    Samsung Galaxy A20e

    Samsung Galaxy A30s

    Samsung Galaxy A40

    Samsung Galaxy A7 2018

    Samsung Galaxy A8 2018

    Samsung Galaxy M20

    Samsung Galaxy Tab A 10.1 2019

    Samsung Galaxy XCover 4s

    Ulefone Armor 3T

    Ulefone Armor 5

    Ulefone Power 3

    Ulefone Power 5

    Umidigi One Max

    Umidigi Z2

    Alcatel 3X 2019

    Alcatel 7

    Blackview BV9500 Pro

    Blackview Max 1

    Blackview P10000 Pro

    BQ RU BQ 6424L Magic O

    Cubot King Kong 3

    Cubot P30

    Cubot Power

    Cubot X19

    Doogee BL12000 Pro

    Doogee BL9000

    Doogee N100

    Doogee N20

    Doogee S50

    Doogee S70

    Doogee S80

    Elephone A4 Pro

    Elephone PX

    Elephone U

    Gigaset GS290

    Gigaset GX290

    Oppo A1

    Oppo A73

    Oppo A83

    Oppo F5

    Oppo F5 Youth

    Oukitel C17 Pro

    Oukitel K10

    Oukitel K6

    Oukitel U23

    Oukitel WP1

    Poptel P10

    Poptel P60

    Samsung Galaxy A10

    Samsung Galaxy A10e

    Samsung Galaxy A20e

    Samsung Galaxy A30

    Samsung Galaxy A30s

    Samsung Galaxy A40

    Samsung Galaxy A7 2018

    Samsung Galaxy A8 2018

    Samsung Galaxy A8 Plus 2018

    Samsung Galaxy J7 Duo 2018

    Samsung Galaxy M10s

    Samsung Galaxy M20

    Samsung Galaxy M30

    Samsung Galaxy Tab A 10.1 (2019)

    Samsung Galaxy Tab A 8.4 (2020)

    Samsung Galaxy Tab A Plus 8

    Samsung Galaxy XCover 4s

    Ulefone Armor 3

    Ulefone Armor 3T

    Ulefone Armor 5

    Ulefone Armor X5

    Ulefone Power 3

    Ulefone Power 3S

    Ulefone Power 5

    Ulefone X

    UMI Z2

    Umidigi A5 Pro

    Umidigi A7 Pro

    Umidigi One Max

    Umidigi One Pro

    Umidigi Z2

    Umidigi Z2 Special Edition

    Vernee V2 Pro

    Vernee X

    Vernee X1

  • The blacklist would only affect games using the webview, i.e. any game from any html5 engine. Games which are compiled into native apps don't use webview. Dead Cells is compiled into native C code. Fun fact is that Dead Cells actually runs it's gameplay code at 30fps, but just render at 60fps.

    Maybe you can try some of the other Android games in the Made with Construct 3 sub-forum and see how they perform on your phone.

  • The cost of ads is 20-30 FPS? I only trigger an ad on game over?

    It shouldn't be. But this is standard troubleshooting procedure. Right now you know there is difference in performance between the apk and chrome. One difference between them is admob. So if you disable the admob events, you will know IF that is causing the performance difference.

  • You could try disabling anything related to admob and see if that changes the apk performance. Would at least narrow down the problem, or rule out admob as the cause.

  • indy2005 are you using mobile specific plugins, like mobile IAP, mobile advert or possibly google play? That might be something which is different between the chrome version and the apk version...

  • Ashley question out of curiosity - are there cases where driver bugs affect cordova app performance but not chrome performance? It looks like his phone runs stock android 9 - in which case isn't the cordova app using chrome (not android system webview) so shouldn't the performance should be the same? Do debug APK have much overhead compared to a release APK?

  • Haha sorry, don't know how that line got deleted, I'll try to blame my cat for always stepping on my insert key. It did cross my mind briefly that it seemed too much of an improvement...

  • For now, you can add the children objects to a family. Use pick children (all), select the family as the child you want to pick, then use the action to move the family to a layer.

  • Looks like your javascript is being slowed by looking up the viewport coordinates every loop. Store them in a variable before the loop and javascript becomes the faster option.

    const Spritetest = runtime.objects.Sprite.getAllInstances()
    const Spritetest3 = runtime.objects.Sprite3.getAllInstances()
    const viewport = runtime.layout.getLayer(0).getViewport()
    var vl = viewport.left
    var vr = viewport.right
    var slength = spritetest.length
    
    for (i = 0; i < slength; i++){
    	Spritetest[i].x = Spritetest[i].x + Spritetest3[i].instVars.speed;	
    	if (Spritetest[i].x > vr -16 ) {
    		Spritetest[i].x = vl + 16 + (Spritetest[i].x - vr -16 ) 
    	}
    }
  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Only 50% of parents have a child, so the difference is looping through 100 parents for 50 child, vs looping through 50 child for 50 parents. I made it this way because it suits my needs and is what I want to do with it, the for each is also looping through 50 child for 50 parents.

    So technically it is an improvement over for each, which is good !! I can work with this

    Ah I missed that part sorry. My results below with event sheet modified so every parent has a child. So still a slight overhead for picking children vs picking parents, but a more sensible difference.

  • Nice benchmark - like bunnymark for scene graphs - would like to reproduce it in some other engines if I get some spare time. I got around 37,000 objects on a Ryzen 3600 - which seems very good.

    The CPU Profiler results makes sense to me. I would have expected performance at least on par with your 'forEach' method, hopefully somewhat faster without the event overhead, and that's what we see with 'PickParent'. I'm guessing 'PickChild' is slower than 'PickParent' because it probably involves array access or something, i.e. parent UID is probably stored in a normal variable because there can only be one parent, but there can be multiple children so their UIDs are probably stored in an array. Performance seems pretty close to containers already, considering the optimizations they could have done for the static contents in a container.

  • SVG are rasterized - converted from a vector format into a bitmap format - before they are used. So I suspect that time is to rasterize them, rather than load the SVG into memory. Objects that are small or not scaled far from their initial size, I would suggest converting those into regular sprites (PNG). Limit SVG usage to backgrounds and other large objects.