The main difference with v4, that the v5 use a new system for render the elements.
It’s called “batch renderer”. This should improve the performance.
And it’s also a good thing for the shaders, the system behind is simplier.
You can check the migration guide on the pixi’s github and the post on their blog about v5 for learn more 
Well, I have something very good to say:
Due to a design error, the game I’m developing was creating (and simultaneously killing) multiple instances of a particle emitter in each iteration of the events (even in many nested loops). This caused the game to freeze for one second every 30 to 40 seconds. I later fixed this bug by redesigning my events and changing some effects to a single instance of the particle emitter, but …
I tried the bugged version of my project (the one with the multiple particle emitters… I kept track of old versions of my projects, just in case) on the beta version of GDevelop with Pixi v5 and, surprisingly, it works very well, there is no lag of any kind.
I’m on a Windows 10, Core i5 2.6GHz, 16Gb RAM laptop.
1 Like
nothing wrong for my project with pixi v5 
Outline layer effect not being applied correctly with pixi 5 version.
Below is the sprite on a layer with outline effect on beta 93 pixi 4 (2 pixels wide, white)
And here is how it displays on the beta 93 pixi 5 branch.
2 Likes
Maybe another thing to check for the pixi V5
Tiled sprite is broken over time. See the video on the post:
Can you share the image of sprite with me? It’s very helpful to find the problem.
@ddabrahim
@Bouh
.
Alright so here is my test results with this one (I tested Miko Adventures: Puffball):-
.
1- In general there is no difference about how the images look or rendered.
2- Program crashed 1 time when opening the preview.
3- I see no difference in performance … might be just slightly better (like less than 5%) … but I’m not really sure about that as it just feels the same.
.
After testing … I don’t know how I feel about Pixi 5.0 really but it might be better in other stuff and elements in GD but might not be for performance or handling big stuff (I can’t see really see that) which is kinda disappointing to be honest, or maybe this release is just not ready enough which makes sense.
I Hope that day come where I can see GD actually able to handle big and heavy stuff…
1 Like
Apologies for the delay, this is the sprite.
1 Like
I have a feeling that “other staff” is fancy visual effects and shaders but when it comes to rendering sprites and text it is not so fast. In my tests GDevelop performed 2 times slower compared to some other engines and frameworks and 10 times slower compared to the framework I am developing for my own use, mind you it is pretty basic at this point but fast 
In my tests I was moving sprites around, change their position, opacity, rotation, color, scale, was doing mostly rendering staff only no complicated gameplay, visual effects or collision and physics was used and no audio was played.
Of course in my tests GD was far from being the worse and rendering 5,000+ sprites is more than enough for most cases, so it is not too bad but also not great I was actually surprised to see that how much faster some other engines and frameworks were in my tests.
It could be interesting to debug this and see where this relatively low performance coming from in GD, is it just how “slow” Pixi is or is it something in the rendering and update cycle of GD or maybe the compiler split out dirty un-optimised code or maybe it is all combined.
1 Like
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.
1 Like
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 
1 Like
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 
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
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)
1 Like
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.
1 Like
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.
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.