Consider providing log output sink in Application::Configuration alongside quiet/verbose flags

[Bill2462]

Hello,

I'm using Magnum version 2020.06-1 and every time I run my program I'm getting debug information in the console.

Platform: can't get Xft.dpi property for virtual DPI scaling, falling back to physical DPI
Renderer: Mesa Intel(R) UHD Graphics 630 (CFL GT2) by Intel
OpenGL version: 4.6 (Core Profile) Mesa 20.3.4
Using optional features:
    GL_ARB_ES2_compatibility
[more logs below]

I'm using custom logging library and I would like to either silence the output from Magnum or redirect it to a custom sink.
Is there an easy way to do this?

[mosra]

Hi!

This info is printed there by default because it proved to be essential when debugging driver issues. Nevertheless, if you want to silence/redirect it, there's two options:

• the output is printed by the Debug utility, which supports scoped redirect to a std::ostream -- but because the context gets created (and the info gets printed) in the constructor, it means you need create the application using the NoCreate tag and then do a deferred creation of the GL context using create(), which you then wrap in the scoped redirect
• another way is to use latest Magnum master instead of 2020.06 and silence the output using Flag::QuietLog set in application's GLConfiguration. In other words, pass GLConfiguration{}.addFlags(GLConfiguration::Flag::QuietLog) to the Application constructor.

One item on my TODO list is support for custom sinks in the Debug output, currently it's just a std::ostream and that API is just bad. No ETA on when that will be implemented tough, there's a lot of other things that currently have more priority.

[Bill2462]

Thank you for your quick answer!
I will probably go with second option and compile master branch from sources.

Yes the current API for debugging is quite bad. I think a good way to handle this would be to add an option to pass a custom debug sink to the constructor of the Application. Maybe I will try to add this feature and make a pull request if I will find some free time.

[mosra]

I think a good way to handle this would be to add an option to pass a custom debug sink to the constructor of the Application.

Assuming the reliance on std::ostream gets removed at some point (which it will), what would this offer over the scoped redirect I mentioned above? A sink usually needs some additional state, there's extra complexity regarding threads (should all use the same sink? should there be per-thread output?) and the Application base class would then need to take care of all this as well. Not to mention it's quite common to use Magnum together with Qt or other toolkits, without the Application wrapper, and the scoped redirect provides a common API for both use cases, with the Application or without.

[Bill2462]

", what would this offer over the scoped redirect I mentioned above?"

It would allow for setting the custom debug sink without the need for using NoCreate tag and then creating GL context using create().

However I was thinking about it some more and now I think that there aren't any benefits of using this over what you proposed.
Implementing deferred creation of the GL context turned out to be a very simple task and getting scope redirect to work without NoCreate tag would require a lot of extra work.

Sorry for asking the beginners question here in issues. I didn't notice glitter chat link in readme.
Anyway, thank you for quick answer to my question. Keep up the great work that your are doing here!

[mosra]

Sorry for asking the beginners question here in issues.

No problem at all :) What you self-labeled as a "beginner" question was to me a fresh view on a common pain point, and that's very valuable -- after working with the same APIs all these years, my mind is so rigid that it never occured to me that the output redirection could be done this way, in a constructor. (The recent addition of GLConfiguration::Flag::QuietLog was "born" in a similar way, I needed to hear "what the hell, man" a few times to realize it's essential missing functionality.)

I'm not discarding your idea, just need to evaluate the pros and cons first. Depending on how the replacement for std::ostream will look like, this could be doable, and one argument for doing it this way is usage simplicity. Keeping this open until I come to a final decision.