Thanks for your response, greven.
Not having any gauge in Xcode is an issue for me. Right now it shows a blank FPS gauge with 0 FPS and a greyed out "Analyze" button when running on a device in Metal mode, as you know. At the very least we can agree that it's not intuitive to display this, not displaying anything would be better.
When debugging on device it's particularly useful to be able to see a timeline of your FPS drops and not just a realtime counter on device. Even though the gauge in Xcode is basic, it filled a great need for me when trying to understand what caused drops. Clicking on the gauge used to also give you a GPU usage% which was useful for shaders.
Using Instruments can be sort of a workaround but it's not realtime, which doesn't help. The "GPU Driver" instrument will give you a once per second updated frame count which would be nice if realtime. The "Metal Application" is useless for me, considering how I don't know how spritekit works internally, it's one step too removed to be useful.
So a specific SpriteKit instrument, why not, but bringing back the gauge should be top priority in my opinion.
Anyway, as per your request, submitted bug report 23703643.
Edit : Since you asked about what kind of metrics would be useful on top of what used to be, assuming this would be some sort of instrument tool, per frame info that could be useful :
- Classic stuff : FPS, node count, quad count (so like SKView properties but logged)
- Process/Rendering times : Actions evaluation, Simulates physics, Evaluates constrants, view rendering
- Even better would be some info about how things are rendered : some info about what was/wasn't rasterized ? some information on some internal states/optimizations ?
Those are some basic ideas of what could be useful. To give you a practical example of a current issue I'm tracking, it's pretty hard to track why SKEffectNode+shouldRasterize will stop using the rasterization optimisation when I run an action somewhere on the scene, even on some separate part of the node tree. Having better tools to understand where the CPU time is consumed and what makes the rendered take the decision to use raster/not raster and other various batching optimisations would be greatly helpful.
