dupuqub Can you please try this. Open Construct, click Menu -> View -> Storage cleanup and post a screenshot of that here.

So I realized today, I can test this in Construct 3 by with running the Construct 2 runtime, and with the C2 runtime I am definitely still seeing an increase in GPU% (both in the debug preview window and the Windows task manager). And this isn't a really low end GPU either (Radeon RX 570). In Construct 3, there's an option with the C2 runtime for WebGL, if I turn that off, then I don't get any GPU usage (but I get higher CPU usage as it's software rendering). This makes me think you're not using WebGL in your project?

I know which thread you're talking about (Chrome vs APK), and there was some fear mongering going on there. In the vast majority of cases, the performance should be very similar - there are these rare cases where it seems like WebGL is being disabled in the APK on a specific phone or GPU driver - the Chromium team is continuing to investigate. Honestly I wouldn't worry about it, but it's still good practice to test with an APK export occasionally.

I think you may be running out of space in the browser's storage cache... there is a limit on how much a domain (in this case construct.net) can store in the cache. How much free space do you have on your C:\ drive? Do you use the beta versions of Construct?

I think it's because you can enable and disable groups during gameplay. So the group is essentially an IF condition, for example, IF Fantasma = true (enabled), then run the code inside the Fantasma group. Why would you want to take that away?

Nice work finding the cause and fixing it. Please still report it so they remember to fix the bug :)

So you got me curious and I did some testing today - and yeh - effects (HSL, B&W, probably others) seem to have a huge overhead on 9-Patches compared to sprites. Sprites I hit the CPU limit with lots of juice left in the GPU, but 9-Patches maxed out my GPU much sooner. I'm not sure why - every time I thought I had a theory, my testing didn't back it, so I'm afraid I'm no closer to unravelling the mysteries of the effects compositor for you.

I should mention this is Construct 3. I don't know if you see the same in Construct 2, so it might be worth checking? If you create a layout with 20 sprites with an effect, and another layout with 20 9-Patches with same effect, do you see a big difference in GPU% when running the layouts? (BTW you have to force a screen redraw - so give the sprites and 9-Patches sine behavior or something to make them move)

To answer your other question, when you can't test on a phone, a computer with integrated graphics will perform more similarly to a phone, they tend to have the same problems with fill rate, overdraw etc. Testing GPU% is tricky too, it can look really high when you first add a lot of objects/effects/etc., but leave it running for 5 minutes and it can drop significantly. I think when the GPU gets lots of new work it 'panics' and draws a lot of power to make sure the framerate doesn't drop, then it gradually winds down it's power until it is just maintaining the desired framerate.

Finally a word of caution about the RAM, yes there's more of it, but there's probably more background applications fighting over it, whereas the GPU should be almost fully dedicated to the game. Test on a phone while developing if you can - I tend to do a build when I'm heading to bed and test it in the morning - because performance can be very different.

Is that first one "collision cells"? If so then it may not be checked in all circumstances.

Yes I believe so, having read through how they work, collision cells is more user friendly name for spatial hashing, with some added optimization for handling moving vs non-moving objects.

Thanks for the correction and the information R0J0hound. I jumped in too early with some bad assumptions :) Didn't know we could look at the engine code in that much detail...

why not hide 9-patch objects from the "Paste Object" list?

Sorry but I have to disagree with this. Your use case is very specific. The issue only applies to 9-patch objects and effects applied and with a canvas offset from the viewport. And you are only doing it because you don't want to apply the effects each frame to eek out extra performance in a project where most game objects are 9-patch. You would want to disable 9-patch object pasting entirely because of that, when it still works for the other 99% of use cases that other people have?

I haven't seen your project or any screenshots, so I can only guess that it is a GUI heavy project? Have you benchmarked the difference with just applying the effects? Because the effects you mention in your issue, black and white, HSL - they are the lightest effects for a GPU to run - the performance impact should be minimal.

Otherwise take the old school approach we used before shaders (effects) - pre-render the black and white, faded versions etc., and swap the object or just switch their visibility on/off.

Sorry event sheet was supposed to be attached:

Sorry my other reply was probably long and confusing.

You could use the IID as the number for the Tile parameter. The problem is you have too many Tilemaps (128) compared to how many tiles are in your image (64). So you can reduce the number of Tilemaps to 64 and it should work.

If you need 128 Tilemap objects, then you can scale the IID (divide by 2), so IID will fit the same range of how many tiles you have. See below for what I mean (note: I made some other changes to make it more optimized):