|
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:
I have learned that _all_ drawing in a GUI should be done as responseAt 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 MichelOK, 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... 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
|
[Prev in Thread] | Current Thread | [Next in Thread] |