xboard-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XBoard-devel] gtk-branch


From: Michel Van den Bergh
Subject: Re: [XBoard-devel] gtk-branch
Date: Fri, 11 Nov 2011 15:29:41 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15

On 11/11/2011 11:47 AM, h.g. muller wrote:
At 09:09 11-11-2011 +0100, Michel Van den Bergh wrote:
Here there is some discussion about cairo and double buffering.
See item 6.2.

http://developer.gnome.org/gtk/2.24/gtk-question-index.html

Michel
OK, that basically confirms my diagnosis. The move-animation
calls all create their own cairo-context outside the expose handler,
so they write to the display directly, but also trigger an expose event,
which then calls DrawPosition. For animateDragging DrawPosition
takes care of drawing the animated piece in the desired place, by
a calltoDrawDragPiece at the end, but it in oblivious of animateMoving,
so it overwrites the display with the animated piece still on the from-square
(or without atomic blast wave).

Not sure how we are expected to use cairo then. We could draw everything
from the expose-event handler, but what then would trigger the expose event?
It seems hard to use a context created in the expose handler for drawing
something outside it...

I have learned that _all_ drawing in a GUI should be done as response
to an expose event.

You can generate your own expose events in gtk by
gtk_widget_queue_draw_area ()

For an amination you may have to create a timer to generate such events at regular
intervals.

I don't know how this plays out with cairo (I have never used cairo).

Here are some notes on cairo animation

http://cairographics.org/threaded_animation_with_cairo/

You can see that in the examples they call indeed
gtk_widget_queue_draw_area(window, 0, 0, width, height);








reply via email to

[Prev in Thread] Current Thread [Next in Thread]