From: Axel S. <Axe...@en...> - 2008-07-31 22:12:09
Attachments:
CairoTest.hs
|
On Jul 30, 2008, at 4:34, Hristo Asenov wrote: > 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 quite sure what you mean with the above. I had a look at your code and moved all the code that reads the image files out of the expose handler. It's still slow, but it might be faster than before. I think drawing with the pattern is quite slow. Maybe there is a different alternative, for instance, to actually restrict yourself to each rectangle of the exposed region. I had trouble running your code as it seemed to crash my X server whenever more than two configure requests were pending. It didn't happen anymore after I removed some redrawing code. I don't quite understand what's happening. I realised that there are some very useful functions not exported from Cairo. That's a pity since there's one function that allows you to load an image as a surface without using it immediately. I've added the appropriate import to your file. > 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. I think it's not really necessary since most information can be obtained by adding putStrLn statements. Hope it helps a bit, Axel. |
From: Hristo A. <nj...@ya...> - 2008-08-01 01:33:58
|
Hello, did you mean to send me a modified version of CairoTest.hs? There is only a binary file attached with the message. > I had trouble running your code as it seemed to crash my X server > whenever more than two configure requests were pending. It didn't > happen anymore after I removed some redrawing code. I don't quite > understand what's happening.I'm pretty sure I commented out the callback to "onConfigure", do you mean that that it still gets called somewhere? What I meant by my statement before is that the fact that all the stones are drawn on a board almost never happens in the real program, so this is the most stones that my program can draw. > Maybe there is a different alternative, for instance, to actually > restrict yourself to each rectangle of the exposed region.Yes, I tried restricting the drawing to a region by calling "region exposeRegion" under "renderWithDrawable win .." line, but that leaves black trail marks when I drag another image over the cairo image. That function from that you mentioned would be very useful, I was hoping I could find something like that. --- On Thu, 7/31/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: Thursday, July 31, 2008, 6:03 PM On Jul 30, 2008, at 4:34, Hristo Asenov wrote: > 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 quite sure what you mean with the above. I had a look at your code and moved all the code that reads the image files out of the expose handler. It's still slow, but it might be faster than before. I think drawing with the pattern is quite slow. Maybe there is a different alternative, for instance, to actually restrict yourself to each rectangle of the exposed region. I had trouble running your code as it seemed to crash my X server whenever more than two configure requests were pending. It didn't happen anymore after I removed some redrawing code. I don't quite understand what's happening. I realised that there are some very useful functions not exported from Cairo. That's a pity since there's one function that allows you to load an image as a surface without using it immediately. I've added the appropriate import to your file. > 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. I think it's not really necessary since most information can be obtained by adding putStrLn statements. Hope it helps a bit, Axel. > 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...>, gtk2hs- > us...@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. > > ---------------------------------------------------------------------- > --- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gtk2hs-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users |
From: Axel S. <Axe...@en...> - 2008-08-01 08:02:13
|
On Aug 1, 2008, at 3:34, Hristo Asenov wrote: > Hello, did you mean to send me a modified version of CairoTest.hs? > There is only a binary file attached with the message. > > I had trouble running your code as it seemed to crash my X server > > whenever more than two configure requests were pending. It didn't > > happen anymore after I removed some redrawing code. I don't quite > > understand what's happening.I'm pretty sure I commented out the > callback to "onConfigure", do you mean that that it still gets > called somewhere? It is a good thing to use the configure signal, I think. You could calculate all scaling factors and transformation matrices in this signal rather than doing this in the expose handler. > > What I meant by my statement before is that the fact that all the > stones are drawn on a board almost never happens in the real > program, so this is the most stones that my program can draw. Ok, but in the example you sent me, the code for drawing the stones was commented out. It would obviously be better if you would draw the grid using fewer but longer lines instead of drawing little squares. Furthermore, I had the impression that everything is much faster if you move the drawing code before the withPatternForSurface. I don't know if it is better to copy the background image into the canvas (using functions in Gdk.Pixbuf) and then to use Cairo to draw the grid and then copy the stones as images with an alpha. Cairo is great for creating fancy drawings but it's probably wasteful if you use these ability to impose an image as a pattern simply to create a background. > > > Maybe there is a different alternative, for instance, to actually > > restrict yourself to each rectangle of the exposed region.Yes, I > tried restricting the drawing to a region by calling "region > exposeRegion" under "renderWithDrawable win .." line, but that > leaves black trail marks when I drag another image over the cairo > image. Ok, that might be an imprecision. In fact, the expose handler will only draw in the area that is passed in as Region, the rest is always clipped. What I meant was that you could change your code in a way that you only draw those stones that lie in the passed-in region. If you flip a stone, then you should invalidate only that area of those stones that have changed. That way, you only redraw what has changed. That's quite fiddely to get right, but that would get a better perceived performance. > > That function from that you mentioned would be very useful, I was > hoping I could find something like that. It should have been exported. We should probably check Cairo for other hidden functions that are not exported. Axel. > > --- On Thu, 7/31/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...>, gtk2hs- > us...@li... > Date: Thursday, July 31, 2008, 6:03 PM > > On Jul 30, 2008, at 4:34, Hristo Asenov wrote: > > > 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 quite sure what you mean with the above. > > I had a look at your code and moved all the code that reads the image > files out of the expose handler. It's still slow, but it might be > faster than before. I think drawing with the pattern is quite slow. > Maybe there is a different alternative, for instance, to actually > restrict yourself to each rectangle of the exposed region. > > I had trouble running your code as it seemed to crash my X server > whenever more than two configure requests were pending. It didn't > happen anymore after I removed some redrawing code. I don't quite > understand what's happening. > > I realised that there are some very useful functions not exported > from Cairo. That's a pity since there's one function that allows you > to load an image as a surface without using it immediately. I've > added the appropriate import to your file. > > > 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. > > I think it's not really necessary since most information can be > obtained by adding putStrLn statements. > > Hope it helps a bit, > Axel. > > 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...>, gtk2hs- > > us...@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. > > > > > ---------------------------------------------------------------------- > > --- > > This SF.Net email is sponsored by the Moblin Your Move Developer's > > challenge > > Build the coolest Linux based applications with Moblin SDK & win > > great prizes > > Grand prize is a trip for two to an Open Source event anywhere in > > the world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > Gtk2hs-users mailing list > > Gtk...@li... > > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users > > |
From: Hristo A. <nj...@ya...> - 2008-08-02 21:03:59
|
Hello, Do you think that it would be better for me to get rid of Cairo altogether and use the local gtk functions instead? Would that speed up performance? Would it be able to accomplish what I'm trying to do (it's not much more than this except adding mouse events)? It would probably make my code and design alot simpler since I dont need any external libraries. > It should have been exported. We should probably check Cairo for > other hidden functions that are not exported.What do you mean? What are the names of the hidden functions? > What I meant was that you could change your code in a way > that you only draw those stones that lie in the passed-in region. If > you flip a stone, then you should invalidate only that area of those > stones that have changed. That way, you only redraw what has changed. > That's quite fiddely to get right, but that would get a better > perceived performance.huh, how would i be able to invalidate an area? is there a way to register an area so that unless it is not updated, it is saved somewhere in cache so it doesn't have to be re-updated? Hristo --- On Fri, 8/1/08, Axel Simon <Axe...@en...> wrote: From: Axel Simon <Axe...@en...> Subject: Re: [Gtk2hs-users] resizing windows To: "gtk2hs Mailing List" <gtk...@li...> Date: Friday, August 1, 2008, 4:02 AM On Aug 1, 2008, at 3:34, Hristo Asenov wrote: > Hello, did you mean to send me a modified version of CairoTest.hs? > There is only a binary file attached with the message. > > I had trouble running your code as it seemed to crash my X server > > whenever more than two configure requests were pending. It didn't > > happen anymore after I removed some redrawing code. I don't quite > > understand what's happening.I'm pretty sure I commented out the > callback to "onConfigure", do you mean that that it still gets > called somewhere? It is a good thing to use the configure signal, I think. You could calculate all scaling factors and transformation matrices in this signal rather than doing this in the expose handler. > > What I meant by my statement before is that the fact that all the > stones are drawn on a board almost never happens in the real > program, so this is the most stones that my program can draw. Ok, but in the example you sent me, the code for drawing the stones was commented out. It would obviously be better if you would draw the grid using fewer but longer lines instead of drawing little squares. Furthermore, I had the impression that everything is much faster if you move the drawing code before the withPatternForSurface. I don't know if it is better to copy the background image into the canvas (using functions in Gdk.Pixbuf) and then to use Cairo to draw the grid and then copy the stones as images with an alpha. Cairo is great for creating fancy drawings but it's probably wasteful if you use these ability to impose an image as a pattern simply to create a background. > > > Maybe there is a different alternative, for instance, to actually > > restrict yourself to each rectangle of the exposed region.Yes, I > tried restricting the drawing to a region by calling "region > exposeRegion" under "renderWithDrawable win .." line, but that > leaves black trail marks when I drag another image over the cairo > image. Ok, that might be an imprecision. In fact, the expose handler will only draw in the area that is passed in as Region, the rest is always clipped. What I meant was that you could change your code in a way that you only draw those stones that lie in the passed-in region. If you flip a stone, then you should invalidate only that area of those stones that have changed. That way, you only redraw what has changed. That's quite fiddely to get right, but that would get a better perceived performance. > > That function from that you mentioned would be very useful, I was > hoping I could find something like that. It should have been exported. We should probably check Cairo for other hidden functions that are not exported. Axel. > > --- On Thu, 7/31/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...>, gtk2hs- > us...@li... > Date: Thursday, July 31, 2008, 6:03 PM > > On Jul 30, 2008, at 4:34, Hristo Asenov wrote: > > > 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 quite sure what you mean with the above. > > I had a look at your code and moved all the code that reads the image > files out of the expose handler. It's still slow, but it might be > faster than before. I think drawing with the pattern is quite slow. > Maybe there is a different alternative, for instance, to actually > restrict yourself to each rectangle of the exposed region. > > I had trouble running your code as it seemed to crash my X server > whenever more than two configure requests were pending. It didn't > happen anymore after I removed some redrawing code. I don't quite > understand what's happening. > > I realised that there are some very useful functions not exported > from Cairo. That's a pity since there's one function that allows you > to load an image as a surface without using it immediately. I've > added the appropriate import to your file. > > > 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. > > I think it's not really necessary since most information can be > obtained by adding putStrLn statements. > > Hope it helps a bit, > Axel. > > 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...>, gtk2hs- > > us...@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. > > > > > ---------------------------------------------------------------------- > > --- > > This SF.Net email is sponsored by the Moblin Your Move Developer's > > challenge > > Build the coolest Linux based applications with Moblin SDK & win > > great prizes > > Grand prize is a trip for two to an Open Source event anywhere in > > the world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > Gtk2hs-users mailing list > > Gtk...@li... > > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users > > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Gtk2hs-users mailing list Gtk...@li... https://lists.sourceforge.net/lists/listinfo/gtk2hs-users |
From: Axel S. <Axe...@en...> - 2008-08-02 22:20:13
|
On Aug 2, 2008, at 23:04, Hristo Asenov wrote: > Hello, > > Do you think that it would be better for me to get rid of Cairo > altogether and use the local gtk functions instead? Would that > speed up performance? Would it be able to accomplish what I'm > trying to do (it's not much more than this except adding mouse > events)? It would probably make my code and design alot simpler > since I dont need any external libraries. Composing several images should be easy and fast using functions in Gdk.Pixbuf. Drawing the lines for the grid could be done with a graphics context and the old Gdk drawing functions, but you can use Cairo for that and I don't think that drawing a few lines with Cairo is going to be a bottleneck. I think it's the use of an image as a pattern that slows things down. > > > It should have been exported. We should probably check Cairo for > > other hidden functions that are not exported.What do you mean? > What are the names of the hidden functions? imageSurfaceCreateFromPNG should but is not exported from Graphics.Rendering.Cairo. I've imported a module under ...Cairo.Internal.Surfaces.PNG for that. > > > What I meant was that you could change your code in a way > > that you only draw those stones that lie in the passed-in region. If > > you flip a stone, then you should invalidate only that area of those > > stones that have changed. That way, you only redraw what has > changed. > > That's quite fiddely to get right, but that would get a better > > perceived performance. > huh, how would i be able to invalidate an area? is there a way to > register an area so that unless it is not updated, it is saved > somewhere in cache so it doesn't have to be re-updated? No, you can't cache an area (although a window manager often does -- the X11 server under Mac OS always does, so does the Gnome window manager nowadays). But if a stone is flipped through a mouse click, you can invalidate just those regions. On the DrawWindow you can use: drawWindowInvalidateRect drawWindowInvalidateRegion On the Widget you can use (these will check if the widget has any children in that area and invalidate them if necessary; this is slower apparently even though there aren't any child widgets in your case): widgetQueueDrawArea Axel. > Hristo > --- On Fri, 8/1/08, Axel Simon <Axe...@en...> wrote: > From: Axel Simon <Axe...@en...> > Subject: Re: [Gtk2hs-users] resizing windows > To: "gtk2hs Mailing List" <gtk...@li...> > Date: Friday, August 1, 2008, 4:02 AM > > On Aug 1, 2008, at 3:34, Hristo Asenov wrote: > > > Hello, did you mean to send me a modified version of CairoTest.hs? > > There is only a binary file attached with the message. > > > I had trouble running your code as it seemed to crash my X server > > > whenever more than two configure requests were pending. It didn't > > > happen anymore after I removed some redrawing code. I don't quite > > > understand what's happening.I'm pretty sure I commented out > the > > callback to "onConfigure", do you mean that that it still gets > > called somewhere? > > It is a good thing to use the configure signal, I think. You could > calculate all scaling factors and transformation matrices in this > signal rather than doing this in the expose handler. > > > > > What I meant by my statement before is that the fact that all the > > stones are drawn on a board almost never happens in the real > > program, so this is the most stones that my program can draw. > > Ok, but in the example you sent me, the code for drawing the stones > was commented out. It would obviously be better if you would draw the > grid using fewer but longer lines instead of drawing little squares. > Furthermore, I had the impression that everything is much faster if > you move the drawing code before the withPatternForSurface. I don't > know if it is better to copy the background image into the canvas > (using functions in Gdk.Pixbuf) and then to use Cairo to draw the > grid and then copy the stones as images with an alpha. Cairo is great > for creating fancy drawings but it's probably wasteful if you use > these ability to impose an image as a pattern simply to create a > background. > > > > > > Maybe there is a different alternative, for instance, to actually > > > restrict yourself to each rectangle of the exposed region.Yes, I > > tried restricting the drawing to a region by calling "region > > exposeRegion" under "renderWithDrawable win .." line, but > that > > leaves black trail marks when I drag another image over the cairo > > image. > > Ok, that might be an imprecision. In fact, the expose handler will > only draw in the area that is passed in as Region, the rest is always > clipped. What I meant was that you could change your code in a way > that you only draw those stones that lie in the passed-in region. If > you flip a stone, then you should invalidate only that area of those > stones that have changed. That way, you only redraw what has changed. > That's quite fiddely to get right, but that would get a better > perceived performance. > > > > > That function from that you mentioned would be very useful, I was > > hoping I could find something like that. > > It should have been exported. We should probably check Cairo for > other hidden functions that are not exported. > > Axel. > > > > > --- On Thu, 7/31/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...>, gtk2hs- > > us...@li... > > Date: Thursday, July 31, 2008, 6:03 PM > > > > On Jul 30, 2008, at 4:34, Hristo Asenov wrote: > > > > > 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 quite sure what you mean with the above. > > > > I had a look at your code and moved all the code that reads the > image > > files out of the expose handler. It's still slow, but it might be > > faster than before. I think drawing with the pattern is quite slow. > > Maybe there is a different alternative, for instance, to actually > > restrict yourself to each rectangle of the exposed region. > > > > I had trouble running your code as it seemed to crash my X server > > whenever more than two configure requests were pending. It didn't > > happen anymore after I removed some redrawing code. I don't quite > > understand what's happening. > > > > I realised that there are some very useful functions not exported > > from Cairo. That's a pity since there's one function that allows > you > > to load an image as a surface without using it immediately. I've > > added the appropriate import to your file. > > > > > 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. > > > > I think it's not really necessary since most information can be > > obtained by adding putStrLn statements. > > > > Hope it helps a bit, > > Axel. > > > 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...>, gtk2hs- > > > us...@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. > > > > > > > > > ---------------------------------------------------------------------- > > > --- > > > This SF.Net email is sponsored by the Moblin Your Move > Developer's > > > challenge > > > Build the coolest Linux based applications with Moblin SDK & win > > > great prizes > > > Grand prize is a trip for two to an Open Source event anywhere in > > > the world > > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > _______________________________________________ > > > Gtk2hs-users mailing list > > > Gtk...@li... > > > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users > > > > > > > ---------------------------------------------------------------------- > --- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Gtk2hs-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users > |