Re: [XBoard-devel] gtk-branch

[John Cheetham]

> At 10:32 11-11-2011 +0000, John Cheetham wrote:
>>  I did a change which I think improves the piece animation. The overlay 
> piece routine was being called OK to draw the piece yet the piece didn't 
> appear on the screen. I added an iteration of mainloop after the piece is 
> drawn 
> and this has improved it. Also the start square wasn't set so it wasn't 
> being cleared properly.
> 
> 
> Hmm, its starts to sound a bit too much like black magic, for my taste...
> 

I think it is a fairly common problem in GTK when doing screen updates in a 
loop that they don't get updated on the screen straight away but wait for the 
next main loop (which won't occur until the loop is exited). To fix it you can 
run one iteration of the main loop yourself (you can check first to see if any 
events are pending which shows if it's needed or not). This will process any 
outstanding events and update the screen. I think the queue_draw() function 
mentioned in another post might have the same effect.

> But indeed there is an improvement. I use -animateSpeed 500, and what I see 
> now 
> is this:
> 
> 1) the piece moves instantly to its to-square
> 2) at the same time the arrow is drawn (I have arrow highlighting on)
> 3) A new piece appears on the from-square
> 4) The piece on the to-square stays there as well
> 5) Only the arrow head on the to-square remains; the rest of the arrow is 
> erased.
> 6) The piece on the from square now starts moving
> 7) Sometimes animation frames still seem to be missing, although most are 
> drawn 
> now
> 8) When the Aimated piece fially coalesces with its fore-runner on the 
> to-square, the arrow is redrawn
> 

That's strange. For me it works pretty good. With speed 500 the piece moves 
smoothly and slowly from its source square to its target square (even following 
the L path for a knight) and then the arrow is drawn afterwards. Maybe there is 
a problem with different versions of GTK.

> The blast waves of atomic captures are still not all drawn (I counted 6 now).
> There is something fishy there anyway, because they don't look like colored 
> disks,
> but there is an extra circle around them (already from the next-larger 
> animation 
> frame?)
>

Haven't tried this yet.