Slight Performance Issues

I’ve been noticing a certain amount of jerkiness in the rendering of some of my projects. Sometimes it gets worse and the whole framerate drops as fbx models are added but other times after deleting and re-adding those same meshes or shuffling other things around it’s just a bit of a jolt one or twice a second. Sometimes removing certain materials helps but another time when it was at its worst I removed all the materials and still had trouble. Scripts made no difference.

This is the current project which is about the smoothest I’ve gotten it with these objects in place. Moving around side to side I notice a consistent frame skip. At the moment you probably need to be looking for it to notice. I wouldn’t be too bothered with its current performance and would have assumed it’s just what to expect from rendering in a web browser, except for the fact that it gets worse when some things are changed.

It runs about the same on an MSI laptop with NVIDIA GTX 1060 and an old Dell with integrated Intel graphics. Tested in Windows and Linux with the same results.

This was a previous state where it got extremely bad. I made a copy, deleted most of the remaining assets and rebuilt it to get the result above.

Hi @Jimage,

I’ve tried your ebp-vr-copy project and it’s quite smooth, didn’t notice any framerate drop. But if you experience the drop while adding new models in scene with a collision/rigidbody component, I would say that’s normal. The physics engine kicks in and creates a physical shape for the model which takes a while and can lead to missing frames.

Your older project I think it’s normal to struggle on some machines since you have a very high polycount (500-600K) and physics enabled for what I see in almost all of your models.

Also make sure to start using batching (batch groups assigned to your models) to lower the draw calls, this can help a lot with performance.

I just don’t see why the original would be struggling like that while the copy with all the more complex objects deleted and then added back in runs smoothly. I’ve hacked up the original again so there are now only a few simple objects with most of the physics elements removed but it has made no difference this time. Not sure what it was I removed to get it back to normal in the copy but I don’t see that it would be a matter of polygon count on this basis.

The performance hit doesn’t just happen while running the project and adding it in the editor. It persists when reloaded. As far as older machines are concerned, the 2017 MSI laptop with NVIDIA GTX 1060 runs no better than the 2012 Dell Latitude with integrated Intel graphics.

Having had another project run up against a similar problem today, including a published version that I’m sure was running smoothly when I built it a few weeks ago, I tried running the problematic projects in Chrome instead of Firefox. In Linux Chromium and Windows Chrome on the MSI, and Linux Chromium on the Dell, they all work smoothly.

Firefox on the Dell is actually working a bit smoother than the MSI, but not as well as Chromium. However, I am also noticing that Chromium is running the graphics at a lower quality with no vsync resulting in a lot of tearing if the camera moves out of its existing viewing area (full quality on the MSI though). Not as noticeable when moving forwards and backwards.

On the MSI in both Windows and Linux it encounters the dramatic framerate drop on these particular projects. At the worst extreme it feels like there’s an after-image as though it’s blending a semitransparent copy of each frame over the previous. Despite this the camera movement kind of still feels smooth so it’s hard to put my finger on exactly what’s going on if it’s not just a matter of low framerate

Firefox and Chrome on my Galaxy S9 both run smoothly. Yet to try these in the Quest but both the built-in browser and Firefox Reality have run everything else perfectly so far.

As a further experiment I switched the MSI to Intel mode in Linux and tested Firefox and Chromium. Chromium was slightly less responsive but still very smooth, while Firefox maintains the same jerky rendering. However, I then came back and tried a second time in Chrome a while later to find similarly rough rendering, worse than the Dell but still with the higher quality graphics and no tearing. Perfect again after rebooting into NVIDIA mode. Poor performance in Firefox persists.

The editors don’t suffer a performance hit at all on any combination of OS and browser.

Tried setting Fill Mode to None, disabling antialisaing, and then unchecking Prefer WebGL 2.0. There’s probably a slight improvement under some of those combinations but the problem persists. Disabling physics collisions and entire batches of entities also makes no difference. I thought maybe there’s something in one of the scripts but I’m using the exact same ones in other projects that are all working fine.

