[Need tester] GDevelop 5 branch Pixi v5



Blockquote It could be interesting to debug this and see where this relatively low performance coming from in GD

I’d like to see that happen with the future updates because I can really feel that the engine can give more you know … but something is just stopping it from doing that.
I’ve been testing GD since beta 30 or even before that and yeah the engine have come a long way in features and so on … but not really in the performance aspect, it is the one thing that makes any game … a game …
Hope to see in the future (hopefully near future) more focus on performance … it will send this engine to another place.


Ok, I checked, and according to this article by the creator of pixi, the improvement are principally:

  • begin to support webgl2, Wich will make great improvement when polished/finished on the supported browsers
  • better loading of textures
  • enorm improvements on shape painters
  • improvement with shaders (effects)
  • batching, aka optimized communication with the GPU for faster rendering by putting every sprites and shape painter in an atlas internally

You tested only on sprites, no wonder you didn’t see any difference :wink:


Yes this is why I’m thinking it might be faster rendering visual effects and shaders.
In my tests, I was focusing on quantity and CorianderGames was trying to render high res images in his game with no success so if there is any performance improvement it must be focused on effects and shaders and not sprites indeed :+1:

But this is actually sounds something like that should also help with sprites:


From what I understood, webgl2 is WIP and should bring in the future real improvements, and only on supported browsers.


After doing some testing it looks like it could do with the boundaries of the layer for the outline effect.

Here is an image of all objects in the layer in a clump, there’s a visible boundary where the effect is not being applied.



When using 2 dummy objects to make the layer area larger, the effect is displayed correctly (except on the dummy objects). I have tested both v4 and v5, and v4 does not require this work-around.



Remember, the focus on this Pixi release is for now not really to improve performance - though it would be a nice side effect, because as explained by Arthuro555 there are a bunch of performance improvements that can make rendering with Pixi.js very fast.
Performance is a complex topic, it can be:

  • rendering performance
  • collision handling… and how much collision check you’re doing
  • how much objects you’re moving (needing to update their collision masks)
  • how much object are animated
  • how much conditions/variables check/etc you’re running on objects that are actually offscreen.

What could be useful is if you make a simple example that seems to under-perform - at this point we could look at if there is something that is clearly sub optiomal in the game engine. The game engine is itself not super complex.

Here we’re just testing that upgrading Pixi does not break your games :wink:

What I think would be useful, and it’s a point where GDevelop could be better, is to give you tools to understand why things are slow. The profiler is very basic. I’m thinking of adding better instrumentation of the games to warn when too much work is done (events using too much objects, collisions taking too much time, physics, too much rendering of objects, too much effects). Whatever the performance of the game engine is, you will always easily make it break if you’re not aware you’ve done something that is too resource intensive (I wonder how many games are creating tons of objects and never deleting them, or making stuff happen outside of the screen while it could be avoided)


Ah, I think you just mentioned the reason behind the low performance in my rendering tests. Yes, it was a rendering test, just to see how many objects I can put on the screen and move around, no collision was checked.
But even if I don’t check collision, the engine still continuously update the collision mask as the object move and rotate right?

If I don’t want to check collision with something, it is sounds like a total waste of resources to update collision mask position and rotoation especially if it a custom shape.

Would that be possible to stop updating? Would it be possible to add an option in the sprite object properties if we want to update collision mask or not, also an event to be able to toggle on and off.


I’ve wondered this myself. Would be interesting to see if such a method had much of an impact on performance.


When an object is moved (example for sprites), it should just toggle a boolean indicating that the “hitboxes” of the object are now “dirty” and do nothing else. Then, it’s only when a collision check is being made or when the hitboxes are used (for example, to know if an object is visible on screen) that the boolean is checked and that hitboxes are recalculated.

So this specific optimization should already be there - but:

  • such optimization can backfire if for example if you’re moving too much objects and recalculate too much hitboxes (at which point the boolean is not useful, and has a slight overhead) (though flipping a boolean is really really the cheapest thing you can do).
  • such optimization may be not enough if you have too much moving objects - in which case it would be useful to know from GDevelop if you’re making “too much” collision tests (but how much is too much?).


