Conversation
|
Note: It makes the info command much slower, 2-3 times, unfortunately. But leaving the rendering engines open isn't really an alternative. |
|
I'm running this currently in pilot-idr0093. It takes ages, and needs to be followed by another run of |
I don't think starting a rendering engine to get the rendering setting info is the way to go when the settings exist. |
|
Could improve the RenderObject in another PR, add an option to load the settings without opening a rendering engine. But at least for now the PR makes sure the open rendering engine is closed again. Having the option to start a rendering engine is necessary too, in order to create rendering settings if there aren't any (I assume that's what it actually does). |
|
When you don't have settings: yes, but when they exist it is not needed. |
|
|
|
Sure. I'll also try to fix the RenderObject in this PR, so that it doesn't unnecessarily open a rendering engine. |
6e66751 to
c79e6ad
Compare
|
I removed the last commit again. A separate |
joshmoore
left a comment
There was a problem hiding this comment.
LGTM. I can imagine that something like the "--keep-going" flag that we have elsewhere (import.py) could be used to determine a throw or a ctx.err.
The
infocommand creates aRenderObjectwhich loads a RenderingEngine but doesn't close it. When you run it on a large Plate you soon hit an OutOfMemory exception. This PR closes the RenderingEngine again.The PR also adds athumbcommand which generates rendering settings (if there aren't any yet) and creates the thumbnails. Without it one has to run firstrender infoand thentest --thumb.