Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Log text via puffin #171

Open
emilk opened this issue Dec 1, 2023 · 1 comment
Open

Log text via puffin #171

emilk opened this issue Dec 1, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@emilk
Copy link
Collaborator

emilk commented Dec 1, 2023

I sometimes get .puffin files from users and wished it contained more information. One of the major questions I often have is "was this recorded on a debug build?".

A great solution for this would be to add support for logging text in puffin. puffin could by default log cfg!(debug_assertions) and rust compiler version, for instance, and puffin users could log their application version, build flags, etc.

The viewer should show these log messages in its own window.

Implementation-wise, I think it makes sense to log these as events, which like scopes contains file:line and function name and a start_time, but no end-time, because it is an instantaneous thing.

In the future we could also support showing such events in the flamegraph, so that one can log custom strings that give more context for a function call for instance, similar to the current "dynamic data".

Example

puffin::log!("Debug build: {}", cfg!(debug_assertions));
@repi
Copy link
Contributor

repi commented Dec 1, 2023

@NiklasNummelin and I have been talking about adding metrics events to the puffin stream also to for example be able to see how many objects in the world are active or triangles drawn on the GPU for a certain frame, or other frameless data but that affects performance & the state.would ofc need some design and fleshing out more.

but think that could be a good fit with log events also which would be essentially just marker events with strings attached to them, while metrics are named values/counters.

biggest difference may be this:

The viewer should show these log messages in its own window.

vs associating log events per frame (which you also talked about), so could do both? definitely useful to have log events as you mentioned that are for the startup and more context, though that could be not an event just extra context when starting so doesn't necessarily have to be part of the frame stream.

while the metrics and potentially some other log events could be useful to have on the frame timelines?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants