Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1.7.0 "stats & performance" demo on my local have much bigger stats value than office demo site #1001

Closed
lancety opened this issue Apr 27, 2021 · 9 comments

Comments

@lancety
Copy link

lancety commented Apr 27, 2021

I saw 1.7 release on top of this issues list, so I tried checkout my local branch to 1.7.0, but the 2nd "ut" time after "fps" is 6 - 7 times longer than the same demo on 1.7.0 official site (https://brm.io/matter-js/demo/#stats), I can see the lagging issue when my local demo page just refreshed (when the balls start falling down).

I tried reopen browser (chrome 90.0.4430.72), re-installed whole node_modules folder, could reproduce the issue.
Below screenshot is taken from same PC side by side, left is official demo site, right side is my local demo running "dev" npm task.

Is there anything from my local webpack dev server will affect it?
Thanks for help.

image

@lancety lancety changed the title just tried 1.7.0 "stats & performance" demo on my loca, the stats value have some diff, not sure iff i 1.7.0 "stats & performance" demo on my local have much bigger stats value than office demo site Apr 27, 2021
@liabru
Copy link
Owner

liabru commented May 1, 2021

Thanks for reporting, I actually noticed this too while I've been working on some performance improvements.

It turns out that the default devtool config in Webpack severely impacts performance in development builds.

Adding the line devtool: 'source-map' (or similar, but not an eval mode) to the Webpack config and restarting the dev server drastically improves this on my machine

For example stress3 example goes from 30ms per update to 6.5ms per update on my machine.

I'd recommend anybody using Webpack with Matter.js to make this change in their own config to get the correct performance in development builds, but also check your production builds too. It's now default on the development server in this project's own config too, but releases themselves should not have been affected.

Let me know if this resolves for you, I'll likely have to make note of this in the readme I think.

@lancety
Copy link
Author

lancety commented May 1, 2021

hi @liabru , adding dev-tool to the webpack.demo.config.ts fixed the issue. Thanks :)

Now just wondering if prod will be affected by this. I can see the demo webpack config is resolve"matter-js" from src folder. It will be helpful to let demo to use "build" min file so we know the build file doesnt have this issue.

@lancety lancety closed this as completed May 4, 2021
@Durss
Copy link

Durss commented Dec 21, 2021

Hello :)

I have terrible performances running matter-js on a Vue-JS 2 project.
If I profile the page without running matter-js everything's fine, the project actually does nothing, which suggest it's not source of these performances issues.

I added the devtool:'source-map' option and I went from 5-6fps to 11-12fps on the "Stress 2 demo" which is better but still quite bad :/ (the online demo works smoothly tho : https://brm.io/matter-js/demo/#stress2)
Is there anything else I could try ?

Have a good day :)

@Durss
Copy link

Durss commented Dec 21, 2021

Ok nevermind i found out the issue !

It seems to be due to Vue adding watchers !
I was storing a renderer's reference as a public prop of my class (using Typescript) which tells Vue that it should make the value reactive.

If I set it as private to remove the reactivity things run fine !

That may help others knowing this :)

@liabru
Copy link
Owner

liabru commented Feb 25, 2022

@Durss thanks for the update, that will probably help some Vue users I'm sure.

@KaliaJS
Copy link

KaliaJS commented Apr 13, 2022

If you use the Vue 3 you need to use the shallowRef() for the engine, runner, bodies, etc (everything that has heavy and deep modifications). It avoid deep reactivity.

@denzhe22
Copy link

Ok nevermind i found out the issue !

It seems to be due to Vue adding watchers ! I was storing a renderer's reference as a public prop of my class (using Typescript) which tells Vue that it should make the value reactive.

If I set it as private to remove the reactivity things run fine !

That may help others knowing this :)

Hi, Please, How do I set it as private to remove the reactivity things run fine ? I'm not quite sure what you mean

@Durss
Copy link

Durss commented Jun 29, 2024

Ok nevermind i found out the issue !

It seems to be due to Vue adding watchers ! I was storing a renderer's reference as a public prop of my class (using Typescript) which tells Vue that it should make the value reactive.

If I set it as private to remove the reactivity things run fine !

That may help others knowing this :)

Hi, Please, How do I set it as private to remove the reactivity things run fine ? I'm not quite sure what you mean

If you're on vue 3 with class decorators you'll need to declare every matterjs vars outside of the class as simple vars.

let engine = blabla;
class YourVueComponent {
 public mounted() {
...
}
}

With vue2 and class decorators just use private keyword private engine = blaba

@denzhe22
Copy link

denzhe22 commented Jun 29, 2024

Ok nevermind i found out the issue !
It seems to be due to Vue adding watchers ! I was storing a renderer's reference as a public prop of my class (using Typescript) which tells Vue that it should make the value reactive.
If I set it as private to remove the reactivity things run fine !
That may help others knowing this :)

Hi, Please, How do I set it as private to remove the reactivity things run fine ? I'm not quite sure what you mean

If you're on vue 3 with class decorators you'll need to declare every matterjs vars outside of the class as simple vars.

let engine = blabla;
class YourVueComponent {
 public mounted() {
...
}
}

With vue2 and class decorators just use private keyword private engine = blaba

Thank you very much for your reply.
But I'm sorry, I still don't understand, please forgive my ignorance.
Here's my code:

svelte1.svelte

`<script lang="ts">
let engine
let render
let runner
const initMatter: Action = (node) => {
$matterEngine = new MatterEngine (node);
engine = $plinkoEngine.engin
render = $plinkoEngine.render
runner = $plinkoEngine.runner
};
</script>

`

MatterEngine.ts
`class PlinkoEngine {
public engine: Matter.Engine;
public render: Matter.Render;
public runner: Matter.Runner;

constructor(canvas: HTMLCanvasElement) {
this.runner = Runner.create();
this.engine = Engine.create()
this.render = Render.create();

}
}`

That's what I understand, but it doesn't seem to solve my problem.
I'm using the svelte kit
Then I found that when I clicked my button, or played the sound, or played node.animation, the game would be very slow, but when I didn't do anything, Matter.js would be very normal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants
@liabru @Durss @denzhe22 @lancety @KaliaJS and others