Three.js: The Joys of Performant Debugging (Optional logs / warnings)

[mjurczyk]

Description of the problem

Related to https://github.com/mrdoob/three.js/issues/7112, https://github.com/mrdoob/three.js/pull/5791, https://github.com/mrdoob/three.js/pull/19309 and a few more.

Is there any reason why we can't suppress warnings from Three? Adding Three.warn / Three.log seems like a 5 minute PR with kinda 0 deprecation issues and 100% happiness increase of any CPU 🤔 ..?

---

Short story long, I understand that deprecation warnings are there originally to help with debugging, and so are possibly any other warnings - but when Chrome tries to render (even hidden) 20k warnings right out of the door (it is a bit of a specific project case, as it generates a lot of materials on the go, but it still is a case.) the app and console freeze for 30 seconds.

Add hot reload plus Preserve Logs, it freezes until next calendar year :')

While none of the things mentioned in warnings are mandatory or breaking at this moment (fixing required vector targets can wait until the version release, and materials won't break on undefined in these specific cases.) the logs that the rest of the application spits out are important, very helpful for debugging, and also lost among 20k three.js warnings (hence this workaround isn't really an option.)

Three.js version

• [x] Latest

Browser

• [x] Chrome

OS

• [x] All of them

[mjurczyk]

(As before - I can do the PR, just would like to know if there's any reason behind not having it already :) )

[Mugen87]

Sorry, but this topic was discussed multiple times in the past and I see no reason why to start over again.

You can monkey-patch the behavior of console.warn on application level if you want it different.

[mjurczyk]

Yep, that's why I linked them and ask why we wouldn't do that, except for opinionated statements that "why would someone not want logs?"

Hacks like that don't work if app itself uses warns, and removing them by hand from three's source makes three un-upgradable - so something that's supposed to help does exactly the opposite.

Is there really any reason besides stubbornness?

[looeee]

A workaround if you are using build tooling and don't want to monkey patch built-ins is to strip out console log for your production build. For example, in Rollup there is @rollup/plugin-strip or for webpack you can use Terser.

[mrdoob]

and 100% happiness increase of any CPU 🤔

Are you saying console.warns() consume CPU? Have you measured it? If so, can you share the results?

[mrdoob]

Also, the screenshot you shared has nothing to do with deprecation warnings.
Seems like misusage of the API to me 🤔

[mjurczyk]

I'm not sure if closing an issue, again, without solving it is a good practice. Workarounds aren't a solution, and it will just appear again in the future.

@looeee Yes, I did work around it, but my point is why do we need a workaround in the first place, when a simple proxy for console solves the issue. There are other challenges in development to focus on, that's why I ask if there's any real reason besides stubbornness - I have no issue with logs, as long as they don't jam the browser when debugging.

@mrdoob

1. There are also warnings about vector targets, just somewhere above in this 20k records (ex. getHSL() after last update I did). If with new version some util gets a new warning that in the future it will require new prop, or something similar, it adds more.
2. I don't think it's a misusage - rather a misinterpreted value in Three. The workaround for it was to convert all undefined to null, since the warning is triggered exclusively by undefined values - the effect is the same as the value is just ignored later.
3. As for CPU / performance jamming via the console, you can open the dev console (can be in this tab, doesn't matter) and paste:
   const i = () => requestAnimationFrame(() => { Array(60).fill(1).forEach(_ => console.warn(_)); i() }); i();
   After a few seconds you should get ~5k records - which, even if hidden, start slowing down the console. By 20k it's not usable anymore.

Once again, I 100% do realise it's an edge case of generating stuff on the go, but why do we refuse to fix it?

[mrdoob]

1. I don't think it's a misusage - rather a misinterpreted value in Three. The workaround for it was to convert all undefined to null, since the warning is triggered exclusively by undefined values - the effect is the same as the value is just ignored later.

These properties accepted values are null or Color/Texture.undefined is not valid there thus it's a misusage of the API.

We try our best helping users with warning when they're passing invalid values wherever we can. The solution is to fix your code instead of asking the library maintainers to hide these warnings. The renderer can break if you don't provide the right values.

1. As for CPU / performance jamming via the console, you can open the dev console (can be in this tab, doesn't matter) and paste:
   const i = () => requestAnimationFrame(() => { Array(60).fill(1).forEach(_ => console.warn(_)); i() }); i();
   After a few seconds you should get ~5k records - which, even if hidden, start slowing down the console. By 20k it's not usable anymore.

You're talking about devtools performance. If you don't open devtools console.warn()s do not consume CPU.

[mjurczyk]

If you don't open devtools console.warn()s do not consume CPU.

Ok, sorry, I'm siding with @Mugen87 there's no point in continuing the discussion.