I extended my comment above a bit, to explain why I think this is the wrong level to add thread safety.

@Brecht Van Lommel (brecht) issue with bitflags in RNA is that from RNA side they look like different properties, but they actually affect the exact same value. So idea would be that default RNA setter would set those bitflags with atomic operations yes...

I'm not sure what it means to make the RNA access atomic, how would that be implemented, manually for each property? If so, there are many of them and taking that into account for every new property sounds fragile. I'm also not sure to what extent writing a char or short could conflict with an adjacent variable.

In T73593#875302, @Brecht Van Lommel (brecht) wrote:

After looking into this with @Sybren A. Stüvel (sybren), we think the random failures are most likely due to a threading issue

The random failures are most likely due to a threading issue, where two threads are evaluating the viewport and render visibility driver for the same object in parallel. These two properties are stored as bitflags on the same integer, so writing to them at the same time is not thread-safe.

Here is a fairly simplified file and video:

When the armature is not a proxy, the issue is still present, but the above warning is not.

Worked: Maybe a month or two ago?

@Eva (sweep2rails)

It's been pointed out to me this may be a duplicate of T56635, but that one was closed as resolved. Maybe this should be merged into that one, and that one be re-opened? I'm not 100% sure it's the same issue, but definitely seems very similar.

I can confirm the problem.

@Germano Cavalcante (mano-wii) please remember to add the - it worked in 2.79 information in the original bug description. A fully triaged report should have all the required information to fix it in said description.

I can confirm the bug.
It didn't happen in blender 2.79

In T58473#853911, @Alexander (aftamat4ik) wrote:

there are few suggetions for people that has this bug:
For example you have already made model with hires modifier and you want to use Apply Base on it. Like this one

If you just press that button it will ... destroy your sculpt -

But! If you first sculpt something on model ... something, whatever it is

And only then press Apply Base - everything will be ok.

This is after i pressed Apply Base. as you see all sculpt data is on it's place. But topology of mesh is changed. Probably when blender activates sculpt mode it is not load all the sculpt data or... something like this.
there is still problems, if you press Aplly Base 5-6 times it will destroy your mesh like this:

More times you press Aplly Base - more distortion you will get.
Maybe there is a way to... fix positions of lowpoly mesh vertexes by binding them to some closest vertexes of highpoly mesh from multires? And when user press Apply Base it should move only when that highpoly mesh vertexes are moved... (sorry for my english). I don't want to install visual studio and else things because by pc has no memory left on c drive. But i want to fix it, ofk. Because Multires modifier is very useful for making Normal Maps, paint some scars, pores and other things. Dyntopo is great but there is a lot of situations where you cannot remesh your model every time you change it. + baking normal map from multires is faster + very accurate (maybe in future we will have baking AO or Cavity maps from multires, i hope).
For tests i used latest blender 2.82 beta build from Blender.org, blender-2.82-81b7f8efaf7a-windows64
I don't know why, but someone removed old level switch feature frob Multires. This how it was(in 06 month of 2.8 build) -

And now how it is -

I don't know who and why done this. Because bug is still in place, but no level switching anymore.... Why? Please, at least return this level switch to us.

there are few suggetions for people that has this bug:
For example you have already made model with hires modifier and you want to use Apply Base on it. Like this one

This is not happening for 2.82 since we are in bugfixing only phase now, and this is a bigger change.

This was resolved by 6eaf51ef3e5b.
Now we have to decide if we include this in 2.82.

It is better to discuss this in a design task: D6603
So closing this as it is not a bug.

I agree with adding offset in bottom part.

I don't think we should move the marker region to the top. It would make things inconsistent, but it's also a workaround exposed as feature.

I think the best solution is to offset the strips so the bottom ones aren't always covered. Or, make it possible to scroll past the bottom layer.

In T57976#849113, @Eitan (EitanSomething) wrote:

In T57976#623927, @Richard Antalik (ISS) wrote:

Problem is, that blocked area is absolute, regardless of timeline zoom and it can block lower channels., as you can not pan below zero.
Simplest thing would be turn markers upside down. so they are selected on the upper part of timeline.
Should I write patch for this?

Putting the marker on the top won't help because it would then block the sequences on the top.

I try to get this fixed as quickly as possible in order to get it into 2.82

In T57976#623927, @Richard Antalik (ISS) wrote:

Problem is, that blocked area is absolute, regardless of timeline zoom and it can block lower channels., as you can not pan below zero.
Simplest thing would be turn markers upside down. so they are selected on the upper part of timeline.
Should I write patch for this?

@Erick Tukuniata (erickblender) better if we keep the discussions where they originated. I will write an update to bf-committers now. Thanks for the reminder.

Yo @Dalai Felinto (dfelinto) Can you keep us update on this email

I absolutely agree. Multires badly needs some love.