Closed ideasman42 closed 5 years ago
@ideasman42 : Thanks Campbell. Is there any convention and/or list of already used values for bpy.app.debug_value? Or we can choose any wanted values?
I will manage it ASAP
Hey Julien, there is a log-level, see help for --log-level
, we could expose this via bpy.app.log_level
,
see https://developer.blender.org/diffusion/B/browse/master/intern/clog/CLG_log.h$55 for log level usage.
What do you think?
Hey Campbell, Yes, if this data can be exposed via bpy.app.log_level, it can be helpfull to use it instead of logging level from logging package.
But if is's not done yet in bpy, it's maybe because other addon developers don't find it usefull, so we can adapt this addon to fit other addon best practices.
Let's me know what is your preferences.
I just committed a first fix for loading modules. Using bpy.app.debug_value for now. We may find a better solution if log_level become expose to bpy
Note that we still have to refactor logging to use same way for import and export ( #89 )
Because the initial problem is now solved (lazy loading time), I propose to close this issue, and continue discussion on #89 when bpy.app.log_level will be available
Blender has a convention of lazy loading modules for faster startup times,
GLTF mostly follows this however importing GLTF logging pulls in many other modules, since GLTF is enabled by default, it should not be imposing a startup cost, even if its a small one since it impacts startup for automation, render farms, tests, etc.
This can be avoided by having the logging levels in the file, or even making this a developer only feature since very few users would be interested in this - you could use
bpy.app.debug_value
or some other method to set the levels.This is a list of modules loaded with times, using:
With the import removed:
from .io.com.gltf2_io_debug import Log
.Patch to test: