Avoid graphical glitches during threaded preview generation #83896

New Issue

Julian Eisel · 2020-12-17T14:16:51+01:00

Julian Eisel commented

2020-12-17 14:16:51 +01:00

When previews are generated using an OpenGL engine, there can be a number of glitches until the preview is done. That's because some data is accessed/modified that is not thread safe. E.g. object_preview_render() modifies U.pixelsize. I think other glitches are caused by overriding the active theme in ED_view3d_draw_offscreen() - although when I avoided this some time ago for similar work on threaded offscreen drawing for VR, this didn't solve the color flickering.
The active theme should probably use thread local storage.

Besides that, the preview generation should be thread safe with OpenGL:

It uses the draw-manager's own context, which is mutex protected.
The non-thread-safe immediate mode API is not used inside the draw-manager.
The draw-manager already has workarounds for GPU driver issues with threaded drawing.

A note: We could also speed up Eevee preview generation significantly by using viewport render quality, not final render quality. The _imbuf offscreen rendering functions don't expose the is_image_render option for that, which they probably should.

When previews are generated using an OpenGL engine, there can be a number of glitches until the preview is done. That's because some data is accessed/modified that is not thread safe. E.g. `object_preview_render()` modifies `U.pixelsize`. I think other glitches are caused by overriding the active theme in `ED_view3d_draw_offscreen()` - although when I avoided this some time ago for similar work on threaded offscreen drawing for VR, this didn't solve the color flickering. The active theme should probably use thread local storage. Besides that, the preview generation should be thread safe with OpenGL: * It uses the draw-manager's own context, which is mutex protected. * The non-thread-safe immediate mode API is not used inside the draw-manager. * The draw-manager already has workarounds for GPU driver issues with threaded drawing. A note: We could also speed up Eevee preview generation significantly by using viewport render quality, not final render quality. The `_imbuf` offscreen rendering functions don't expose the `is_image_render` option for that, which they probably should.

Julian Eisel commented

2020-12-17 14:16:51 +01:00

Added subscriber: @JulianEisel

blender-admin commented

2020-12-17 14:16:51 +01:00

#96002 was marked as duplicate of this issue

blender-admin commented

2020-12-17 14:16:51 +01:00

#95057 was marked as duplicate of this issue

blender-admin commented

2020-12-17 14:16:51 +01:00

#85929 was marked as duplicate of this issue

blender-admin commented

2020-12-17 14:16:51 +01:00

#84062 was marked as duplicate of this issue

blender-admin commented

2020-12-17 14:16:51 +01:00

#83905 was marked as duplicate of this issue

Daniel Santana commented

2020-12-17 14:22:15 +01:00

Added subscriber: @dgsantana

Julian Eisel commented

2020-12-17 20:38:59 +01:00

Added subscriber: @TasosK

Georg K commented

2020-12-21 17:53:55 +01:00

Added subscriber: @georgK

Robert Guetzkow commented

2020-12-23 17:04:41 +01:00

Added subscribers: @gusdleon, @rboxman

Robert Guetzkow commented

2020-12-23 17:04:54 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Julian Eisel commented

2021-02-24 11:23:44 +01:00

Added subscriber: @Kdaf

Jason van Gumster commented

2021-04-23 14:13:04 +02:00

Added subscriber: @JasonvanGumster

Harley Acheson commented

2022-01-03 21:51:31 +01:00

Added subscriber: @Harley

Harley Acheson commented

2022-01-03 21:51:31 +01:00

Can't think of a reason for this to change U.pixelsize for the render. Maybe if the render included wireframes or showed cavity extras since those change with line size. And they would become less than a pixel when these previews are shown. But they don't.

I comment that part out and I can't tell a difference:

{F12787423,width=100%}

Can't think of a reason for this to change U.pixelsize for the render. Maybe if the render included wireframes or showed cavity extras since those change with line size. And they would become less than a pixel when these previews are shown. *But they don't*. I comment that part out and I can't tell a difference: {[F12787423](https://archive.blender.org/developer/F12787423/PixelSizePreview.png),width=100%}

Richard Antalik commented

2022-01-19 18:56:32 +01:00

Added subscribers: @LalaGhost, @RedMser

Harley Acheson commented

2022-01-19 19:28:59 +01:00

The primary issue stated here, the modification of u.pixelsize within object_preview_render, was fixed in the following:

https://developer.blender.org/D13717

The primary issue stated here, the modification of u.pixelsize within object_preview_render, was fixed in the following: https://developer.blender.org/D13717

Julian Eisel commented

2022-02-23 19:47:51 +01:00

Setting this to normal priority now. There are still notable glitches while generating the previews, but it's mostly things like buttons using wrong colors for a frame. Something that should be fixed, but nothing critical.

Pratik Borhade commented

2022-02-24 06:47:49 +01:00

Added subscribers: @ArmandoTello, @PratikPB2123, @Alaska

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Avoid graphical glitches during threaded preview generation #83896