I see what you mean, but if you don’t check collision ever, it may be uses too much resources I mean, as I mentioned GD was 2-3 times slower in my tests than some other engines out there but now that I think about it, in the other engines I did not even have a collision mask so that must be part of the reason and I think worth investigating imo. Now, one might say that if all you do is move objects around the screen then you can use particles instead but the thing is, with using sprite objects you can still have animations, object variables and able to take control any individual object at any given time, with particles it is not so easy because as far as I know currently we don’t have control over individual particles but the particle emitter.

It is depends on the device and the shape of the collision mask (the number of polygons) I guess. I grabbed my cheap tablet and was able to check collision with 900 objects on screen while mainlining 30FPS. So if someone put a gun to my head and ask the question, I would say 100 considering the cheapest possible device people may own which is my tablet as of today and also that probably want to do other things in the game not just checking collision. So when there is more than 100 collision checks happen, you can put a warning in the console saying the number of collision checks may hit performance on slow devices. :+1:

But then people may don’t care or don’t even see the warning. I mean people don’t see the examples included, constantly every day asking how to do something that is already demonstrated in examples included, so do you really expect them to see a warning in the dev console? Maybe if GD would have a console built in to the IDE that can be hidden and display a giant red “!” sign if there was a warning during preview maybe.


Lol. Realized I can actually remove the hitbox by having a custom hitbox with 0 polygons.
It is improved the performance by 10 FPS and allowed me to put 1000 more objects on the screen while maintaining 30 FPS on my dev PC. But it is till way below the results of some other engines, wondering how much the calculation to update the hitbox cost even if I have an empty array of polygons. :thinking:

[SOLVED] Panel Sprite Bug on android

Updated version! :slight_smile: GDevelop 5.0 beta 97 with Pixi 5:

The BB Text issue should be resolved. In theory very few things should be changed - don’t expect mad performance gain or any gain at all. The idea is just to test the stability.
In particular let me know if an effect is not working anymore.


If I understand correctly, this is PixiJS 5.3.0, correct?

Any chance GD5 will get the implementation of BitmapText and automatic bitmapfont generation they added?

Edit: Forgot to mention I’ve downloaded and will try to run through the paces later today. :smiley:


Initial testing on BBText still seems to be broken at large sizes.

Scene Editor:


BBText setting:

Font: https://dacosta.itch.io/gothic-pixel-font

If I just enter a bunch of blank lines before the text, it works but you have to drag the huge object up.


BBtext issues still persist with pixi v5. Top is custom font, bottom is default font. Seems custom fonts react badly for some reason. I tested 3 different ttf fonts from different sources, all behaved the same.

Another thing to note, is that the BBtext font seems to change when left as it’s default setting of Arial when compared what is displayed in the scene editor and in the preview.

Edit: Added pictures of BBtext settings for each object.


Sorry for the confusion, when I said “BB Text issue” solved I was thinking of the one crashing the editor.

Before we go any further, is this issue of line height related to Pixi v5 or is it also appearing in GDevelop beta 97 (i.e: using Pixi v4)? I believe what you are reporting here is already an issue in the current version of GDevelop, reported here: https://github.com/4ian/GDevelop/issues/1521

I know it’s frustrating but I want to make sure we’re here only dealing with Pixi v5 regressions here, otherwise this will delay the adoption of Pixi v5 which is largely overdue already :slight_smile: In a way I want to verify that Pixi v5 is not “making things worse”.

I agree that this bug should be fixed though, but let’s talk about it on https://github.com/4ian/GDevelop/issues/1521

PixiJS 5.3.0, correct



Bug appears in pixi4 so yes you are right, wrong thread to bring this up, worry :sweat_smile:


To be clear I think I should take another look at this issue because it’s clearly a bad bug making BB Text almost unusable :slight_smile: Will try to see if I can do something.

Any chance GD5 will get the implementation of BitmapText and automatic bitmapfont generation they added?

I think that would make a great object/feature! :slight_smile: Should be more performant and could help with some pixel perfect rendering issues.
I’ve added a card here:


Thanks for the card, and agreed on the BBText issue. It definitely existed before v5.

closed #41