3D View invalidate/redraw infinite loop on particular mouse locations #63439

New Issue

Ian Finnimore · 2019-04-09T22:48:20+02:00

Ian Finnimore commented

2019-04-09 22:48:20 +02:00

System Information
Operating system: Windows-10-10.0.17134 64 Bits
Graphics card: GeForce GTX 650/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 419.67

Blender Version
Broken: version: 2.80 (sub 53), branch: blender2.7, commit date: 2019-04-03 23:27, hash: 0e78e3038d
Worked: (optional)

Short description of error
When the mouse is in certain locations and not moving, the 3D View is constantly being invalidated and redrawing. Performance issue.

Exact steps for others to reproduce the error
Blend File Attached:
1 object (duplicated by array to 2.3m verts)
Video of effect attached. Note: only action performed during the video was movement of mouse, no clicking and no keyboard.

This is a subtle bug. It seems when the mouse cursor is in certain visual containers the 3D View is being constantly invalidated and redrawn.

Yes, I agree this is a crazy array object in the .Blend. The point is that it highlights something clearly that must be occurring regardless of complexity of object, but just isn't visible normally. While it didn't capture in the video (GPU was maxed out), this occurs regardless of current view detail (as was seen by monitoring GPU load).

MonolithFiberTest.blend

Blender_ [I__Blended_BurningMan_Monolith_MonolithFiberTest.blend] 09_04_2019 22_26_13.mp4

