I am using xmonad 0.5, a tiling window manager, so when I switch windows one totally covers the other one usually. If I put a tracer inside the callback to "oneExpose", it gets called everytime I bring the gtk window into view. Would I need to use a non-tiling window manager? It would seem to me that the same behavior would occur if I minimize then maximise the window. I also tried setting "widgetSetAppPaintable" to False on the main window but it seemed to produce no effect. I did some more experimentation and am now noticing that when I move any window over the gtk canvas, there is a trail of gray marks that are left behind until the screen is redrawn. The cairo operations that I'm doing are intensive, nonetheless, but the reason it takes so long probably is because the onExpose callback gets called every time. Would I need to switch window managers?

--- On Mon, 7/28/08, Axel Simon <Axel.Simon@ens.fr> wrote:
From: Axel Simon <Axel.Simon@ens.fr>
Subject: Re: [Gtk2hs-users] resizing windows
To: gtk2hs-users@lists.sourceforge.net
Date: Monday, July 28, 2008, 5:55 AM

On Sat, 2008-07-26 at 17:11 -0700, Hristo Asenov wrote:
> This is to a degree a continuation of my last post. I used
> postGUIAsync and worked wonderfully. Now, in the beginning when the
> window is created, it works exactly like I wanted. However, when I
> switch the view

the view -> the input focus (I assume)

> to another window and then bring the created one into view, I am
> presented with a gray screen until the whole thing is redrawn on the
> screen. I am making a lot of cairo drawing calls so I guess that is
> where the delay is introduced.

Gtk+ has double buffering by default (see widgetSetAppPaintable) which
means that each time a widget is redrawn, all your drawing operations
are done on an off-screen buffer and then copied to the screen. You
might want to turn that off to see if you drawing actions are really
that slow of if you have some other problem in your control logic (maybe
you invalidate too often).

> However, there is usually no change of the picture. Would using
> "save" and "restore" work?

No, save and restore only allow you to temporarily store the current
style in a Cairo context. They are useful if you're changing, say, the
width of lines just for one line and then want to use the previous

> If so, how could I use these calls appropriately? Also I need to do
> something when the window is resized because it takes a long time to
> redraw everything in the modified size.

You could certainly come up with something rather sophisticated that,
say, scales up the previously valid image before the new image is ready.
But I think it might be easier to figure out why your drawing actions
are so slow. The clock simply redraws everything every second. In fact,
my window manager saves the content of every window if I move another
window of it (this isn't the case with older window managers). You can
see this by adding debug output to the expose event in the clock example
and observe that you get no extra expose signals when moving another
window over the clock. Thus, the fact that you see a grey screen when
you move a window over your application might mean that it's not updated
correctly (or you have a really old window manager).

> I tried looking at the Clock example again but I'm not sure how the
> whole "onConfigure" call works. It does not do what I expected
> does not redraw the screen properly. It was mentioned earlier that
> IORefs weren't needed so I didn't need them. If there is a better
> example on resizing the screen in Cairo, that would be useful.

The configure signal should not do any drawing but should allocate fonts
or other resources that change with the size of the window. You only
need an IORef if you need to store these resources so that the expose
handler can use them. I think the clock example is quite complicated.
Have you had a look at cairo/Drawing.hs?


This SF.Net email is sponsored by the Moblin Your Move Developer's
Build the coolest Linux based applications with Moblin SDK & win great
Grand prize is a trip for two to an Open Source event anywhere in the world
Gtk2hs-users mailing list