public interface IProfileSourceWhere a capture's samples come from.
No guide page documents this yet — the page shows what the code says about itself.
Remarks
⚠ Doc 20 is blunt that "the profiler must be able to profile the editor", and this interface is the whole of the mechanism. An editor that could only profile the game cannot answer why the editor is slow — and doc 00's editor-shell performance bar is a claim about the editor. So the panel never touches Profiler directly: it asks a source, and which source is a dropdown.
⚠ Collecting empties the rings, which is why a source is a thing and not a call. Profiler.Collect hands over the samples and clears them, so two readers of the same rings see half the frame each. One source per process-side ring, owned by the panel, is what keeps the second reader from being a bug nobody can reproduce.
Fields and properties (3)
string NameWhat the dropdown calls it — "Editor", "Game", the name of an attached device.
bool IsRecordingWhether this source is recording at all.
long DroppedSampleCountHow many samples went over the side before anybody collected them.
Methods (1)
ProfilerThreadSamples[] Collect()Takes whatever has been sampled since the last call, emptying the rings.
Used by (5)
- BufferedProfileSourceVixen.Editor.Profiler
- DiagnosticsPanelTestsVixen.Editor.App.Tests
- LocalProfileSourceVixen.Editor.Profiler
- ProfilerModelVixen.Editor.Profiler
- ProfilerViewVixen.Editor.Profiler