Clean up root

[Pessimistress]

No description provided.

[coveralls]

Coverage decreased (-0.03%) to 46.191% when pulling b748e10 on eslint-module into 0859f92 on master.

[ibgreen]

The JSON WebGL API description files were intended for seer integration, since that is no longer something we are working on I'm OK with them being removed.

[ibgreen]

Nit: I assume we not planning to publish this module? If we did it would either be part of probe or ocular? In that case I am not sure dev-modules is the right place.

Although I guess we could name it something like @probe.gl/eslint so that we publish it on npm under the right name now, then we can move the source later?

[tsherif]

@ibgreen

The JSON WebGL API description files were intended for seer integration, since that is no longer something we are working on I'm OK with them being removed.

If that's the case, can we remove the timers from Model and BaseModel? I'm concerned that if used they'll interfere with the frame timers.

[ibgreen]

If that's the case, can we remove the timers from Model and BaseModel? I'm concerned that if used they'll interfere with the frame timers.

Well, Seer integration should still be working, it is not a feature we have so far discussed discontinuing. I was mainly commenting on the fact that certain in-progress development of seer stopped when the original author moved on, so no reason to keep in-progress work alive in the source tree.

I have found it useful to see individual results directly in seer for each model, it provides a lot more information than a frame number when multiple things are being rendered. It has seemed to work in the past, but perhaps there are limitations, and then we'll have to understand whether fixing those is worth the cost.

that if used they'll interfere with the frame timers.

When are they currently used? Are they only activated when the seer Chrome extension is opened? If that is the case we can do some testing and check how it looks?

---

About Seer: One of the potential integration points I have envisioned is to have an automatic seer integration with the stats objects you have been working on, such that we don't need to inject stats widgets into every app to instrument it, instead just open Chrome dev tools and get the data right there!

[ibgreen]

To add to previous comment: Ideally all performance collection should go through a single system (stats object).

so just like the existing resource counter setup was an integration target, this per-model measurement should ideally also go through the luma stats object, and seer should read it from there.

That should at least ensure that we don't have competing systems doing the same thing, but a single design where we can more easily evaluate what is possible/practical.