GUI concept for a reactive, asynchronous graphical editor

Question

I think I could describe this problem in an abstract way, but I suppose it will be easier to understand when I describe it in a real world environment.

The Problem

Imagine a graphical editor where different graphical objects can be inserted via drag and drop:

Now when I drop the half transparent object there. Through some heavy computations the following result is achieved:

Up until now we do the computation at the time when the user releases the mouse synchronously. Meaning, he waits lets say two seconds until he can use the program instead. As I said previously this is just a simplified example. It needs quite more than this interaction to have a two second calculation time, but it happens.

Now we thought it would be nice to do the whole computation asynchronously, so that the user use the rest of the application during this time. And there lies the problem The user could now in these two seconds trigger additional drops as he pleases.

Meaning he has dropped three objects (a,b,c) while not even the first was completely calculated (A).

Solution 1

The user can drop the objects as he pleases. The changes are accumulated after the first calculation is ready.

Problem with this solution is, that the user drops objects on the initial state of the worksheet probably assuming that the first object (a) was never inserted. It will definitively confuse the user.

Solution 2

The dropped objects (b,c) are just ignored. Of course the UI would be "blocked" with an overlay and drop would be made impossible.

Problem with this solution is, that I would have again blocked the UI only now with my own custom overlay.

The Question

Have you encountered any of these problems? Is there a smarter solution than any of the two presented?

Answer 1

Solution 1 is the one preferred by most users, based on my experience. The problem you described, "he user drops objects on the initial state of the worksheet probably assuming that the first object (a) was never inserted," can be mitigated with a temporary placeholder visual that indicates an object was dropped, but its state is not yet computed. I would make the visual similar to the final result, but with a difference that indicates the final result is being computed. Also, have another visual somewhere, either in a status area, or as part of the temporary visual, with a small, unobtrusive animation, indicating calculations are occurring.

Finally, I would work hard to make these calculations faster. Perhaps there is a problem with the algorithm, or perhaps you need to pre-fetch some data remotely. The faster you can speed up the calculations, the more friendly your application will appear to the user.