From: Hristo A. <nj...@ya...> - 2008-07-30 02:34:16
|
I have the code hosted on http://code.haskell.org/~ecks/goClient If you can, please check out CairoTest.hs, and I think you will also need all of the png images. This is actually an upper limit of my problem domain and in reality will probably not happen, but something close to it can. I'm not sure how to compile gtk to use debugging and even if I did, I don't really know much about gtk to derive any meaning out of the messages. Thanx for the help so far, Hristo --- On Tue, 7/29/08, Axel Simon <Axe...@en...> wrote: From: Axel Simon <Axe...@en...> Subject: Re: [Gtk2hs-users] resizing windows To: nj...@ya... Cc: "Axel Simon" <Axe...@en...>, gtk...@li... Date: Tuesday, July 29, 2008, 4:07 AM On Mon, 2008-07-28 at 15:40 -0700, Hristo Asenov wrote: > 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. Perhaps you could try an off-the-shelf one to see if it gets any better. > 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? I suspect there is something wrong with the logic in your program since I don't think Gtk should fill the area that needs to be redrawn before your drawing actions in the expose handler are executed. Could you post a runnable example of your program? You can get update information from Gtk if it is compiled with debugging on (normally it isn't; not I'm talking about Gtk here, not Gtk2Hs). You might be able to glean some of this information by adding putStrLn statements into your own code or maybe even getLine to stop execution (never tried that myself) in order to see if the background gets filled before your expose handler is called. Are you returning True from your Expose handler? If it turns out that your drawing is simply too slow, you can use the information in the drawing even (the rectangle or event the region) to determine which regions of the canvas need to be redrawn. Axel. |