Problem
I'm looking at the SetState stuff, and I see I can pass in a parameter to say it is thread safe. I'm assuming it's to avoid the locks for performance when not needed. I was wondering if it can be simplified a bit so you don't ever have to know upfront whether properties will update in the background or not, and just have a dirty flag that gets set, or detect the thread id is different and only then do the lock? You're already doing the thread id check in AssertUIThread, but that method throws a runtime-exception, so once you later decide to calculate a value on the background you don't have to deal with exceptions, and go iterate as much on declaring your state variables, but things will "just work" ?
Proposed solution
i think that's a good point. really the only reason not to always lock is if you think you will have enough state variables that locks will be a problem. having a lock per UIElement - bad, having a lock per state write and 1 time per render read... that could be pretty tolerable. i think it's a good issue. i have some stress tests I could use to vet if the lock would be a perf problem.
The thread id check is definitely needed, i already have reports of people hitting the silent failure when trying to do off thread access of state, so it feels like 1/ we need to be defensive, and 2/ this may be a good case of going for safety over raw performance
Alternatives considered
No response
Additional context
No response
Confirmation
Problem
I'm looking at the SetState stuff, and I see I can pass in a parameter to say it is thread safe. I'm assuming it's to avoid the locks for performance when not needed. I was wondering if it can be simplified a bit so you don't ever have to know upfront whether properties will update in the background or not, and just have a dirty flag that gets set, or detect the thread id is different and only then do the lock? You're already doing the thread id check in AssertUIThread, but that method throws a runtime-exception, so once you later decide to calculate a value on the background you don't have to deal with exceptions, and go iterate as much on declaring your state variables, but things will "just work" ?
Proposed solution
i think that's a good point. really the only reason not to always lock is if you think you will have enough state variables that locks will be a problem. having a lock per UIElement - bad, having a lock per state write and 1 time per render read... that could be pretty tolerable. i think it's a good issue. i have some stress tests I could use to vet if the lock would be a perf problem.
The thread id check is definitely needed, i already have reports of people hitting the silent failure when trying to do off thread access of state, so it feels like 1/ we need to be defensive, and 2/ this may be a good case of going for safety over raw performance
Alternatives considered
No response
Additional context
No response
Confirmation