@Julian Eisel (Severin): I can't reproduce this issue here (Windows 8.1 + Nvidia GeForce 740M)

My hardware: Video card: Nvidia GTX 750ti 2gb, driver 352.79, cpu core i5 750, 8 GB ram...
Eraser, sculpt brush and other brushs display correct. It's not only render mode, you cant's see mouse cursor, because xubuntu don't grub it when i make screenshot.

Tested on blender-softwaregl issue reproduced here.

Tested on windows 8.1 x32, video integrated intel, some here.

windows 10 pro 64bits
NVidia GTX960 + GT730
version: 2.77 (sub 0), hash: 34fe03c

@perfection cat (sindra1961) Thanks for the screenshots. I can now reproduce the bug, and I think I might know why it happens :)

Cheeesis, this is tricky. Spent some hours investigating, here's what's going on (if I'm not mistaken):

• Selecting the item from the menu makes the ui-handler return WM_UI_HANDLER_BREAK which again makes the wm-handler return WM_HANDLER_BREAK.
• Because of this, wm_event_do_handlers doesn't call the functions needed to set the right context for drawing the cursors (ED_screen_set_subwinactive & wm_paintcursor_test).
• To trigger an update of the cursor, it's usually enough to send a mouse move event, which is done in fact.
• Issue is though, that now the modal operator for stroke sculpting runs, and - unlike other modal operators - it doesn't return OPERATOR_PASS_THROUGH for the mouse move event added (nor for any other mouse move event).
• This means, as long as the operator runs, the wm_event_do_handlers never calls the functions for updating the cursor context.
• The wrong context causes a glScissor call for the wrong region.

Possible ways to fix this:

1. Let stroke sculpt operator pass the first event - P334
2. Always return OPERATOR_PASS_THROUGH on mouse move during stroke sculpting and use paintcursor poll to check for correct region (to lazy to write patch, should work though ;) )
3. Always let WM call the cursor context update functions after cursor was changed (a bit ugly and just another event system hack, but technically it would be a correct fix) - P333
4. Always let WM call the cursor context update on mouse move - P335 (also a correct fix - here we had to add a paintcursor poll check for correct region too though)

While investigating I also noticed that the return values in gpsculpt_brush_modal are managed in a pretty odd way. For example it's assuming that view rotation is set to middle mouse button. The operator should return OPERATOR_PASS_THROUGH by default and only block events it really uses (doing that would basically include #2.)

BTW: Invoking the stroke sculpt operator from the search menu outside of the main 3D view region causes a crash :| Instead of using CTX_wm_region to get the region we should search for a region that supports gpencil drawing (we'd also need that for #2.).

This is also reproducible from other editors btw, e.g. call stroke sculpting from search menu in node editor toolbar.

We could fix the crash by ensuring the operator is only called in the main region in case of a 3D View, but that would make it inconsistent with other areas (wouldn't be a big annoyance though).

I'd propose we continue as follows:

• Add bool ED_region_supports_gpencil(ARegion *ar)
• Use it for implementing #4
• Use it for fixing crash
• Cleanup gpsculpt_brush_modal for a more streamlined event handling

@Joshua Leung (aligorith), any feedback? Would just go with my proposed changes otherwise.

This issue is still happening for me
Windows 10
GTX 770
Blender V2.78c