The latest blender 2.93 alpha build for Mac Intel (on my Mac Pro 2013 with AMD graphics) will crash 100% of the time when loading the Barbershop_Cpu demo also.

It definitely feels like once the mac display wakes up from sleep, blender is on borrowed time. It may not crash immediately, but it will crash "any second now" and almost always does.

I was able to reproduce this IF I also let the display sleep before returning to the app.
Steps:

1. Open this file
2. Move to another app
3. Sleep the display
4. Wake the display
5. Return to blender

Blender crashes.
I believe this will require an AMD for this crash to happen, however, and I can't seem to make it crash every time. I get is similar crashes a lot, but rarely is it repeatable 100% of the time. It's maddening.

It's possible these crashes are related to some of the other bug reports, like Blender crashing after the display wakes from sleep. This happens to me fairly consistently, so it's possible to find a repeatable bug there. Otherwise, the only other consistently repeatable one that I could find that happens every time is that the "spring" demo crashes while loading. But that only seems to happen for me when using a 2013 mac pro. That file loaded fine on a 2012 Mac Pro with an AMD RX 580.

Thank you for looking into this. I dont think we should just hope that Vulkan fixes it, however, especially since Vulkan for Blender is likely a long ways off. Personally, I would even be happy with workarounds, as long it results in a stable Blender. I've tried not using EEVEE, not allowing the display to sleep, but nothing seems to help overall. I sincerely hope the developers can find a solution for this.

I've tested the latest M1 build from Stephan Werner and it does not exhibit this issue (great news for the future), so it suggests this issue is related to AMD mac drivers not playing well with Blender. My current workstation is a 2013 Mac Pro, which is a highly capable machine, along with many other macs with AMD graphics. I sincerely hope this longstanding bug can finally get fixed ASAP so we can start using Blender on our workstations again.

I can confirm this happens on my 2013 mac pro with D700 graphics.

In D1783#41091, @Ton Roosendaal (ton) wrote:

Galen: thanks for sharing, very useful this kind of info. The more detail studios share the better.

You're right, Optimus was deciding to launch blender using integrated graphics, not the nvidia chip for some reason. I forced blender to launch with the quadro and now all is well.

Ok, it turned out to be a driver issue. I had multiple wacom drivers for different tablets installed. One for an Intuos/Bamboo and one for Intuos3/Cintiq. Blender doesn't seem to like that. It's worth noting that all of my other apps (Maya, Krita, Photoshop, Mudbox, ZBrush) didn't have any issues but Blender seems particularly sensititive to it. Maybe it was trying to use the driver for the Bamboo tablet even though it was the Intuos3 that was hooked up to it? I don't have the Bamboo available to test anymore but if I can find one I'll try it out. In any case, pressure sensitivity is working fine now. Thanks!

Ok, got it! Thanks!

I just loaded a hair scene of mine using 2.74 offical release and this bug is back!! Did the patch get removed from master? Is there a build where I can get it back? I'm desperate at this point. I'm on a deadline and this was fixed a few weeks ago. :P

I'm not sure the patch helped. As of RC3 the issue is still present.

I'm ok with Cessen's proposal it as long as the goals are achieved, doesn't have to use modifier keys or increase the number of clicks and it allows development on the feature to continue.

That's actually GREAT news! :) Thanks for looking into it!

The above link may not work. If not, try this one.

I can confirm this bug as well for a project I'm working on. Oh man I hope this one can be fixed soon! :)

Keep in mind that this is an alternate way of working with curves in the graph editor. A separate mode, if you will. There are many other ways to work with curves in other graph editors I've seen. I've seen a mode where all the channels you select get stacked on top of each other in the editor so you can compare them side-by-side or vertaically stacked without any overlap. If such a feature wants to be implemented into the graph editor someday, what makes more sense? Another hotkey combination or another toggle switch to a different mode in the menu?
The view menu can easily be de-cluttered with a little consolidation. We can have various channel "modes" be in their own nested directory inside the view menu.
Being able to switch between these modes makes Blender's graph editor more flexible and better for dealing with common and uncommon challenges in working with and managing curves. There doesn't have to be a "one-size-fits-all" method of working with curves, since not all challenges are the same.
Having selectable modes that the user can choose from also allows for further expansion down the road, as we now have a nested directory that has room for more modes if someone feels it would be helpful.

Ugh, that's very sad to hear Severin. Hopefully this can be picked up again in the near future.

Hi guys, sorry for being late to provide feedback. Cessen, I figured that some users would balk at this functionality. It's inevitable. But keep in mind that this is toggle feature that probably shouldn't be enabled by default. Coupling selection with hiding isn't neccessarily required either since you can break the functionality into 2 options in we must ("auto-frame" and "auto-hide").

They don't have to be all-in-one. I'm all for flexibility, especially since blender's user base is so wide and diverse. I strongly appreciate the wide array of options that are provided to the user.

And, for the record, having this in the view menu is logical, and while it is getting big, I really don't care becuase its a menu where I go for all things related to working with the view of the graph editor. Placing this as an icon in the graph editor window would be MORE clutter, and useless, since this a "set-it-and-forget-it" feature. Icons should be for frequently used options.

I agree that menu is getting big. And I also agree that the existing visibility icons should NEVER lie to the user. So no arguemnts there. This auto system should work in tandem with what's already there.

I haven't tested it, but judging by the demo it's looking almost perfect.

Sounds good! I figured that might be the case. Thanks for looking into it Sergey!

Hello Cessen,