Its highly likely that this bug is specific to your hardware/driver configuration.
These kinds of display issues are often caused by OpenGL driver bugs.

I wouldn't surprise me if the macOS setting got lost in a system update, that kind of thing has happened to me before.

Ok, kind of figured it out. I had to change the OSX settings to have a "secondary click" (right click option)

Will do, just FYI it worked fine until I got a computer upgrade, I think I used to have and older version of OSX.

in the preferences menu go to system and try a different selection method see if that improves things.

I have the 'same' issue, except that the rendered tiles on GPU are completely black. No artifacts.
OSX 10.12.6
iMac 5k, 4Ghz Intel i7
AMD Radeon R9 M395X 4096Mb

More than a week without reply. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply. Due to the policy of the tracker archiving for until required info/data are provided.

I can reproduce the issue on so called trashcan here in the studio.

I can't reproduce this with the hardware I have available (no macOS here). Maybe @Lukas Stockner (lukasstockner97) can take a look?

I tried to repro this with Intel + macOS (with a simplified megakernel since the full one doesn't work), but denoising seemed to work ok. @Mai Lavelle (maiself), do you have a way to test this perhaps? Not sure who maintains macOS OpenCL now.

Certainly Blender stops zooming at a certain point, as explained in the answer on stack exchange. Re-entering the viewport on the opposite edge sounds like continuous grab. These are not bugs, but a crash would be. However I couldn't reproduce any crash with latest master on macOS 10.12, zooming out again after having zoomed in fully towards the center point works fine for me.

if you can share the .blend that is causing issues that might also help

Using cycles, render is set for CPU.
I looked for the crash log in the folder of the blend file, nothing.
will look at the other locations, thanks.

Do you have a crash log that you can attach to this report? Two places to look:

• In the Console application on macOS, under System Reports.
• In the Finder, Go > Go To Folder ... > type "/tmp", there may be a crash log written by Blender.

not sure how to proceed. Looked at bug reports URL. provided as much info as I have.

Please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

This should be solved now with the continuous grab fixes.

The Blender internal BVH builder is running out of stack space, it might be macOS specific since threads there have a smaller default stack size than other operating systems.

Crash confirmed.

Oh, did not saw latest comment… so crash can be replicated, and seems to be a Cycles issue, OSX-only maybe?

I could test it with a gaming mouse now and the issue is much worse then. I found a fix now, mouse motion should be always smooth now, both for gaming mouse and heavy scenes and other mouse.

@Andrei Nadin (AnadinX) No problem. I am glad it worked for you too :)

@Chris Slazinski (mallow) indeed it is, big apologies I had not seen your comment when I came across this problem before.

@Andrei Nadin (AnadinX) Isn't this the same as my fix?
https://developer.blender.org/T49473#403226

Pretty good fix here for it.

No reply over a week so closing for now.

Yes sorry I am running OSX 10.12.5

As user I would like to keep simple way, so I'm ok with the .dmg solution.

+1 for signed .dmg

Ok, the fix might be so simple, but some possible solutions:

• Put blenderplayer in blender.app/Contents/Resources/
• Distribute blender as a signed .dmg

Gatekeeper translocation copies .app to folder under /private/vars/folders. That is, quarantine location. We don't know what is the location where blender was copied from.

Surely this is still a bug and something we can fix quite easily?