**System Information** Operating system: Windows-10-10.0.17134 64 Bits Graphics card: GeForce GTX 650/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 419.67 **Blender Version** Broken: version: 2.80 (sub 53), branch: blender2.7, commit date: 2019-04-03 23:27, hash: `0e78e3038d` Worked: (optional) **Short description of error** When the mouse is in certain locations and not moving, the 3D View is constantly being invalidated and redrawing. Performance issue. **Exact steps for others to reproduce the error** Blend File Attached: 1 object (duplicated by array to 2.3m verts) Video of effect attached. Note: only action performed during the video was movement of mouse, no clicking and no keyboard. This is a subtle bug. It seems when the mouse cursor is in certain visual containers the 3D View is being constantly invalidated and redrawn. Yes, I agree this is a crazy array object in the .Blend. The point is that it highlights something clearly that must be occurring regardless of complexity of object, but just isn't visible normally. While it didn't capture in the video (GPU was maxed out), this occurs regardless of current view detail (as was seen by monitoring GPU load). [MonolithFiberTest.blend](https://archive.blender.org/developer/F6923600/MonolithFiberTest.blend) [Blender_ [I__Blended_BurningMan_Monolith_MonolithFiberTest.blend] 09_04_2019 22_26_13.mp4](https://archive.blender.org/developer/F6923598/Blender___I__Blended_BurningMan_Monolith_MonolithFiberTest.blend__09_04_2019_22_26_13.mp4)

Ian Finnimore commented

2019-04-09 22:48:20 +02:00

Added subscriber: @IanFinn

Ian Finnimore commented

2019-04-09 23:03:30 +02:00

Just one other detail. I noted that closing and reloading this .blend file changed the behavior to redraw on mouse movement, so obviously there is some state var that can get mangled as well but clears up on reload. Video shows redraw on mouse hover, but now I am seeing it on mouse move in same regions.

Sebastian Parborg commented

2019-04-10 17:28:28 +02:00

Added subscribers: @fclem, @ZedDB

Clément Foucault was assigned by Sebastian Parborg

2019-04-10 17:28:28 +02:00

Sebastian Parborg commented

2019-04-10 17:28:28 +02:00

@fclem this is a duplicate of #62961, right?
The thing that is causing redraws in this case is the n-panel scrollbar (not the widgets).

@fclem this is a duplicate of #62961, right? The thing that is causing redraws in this case is the n-panel scrollbar (not the widgets).

Ian Finnimore commented

2019-04-11 13:23:15 +02:00

Clement, as you noted in #62961 (which I agree is a duplicate description of this from a different point of view) tagging the viewport for redraw seem to be the root symptom. The root cause questions to still resolve seem to be:

Why simple mouse movement over only some particular regions tag the viewport for redraw in the first place [In my example it was the render detail widget and the n-panel scroll bar.

Further experimentation shows that this is render engine independent, as Cycles exhibits the same GPU spike and visual effect.

Additionally, the experimentation seems to correlate this effect precisely with the n-panel and t-panel vertical scroll bars, specifically correlated to the scroll bar alpha value change relating to mouse horizontal distance. Perhaps it is this particular fade effect code that is invalidating the viewport, and is probably related to the panel transparency change implementation.

This effect is also correlated to tool tip pop up, and hide over the properties viewport even when the tooltip is wholly contained in the properties viewport.

I don't know the particular blender viewport engine code, but all systems I have coded in have separate methods (or at least parameters) for invalidate region, invalidate viewport, and invalidate all. Perhaps both the Tool Tip and scroll bar opacity are calling the wrong invalidate method? Or perhaps the event handler for the 3D viewport needs to check the parameter that indicates the dirty region needing redraw (if such a param exists), and at least do a "it's not my visible region" check to ignore effects that have no need for redraw.

This particular issue is a significant performance hit, especially the when triggered by the n-panel scroll bar fade in/out, as mouse movement around and across this happens a lot, and may account for several "sluggish performance" bug reports that have not been repeatable.

How and where, in this particular example case, does the viewport redraw tag get corrupted and therefore not cleared on redraw completion, as evidenced in the attached video showing continuous viewport redraw with a stationary mouse. Corruption is assumed, as restart of blender changed the behavior to be continuous redraw on move but no redraw on hover (probably in the same scrollbar fade code, some var corrupted causing the fade event handler to loop which makes no visual change on the scroll bar opacity).

Personally I would recommend disabling the scrollbar fade flourish globally (just keeping the scrollbar visible if scrolling is valid) until this redraw viewport side effect can be corrected. and even then consider parameterizing it with a default of "always show". When someone does look into the scrollbar fade mouse event handler code, I also note that the horizontal bar never fades to 0 when moving the mouse out of the viewport, unlike the vertical bar.

Since these scroll bars do not overlay any visual elements, hiding them does not bring anything more into view but just obscures to the user the fact that the viewport has more content to scroll to. Is that truly worth multiple redraws of the 3D viewport? In the case of tablet UX (where dragging the scroll bar thumb would be more common due to lack of a wheel on the pen), isn't hiding the scroll bar a wrong experience?

If the fade flourish is truly someone's pet "must have" feature I would question why specifically on the n-panel, as the fields extend to the right hand edge with controls, so much of the time the scroll bar is fading into view when the user is not even considering scrolling.

Clement, as you noted in #62961 (which I agree is a duplicate description of this from a different point of view) tagging the viewport for redraw seem to be the root symptom. The root cause questions to still resolve seem to be: 1) Why simple mouse movement over only some particular regions tag the viewport for redraw in the first place [In my example it was the render detail widget and the n-panel scroll bar. Further experimentation shows that this is render engine independent, as Cycles exhibits the same GPU spike and visual effect. Additionally, the experimentation seems to correlate this effect precisely with the n-panel and t-panel vertical scroll bars, specifically correlated to the scroll bar alpha value change relating to mouse horizontal distance. Perhaps it is this particular fade effect code that is invalidating the viewport, and is probably related to the panel transparency change implementation. This effect is also correlated to tool tip pop up, and hide over the properties viewport even when the tooltip is wholly contained in the properties viewport. I don't know the particular blender viewport engine code, but all systems I have coded in have separate methods (or at least parameters) for invalidate region, invalidate viewport, and invalidate all. Perhaps both the Tool Tip and scroll bar opacity are calling the wrong invalidate method? Or perhaps the event handler for the 3D viewport needs to check the parameter that indicates the dirty region needing redraw (if such a param exists), and at least do a "it's not my visible region" check to ignore effects that have no need for redraw. This particular issue is a significant performance hit, especially the when triggered by the n-panel scroll bar fade in/out, as mouse movement around and across this happens a lot, and may account for several "sluggish performance" bug reports that have not been repeatable. 2) How and where, in this particular example case, does the viewport redraw tag get corrupted and therefore not cleared on redraw completion, as evidenced in the attached video showing continuous viewport redraw with a stationary mouse. Corruption is assumed, as restart of blender changed the behavior to be continuous redraw on move but no redraw on hover (probably in the same scrollbar fade code, some var corrupted causing the fade event handler to loop which makes no visual change on the scroll bar opacity). --- Personally I would recommend disabling the scrollbar fade flourish globally (just keeping the scrollbar visible if scrolling is valid) until this redraw viewport side effect can be corrected. and even then consider parameterizing it with a default of "always show". When someone does look into the scrollbar fade mouse event handler code, I also note that the horizontal bar never fades to 0 when moving the mouse out of the viewport, unlike the vertical bar. Since these scroll bars do not overlay any visual elements, hiding them does not bring anything more into view but just obscures to the user the fact that the viewport has more content to scroll to. Is that truly worth multiple redraws of the 3D viewport? In the case of tablet UX (where dragging the scroll bar thumb would be more common due to lack of a wheel on the pen), isn't hiding the scroll bar a wrong experience? If the fade flourish is truly someone's pet "must have" feature I would question why specifically on the n-panel, as the fields extend to the right hand edge with controls, so much of the time the scroll bar is fading into view when the user is not even considering scrolling.

blender-admin commented

2019-04-16 01:22:40 +02:00

This issue was referenced by 9d06dc1496

This issue was referenced by 9d06dc14968318bb683c54399f965f045d493a0a

Brecht Van Lommel commented

2019-04-16 01:26:39 +02:00

Added subscriber: @brecht