Possibility to control / tame logging output #169
Comments
|
Here's what you can do today: When building in release mode, tracing is initialized to only show errors levels or higher. If you install your own With all that being said, I too feel the current debug-build output is rather egregious, so I don't want to consider this resolved even though you can change its behavior today. I've also been daydreaming of changing the subscriber to being able to route logs into a Cushy's window to show the log output. Your suggestions and feedback are greatly appreciated! I also wanted to justify why Cushy initializes logs out of the box: I'm trying to make Cushy an easy-to-use, all-inclusive application framework and logging is used inside of Cushy itself to report errors and warnings. Hiding this information from users who don't know how to configure logging seems like a very wrong approach. Since tracing_subscriber allows the first-initializer-to-win style setup, this seemed like a harmless thing to do out of the box since if wgpu fails to initialize, without logs there may not be any clue as to what is going on. |
Thanks for the hint! That works pretty well already. Currently I'm just doing something like this: tracing_subscriber::fmt()
.with_env_filter(
EnvFilter::from_default_env()
.add_directive("info".parse().unwrap())
.add_directive("winit=warn".parse().unwrap())
.add_directive("naga=warn".parse().unwrap())
.add_directive("wgpu=error".parse().unwrap()),
)
.init();I also tried the idea of setting it to "error" only during the initialization, and changing it back to "warn" afterwards, but couldn't really get it to work. Perhaps related to an issue in
I really like this "batteries included" philosophy of cushy! |
|
I've added filtering to errors by default for all three of those crates. I still have more I want to do with logging eventually, but the current behavior is now documented on Thank you again for the feedback! |
One of my use cases of using cushy is a kind of hybrid between terminal and GUI usage, e.g. running a cushy app from a Python REPL for data visualization purposes. Currently such use cases don't work so well, because there is a lot of logging output from winit / wgpu when running a cushy app:
Example log output of using cushy app for ~1 second
(The waiting for submission index messages occur during re-rendering, the rest is application startup.)
It would be great if it was possible to run a cushy app with basically zero output to stdout/stderr (of course unless the app really crashes) to avoid messing up the console output.
Typically the logging is setup not within libraries, but rather the
mainside, which I guess is either cushy or winit in this case, because my ownmaincontains no logging setup whatsoever. Would it make sense to allow for controlling the logging setup from the client side, i.e., pass through logging setup information from the client to wherever the logging currently gets configuered?Unfortuantely wgpu seems to make liberal use of
WARNmessages. From what I've seen so far, getting warnings during awinitstartup seems to be the norm even though nothing actually harmful happens. This would mean that one has to set a log level ofERRORto actually silence the output, which is a bit of a pity. So perhaps it would even make sense to explicitly control the log level during the winit startup phase (setting it toERRORtemporarily), and revert it back toWARNafterwards? Not sure if something like that would be feasible.The text was updated successfully, but these errors were encountered: