log every n-th render stat

It's unclear what this means exactly. But note that for render farms, we need full logs, you can't skip printing part of the stats. We should not change the format unless there is a major improvement, since this will break scripts that parse this output.

On a more general note, there is a distinction between log messages that are interesting to users and to developers.

For messages for users, we should not print anything like source file location or line numbers, and any important warnings or errors should be printed by default without the user having to enable logging.

In D8691#211900, @Brecht Van Lommel (brecht) wrote:

On a more general note, there is a distinction between log messages that are interesting to users and to developers.

Oh, I assumed all logs are mean for developers and reports are meant for users. But it will be easy to implement as log records can hold flags (which then can be filtered)

Oh, I assumed all logs are mean for developers and reports are meant for users. But it will be easy to implement as log records can hold flags (which then can be filtered)

I think it is correct that so far logs were meant for developers only. Which is why I don't understand why render stats and errors were changed to use the logging system. I only checked the render module, there may be messages in other modules that are also meant for (technical) users.

In any case, it is not up to the logging system to decide which subset of render stats to show. There could be verbosity levels in render stats and we could default to less verbose stats by default, but using every Nth stats is not a solution I would accept.

I don't have a strong opinion if the logging system or reports system should be extended. But the distinction needs to be there in the API, and user and developer messages need to be handled differently.

Besides users vs. developer, it's also important for most user messages can happen within a specific context. Operator reports are associated with a particular operator execution, render stats should be associated with a specific render, depsgraph stats should be associated with a specific scene and view layer. With multithreading multiple tasks can be executed at the same time, and we don't want such messages to be mixed. The reports systems can handle this since it explicitly passes on a ReportList, instead of using globals.