So apart from Chromium in Intel mode struggling a bit on the MSI, the common factor here seems to be Firefox on PC. But it’s still weird that there are specific projects that do this while others run fine.

1 Like

I have just found a setting that consistently clears this problem on several projects I’ve tested it with.

Switching Resolution Mode from Auto to Fixed results in almost flawless performance in Firefox. The projects I’ve checked so far that were running fine were already set to Fixed so that appears to be the common variable.

I think it is still dropping a couple of extra frames every now and then which doesn’t happen in Chrome but it’s the best I’ve ever seen it running in Firefox. I’ll run a few more tests before marking this as solved though.

Edit: One project was still lagging and I’ve narrowed it down to some tree models. But they’re the same models as another project that’s working fine.

Edit: Tested it again on the Dell which works fine. It has Firefox 78 installed while the MSI has 79. Maybe there’s something in the new version that’s breaking things, which would explain why the previously published version is also running worse than I recall.

1 Like

I rebooted into Windows 10 and installed a portable copy of 78.1. Much smoother, though again still dropping a couple of frames unlike Chrome.

Interestingly, running it in Chrome and Firefox 78 at the same time results in the same juddering redraw as Firefox 79 in both browsers. However, running it in two tabs within Firefox 78 is perfectly fine.

Tried running the profiler. It triggers the same rendering problem in Firefox 78 and 79 while Chromium doesn’t suffer a noticeable performance hit.

It doesn’t seem to be a matter of framerate as that sits consistently at 40 (60 in Chromium). Though I don’t know how I would check what it is normally without the profiler.

It should be noted that this changes the pixel ratio. For example, it seems like the default resolution in project settings is 1280x720. If you set that to auto, it will adjust to whatever resolution your screen is, for me that’s 1920x1080. “Fixed” on the other hand will keep it at 1280x720, so it ends up rendering a lot less pixels. I think your best bet with that is to leave it on “Auto” and adjust “maxPixelRatio” instead which does the same thing.

I’ve also had issues on Firefox. I actually use Firefox for everything, except for previewing the scene. I use Chrome for that because every 3-8 hours of development Firefox will suddenly freeze up the whole system and force a hard reboot. I think Chrome runs into a similar issue; however, it handles it a lot better, the tab will just crash instead of locking up the whole system.

I believe that’s because Firefox will performance throttle the tab that isn’t active. All browsers do this to keep a WebGL-heavy or JS-heavy page from slowing down the browser when it’s not open. It would make sense having the same thing open in two browsers means neither tab is getting throttled.

Could be related to garbage collection, if you run a performance test in the dev tools. Every time the memory graph drops of a cliff, that’s garbage collection running. Out of control memory or a memory leak will result in garbage collection running too often. It’s probably not gc, but something you could always double-check.

This actually doesn’t run that bad on my end. But, taking a look at the loaded assets, seems like there’s a ton of assets that are loaded, but not used. I’m assuming this is because they were taken out at some point to improve performance?
Only two of those are in VRAM, if they’re not in VRAM, they’re probably not needed.
VRAM looks to be at 32 MB, which is very low and therefore definitely shouldn’t be an issue.

In relation to garbage collection mentioned above. It looks like gc is running about twice a second, as you can see by the drops on the blue line graph. That means you probably want to pay attention to what’s happening in update() functions, those shouldn’t be doing much work. Maybe JS objects are getting created there? Could be a lot of things, but that looks to be something to track down.

1 Like

Is that garbage collection activity unusual? Where do I find the graph? Even with only two basic scripts for movement and mouse look, it’s doing the same thing. Is there anything else that would be affecting garbage collection besides entity scripts?

