Like the developer hud in gaia, we should have some options to expose graphics performance issues so that developers can have some sense of how well their apps are doing at the graphics level. Some proposals: 1) Rendering times / Painting Times 2) Long Layout Flushes 3) Some way to highlight things that take a long time to paint Add bugs as needed

Resetting priorities because these P* levels are very out of date. Sorry for the bug spam. Filter on Lobster Thermidor

Bug 975675 introduces a number of widgets that live in the developer toolbar and provide performance-related data, like memory consumption, reflows and jank. All these are realtime-updating graphs, but we could imagine all sorts of widgets that could share that space. Is that something that would work for you?

(In reply to Panos Astithas [:past] from comment #2) > Bug 975675 introduces a number of widgets that live in the developer toolbar > and provide performance-related data, like memory consumption, reflows and > jank. All these are realtime-updating graphs, but we could imagine all sorts > of widgets that could share that space. Is that something that would work > for you? For #gfx we would just need a console that filters are some performance warnings, no widgets. If we have an API to log these from c++ that would be great. However it's not always possible to get a page context in graphics land.

filters out*

I think something like dev tools widgets would be better than just warnings. At least personally, a running always live metric is better than a warning because we'd constantly have to tweak the warnings as we change what is valid / invalid.

(In reply to Benoit Girard (:BenWa) from comment #3) > (In reply to Panos Astithas [:past] from comment #2) > > Bug 975675 introduces a number of widgets that live in the developer toolbar > > and provide performance-related data, like memory consumption, reflows and > > jank. All these are realtime-updating graphs, but we could imagine all sorts > > of widgets that could share that space. Is that something that would work > > for you? > > For #gfx we would just need a console that filters are some performance > warnings, no widgets. If we have an API to log these from c++ that would be > great. However it's not always possible to get a page context in graphics > land. if you can get to Cu.reportError or one of its friends, those'll show up in the console. (In reply to Mason Chang [:mchang] from comment #5) > I think something like dev tools widgets would be better than just warnings. > At least personally, a running always live metric is better than a warning > because we'd constantly have to tweak the warnings as we change what is > valid / invalid. Really depends on the use cases. The #gfx teams have different needs. That said, we are definitely planning on working on some things to expose graphics slowdowns via widgets and our performance tab very soon. See the bug Panos referenced for hints.

We probably want to add that to the gecko perf monitor.