We have a scenario where we need to call an API so that the user can draw something on the screen. The following scenarios are possible:

1. API call goes quickly and is successful: user draws a new object on the screen with no obvious delay.
2. API call goes quickly and is unsuccessful (rare but can happen, e.g. if 3G data drops out for a moment): user tries to draw a new object on the screen, but gets fast visual feedback that this has not happened. At this point they can try again immediately and don't necessarily need an error explaining what happened or that they can try again.
3. API call goes slowly but is successful: user is able to draw an object on the screen but there is an appreciable delay (we hope this is rare, but we need to concede that it might happen). The interaction would feel 'laggy'.
4. API call goes slowly and is unsuccessful: user waits longer for visual feedback before eventually discovering that they need to re-attempt drawing the object.

We could get around the uncertainty of latency and API call success by letting the user 'successfully' draw on the screen in the client (i.e. making the interaction more responsive), and letting the API call and response happen behind the scenes. However this would necessitate an error message when the API call has failed: we would have to let the user know "yeah, sorry, that drawing on the screen you just did? Not so much."

So my questions are:

a) How long is too long for 'drawing on a screen' response latency? 

and

b1) Should we prioritise making the interaction fast (i.e. execute it in the client and make the API call behind the scenes, with a chance of having to show an error message that says "uh, we kinda lied, you didn't draw that thing") 

or 

b2) accept that occasionally it will be slow and that users will just have to try drawing the thing again? (doesn't seem very onerous and will probably not happen very often)