I’m rebuilding one of the projects from scratch. I tried setting it back to Auto Resolution Mode after adding a few models and it’s lagging again. I then set it back to fixed and changed the resolution to 1920x1080 and it does the same thing, so perhaps it’s just not coping with that resolution somehow. I’ve been forking it before adding things and loaded a previous version with only a few Box models. Auto has a barely noticeable lag effect even there. It just seems to get worse with more complex models added.

I haven’t had any other trouble with Firefox and PlayCanvas so far, just this one thing. It still just seems to be this latest version more than anything to do with PlayCanvas itself. Are there any settings I should look into that might be affecting WebGL performance or anything else PlayCanvas may be relying on?

I don’t see maxPixelRatio anywhere. Is that meant to be set in a script?

Edit: Added a script to root that sets pc.Application.getApplication().graphicsDevice.maxPixelRatio. Not sure which way the values are meant to work but I tried 0.5, 1 and 2 while set to Auto Resolution Mode and it made no difference.

That garbage collection isn’t necessarily unusual. I think it depends on how much data your using/getting garbage collected. So, it could be related to the frame skip, but I’m not convinced that’s the reason. It doesn’t seem like Firefox has it, so you would have to use the performance tab from Chrome. Garbage collection is related to literally any JS object that is no longer used by your page, if you create a large JS object on update() that can be an issue, but otherwise it’s probably not an issue.

If you think an update to the PlayCanvas engine is the issue, something you can try is export the project and switch out the engine script for an older engine script from PlayCanvas’ GitHub.

That’s weird maxPixelRatio isn’t working for you. You don’t have “Device Pixel Ratio” checked in the project settings right? Not sure why it wouldn’t make a difference. When I use it on my project, just 0.7 and 1.0 already make a 15 FPS difference. Also, visually much blurrier at 0.7. Maybe VR does something different, I’m testing without any VR equipment.

Fixed a typo and it worked. 0.7 was a bit better at Auto resolution. Fixed still looks better and runs smoother so I’ll stick with that instead.

I still don’t think it’s PlayCanvas since it’s fine on everything else I’ve tried. Haven’t tested VR recently but it was as good as Chrome last I checked a few weeks ago so I doubt that’s changed.

Installed Firefox 78 in Linux on the MSI as well and it’s back to the performance I was used to. Still has that minor frame skip, but it’s always done that and it’s not too drastic so I can deal with that. I’ll see if I can clear it up somehow another time and see if older versions of the engine make any difference, but for now at least I know the problem isn’t with my projects and the Fixed resolution workaround is available if others encounter the issue with Firefox 79.

These videos demonstrate what I’m seeing in Firefox 79.

The first is the major difference between Auto and Fixed. Other projects are performing worse than that on Auto.

The second shows the frame skip. It’s subtle and a bit harder to spot when the video is scaled down in this post. Most users probably won’t notice it, but it’s something that only happens in Firefox on PC.

Personally, I’ve just come to accept Firefox performance-wise won’t be at Chrome’s level. Kind of unfortunate. Maybe there is some way to fix that skip, but I wouldn’t know. I do notice it looks like there’s lighting in those scenes, maybe viewing that same scene with lighting disabled might help narrow down what the culprit could be?

@Jimage I’d be interested to see the mini-stats running while you run the tests. Is that possible? @yaustar might be able to explain his neat method of adding it to a scene.

Easiest way to do it (for the ministats at least) is to inject the JS file :slight_smile:

On the launch tab, paste the following code into the console and run it:

var imported = document.createElement('script');
imported.src = ""
imported.onload = function () {
    var ministats = new pc.MiniStats(pc.Application.getApplication());

I have more devtools here that you can also use:

Chromium Auto Resolution
Mini Stats Auto Resolution Chromium

Firefox 78
Auto Resolution
Mini Stats Auto Resolution Firefox 78
Fixed Resolution
Mini Stats Fixed Resolution Firefox 78

Firefox 79
Auto Resolution
Mini Stats Auto Resolution Firefox 79
Fixed Resolution
Mini Stats Fixed Resolution Firefox 79