Review of attachment 286540 [details] [review]:

::: src/iagno-main.vala
@@ +367,3 @@
+            timeout_running = true;
+            /* PIXMAP_FLIP_DELAY * 31 frames, needed for the animation */
+            computer_timer1 = Timeout.add (620, computer_move_cb);

Does this fix the animation glitch that sometimes occurs on the last turn of the game?

Review of attachment 286540 [details] [review]:

::: src/iagno-main.vala
@@ +41,3 @@
+    private uint computer_timer2 = 0;
+    private uint computer_timer3 = 0;
+    private bool timeout_running = false;

It might be past my bedtime, but I can't follow what these are all used for... I can see why you said you weren't satisfied with this approach. ^^  Alternative suggestion incoming....

@@ +377,3 @@
+
+        if (game.n_tiles != 4 && game.n_tiles != 63 && !fast_mode)
+            computer_timer2 = Timeout.add_seconds (1, () => { timeout_running = false; computer_timer2 = 0; return false; });

Our style for lambdas is:

computer_timer2 = Timeout.add_seconds (1, () => {
    ...;
    ...;
    ....;
});

@@ +385,3 @@
+        computer.move (ref x, ref y);
+        computer_timer3 = Timeout.add (100, () =>
+            {

Style: opening brace one space after the => for lambdas.

Created attachment 286550 [details] [review]
computer-player: split searching out of move()

Let's split the move action out from the search logic, so that we can do
more complex things in move(), like returning after a delay and running
the search in another thread.

Created attachment 286551 [details] [review]
Calculate move delay after performing search

Right now, we add a fixed amount of delay before each move, then start
the search. This means that the game takes longer to move on higher
difficulty levels and slower computers. Mitigate this by computing
artifical delay after the completion of the search instead. (This means
the AI will now move a bit faster than before.)

I don’t understand the technology you’re using, but it doesn’t work… The drawing and animation of the human player’s tile isn’t done before the AI finish its thinking (many seconds after you clicked the board). Try in level 3 (after the two first random move)…

Oh, sorry, didn’t see the other bug[1].

(In reply to comment #1)
> ::: src/iagno-main.vala
> @@ +367,3 @@
> +            timeout_running = true;
> +            /* PIXMAP_FLIP_DELAY * 31 frames, needed for the animation */
> +            computer_timer1 = Timeout.add (620, computer_move_cb);
> 
> Does this fix the animation glitch that sometimes occurs on the last turn of
> the game?

I don’t know which glitch you’re talking about. Maybe. ^^ It should fix (even if I don’t tried) the fast-mode bug where tiles are blocked by the AI thinking, without requiring threads. But if we use threads… no need for me to change the (minimal) delays.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=736941

(In reply to comment #5)
> I don’t understand the technology you’re using, but it doesn’t work… The
> drawing and animation of the human player’s tile isn’t done before the AI
> finish its thinking (many seconds after you clicked the board). Try in level 3
> (after the two first random move)…

Well, I didn't even notice this, so it's good that you pointed it out. But yeah, that's inadvertently fixed by the patch in bug #736941.

(In reply to comment #6)
> I don’t know which glitch you’re talking about. Maybe. ^^ It should fix (even
> if I don’t tried) the fast-mode bug where tiles are blocked by the AI thinking,
> without requiring threads.

I'm not familiar with this bug? Maybe a screencast (or longer description) will help me understand.

We really ought to run the search in another thread regardless; otherwise, the UI becomes unresponsive while the AI is thinking. It's only really apparent if you increase the search depth.

Attachment 286550 [details] pushed as 1b5b968 - computer-player: split searching out of move()
Attachment 286551 [details] pushed as 14a996c - Calculate move delay after performing search