View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001599||NoesisGUI||Unity3D||public||2019-12-12 14:09||2019-12-20 17:40|
|Target Version||2.2.6||Fixed in Version||2.2.6|
|Summary||0001599: Unity Hard Loop/Lock on Visual Tree Update|
|Description||Updated: -- User Error, Please Ignore|
I don't know how to provide the telemetry you need for this one -- your guidance/help on getting you what you need is requested. I have a UI that causes Unity to hard lock (loop?) with high processor utilization. Breakpoints don't fire and I am forced to terminate Unity. A freeze occurs after the UI is initialized and a subsequent change is made. Sometimes the UI disappears, but most of the time it is a lock. The visual tree is as follows:
Grid (which forces a specific size based on user's preferred UI 'size')
UserControl w/ LayoutTransform & ScaleTransform
Grid (Focused 9-Slice Grid w/ Image)
Grid (Unfocused 9-Slice Grid w/ Image)
Grid (Over 9-Slice Grid w/ Image)
Grid (Down 9-Slice Grid w/ Image)
There are 75+ UserControl instances in that wrap panel. I found that if the focused grid had negative margin (so that it extends outside of its parent) I get a hard lock every time the scrollviewer hits 0.
Clearing the wrap panel can also cause a hard lock. This could be Unity, it could be me. I'm not aware of anything I am doing to cause a layout cycle, but hey, I've done incorrect things before.
What kind of information can I provide to help us diagnose if this is a Noesis thing?
Encl. screenshots of UI and unresponsive process.
|Tags||No tags attached.|
Skills.PNG (3,131,612 bytes)
Skills2.PNG (19,320 bytes)
Skills2.PNG (19,320 bytes)
I found the code that causes the hard lock. Commenting it out resolves the behavior. The UserControl cited above has this logic:
Button.MouseEnter += (sender2, e2) =>
_FocusedLayer.Visibility = Visibility.Visible;
_OverLayer.Visibility = Visibility.Visible;
Changing what is visible inside the button is most likely firing a layout event which in turn is firing a MouseEnter/MouseLeave event, and it loops indefinitely. I am going to try to resolve this with different logic. If you think this is actually a bug to investigate let me know, otherwise I'll reply back once I have my offending logic eliminated.
|Setting IsHitTestVisible to false for UIElements which change on MouseOver resolves the behavior. Seems very much like user error on my part. Please do feel free to close this unless you feel further investigation is warranted.|
I think this is in fact a bug in Noesis because we shouldn't freeze in an infinite loop no matter what layout and triggers you decide to use.
We should be able to detect those scenarios and break the layout loop.
|2019-12-12 14:09||stonstad||New Issue|
|2019-12-12 14:09||stonstad||File Added: Skills.PNG|
|2019-12-12 14:09||stonstad||File Added: Skills2.PNG|
|2019-12-12 14:23||stonstad||Note Added: 0006034|
|2019-12-12 14:33||stonstad||Note Added: 0006035|
|2019-12-12 14:33||stonstad||Summary||Unity Hard Loop/Lock on Visual Tree Update => Unity Hard Loop/Lock on Visual Tree Update -- User Error, Please Ignore|
|2019-12-12 14:33||stonstad||Description Updated||View Revisions|
|2019-12-16 12:46||sfernandez||Note Added: 0006036|
|2019-12-16 12:46||sfernandez||Assigned To||=> sfernandez|
|2019-12-16 12:46||sfernandez||Status||new => assigned|
|2019-12-16 12:46||sfernandez||Target Version||=> 2.2.6|
|2019-12-16 12:47||sfernandez||Relationship added||related to 0001600|
|2019-12-18 15:56||stonstad||Summary||Unity Hard Loop/Lock on Visual Tree Update -- User Error, Please Ignore => Unity Hard Loop/Lock on Visual Tree Update|
|2019-12-20 17:40||sfernandez||Status||assigned => resolved|
|2019-12-20 17:40||sfernandez||Resolution||open => fixed|
|2019-12-20 17:40||sfernandez||Fixed in Version||=> 2.2.6|