diff options
author | Sergey Sharybin <sergey.vfx@gmail.com> | 2013-12-17 21:42:38 +0400 |
---|---|---|
committer | Sergey Sharybin <sergey.vfx@gmail.com> | 2013-12-17 21:42:38 +0400 |
commit | c5d7ea091fa5a291b270565e456612df1e37b50c (patch) | |
tree | 4322fffdf299ec35afe86030b49fdda9d0f38c8a /source/blender/editors/screen/glutil.c | |
parent | 04eb24a33737b9d9e29ec758c3db8fb81d140fc1 (diff) |
Changes to partial update during rendering
Summary:
Mainly addressed to solve old TODO with color managed fallback
to CPU mode when displaying render result during rendering.
That fallback was caused by the fact that partial image update
was always acquiring image buffer for composite output and was
only modifying display buffer directly.
This was a big issue for Cycles rendering which renders layers
one by one and wanted to display progress of each individual
layer. This lead to situations when display buffer was based on
what Cycles passes via RenderResult and didn't take layer/pass
from image editor header into account.
Now made it so image buffer which partial update is operating
with always corresponds to what is set in image editor header.
To make Cycles displaying progress of all the layers one by one
made it so image_rect_update switches image editor user to
newly rendering render layer. It happens only once when render
engine starts rendering next render layer, so should not be
annoying for navigation during rendering.
Additional change to render engines was done to make it so
they're able to merge composite output to final result
without marking tile as done. This is done via do_merge_result
argument to end_result() callback. This argument is optional
so should not break script compatibility.
Additional changes:
- Partial display update for Blender Internal now happens from
the same thread as tile rendering. This makes it so display
conversion (which could be pretty heavy actually) is done in
separate threads. Also gives better UI feedback when rendering
easy scene with small tiles.
- Avoid freeing/allocating byte buffer for render result
if it's owned by the image buffer. Only mark it as invalid
for color management.
Saves loads of buffer re-allocations in cases when having
several image editors opened with render result. This change
in conjunction with the rest of the patch gave around
50%-100% speedup of render time when displaying non-combined
pass during rendering on my laptop.
- Partial display buffer update was wrong for buffers with number
of channels different from 4.
- Remove unused window from RenderJob.
- Made image_buffer_rect_update static since it's only used
in single file.
Reviewers: brecht
Reviewed By: brecht
CC: dingto
Differential Revision: http://developer.blender.org/D98
Diffstat (limited to 'source/blender/editors/screen/glutil.c')
-rw-r--r-- | source/blender/editors/screen/glutil.c | 33 |
1 files changed, 0 insertions, 33 deletions
diff --git a/source/blender/editors/screen/glutil.c b/source/blender/editors/screen/glutil.c index af5f9d3c875..230c3a11108 100644 --- a/source/blender/editors/screen/glutil.c +++ b/source/blender/editors/screen/glutil.c @@ -1050,39 +1050,6 @@ void glaDrawImBuf_glsl(ImBuf *ibuf, float x, float y, int zoomfilter, /* If user decided not to use GLSL, fallback to glaDrawPixelsAuto */ force_fallback |= (U.image_draw_method != IMAGE_DRAW_METHOD_GLSL); - /* This is actually lots of crap, but currently not sure about - * more clear way to bypass partial buffer update crappyness - * while rendering. - * - * The thing is -- render engines are only updating byte and - * display buffers for active render result opened in image - * editor. This works fine to show render progress without - * switching render layers in image editor user, but this is - * completely useless for GLSL display, where we need to have - * original buffer which we could color manage. - * - * For the time of rendering, we'll stick back to slower CPU - * display buffer update. GLSL could be used as soon as some - * fixes (?) are done in render itself, so we'll always have - * image buffer with relevant float buffer opened while - * rendering. - * - * On the other hand, when using Cycles, stressing GPU with - * GLSL could backfire on a performance. - * - sergey - - */ - if (G.is_rendering) { - /* Try to detect whether we're drawing render result, - * other images could have both rect and rect_float - * but they'll be synchronized - */ - if (ibuf->rect_float && ibuf->rect && - ((ibuf->mall & IB_rectfloat) == 0)) - { - force_fallback = true; - } - } - /* Try to draw buffer using GLSL display transform */ if (force_fallback == false) { int ok; |