www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - gtkD: How to paint to screen for animation

reply Michelle Long <HappyDance321 gmail.com> writes:
I've added a function to addOnDraw for a DrawingArea and it 
paints using the code I have when I resize.

I added a queueDraw in threadsAddIdle and it seems to draws the 
screen immediately but it does not seem to be called again.

If I put queueDraw inside the addOnDraw routine then the 
animation works but it is quite slow, about 1 fps and cpu usage 
is 100% without it, it is 0%.
Mar 18
next sibling parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Tuesday, 19 March 2019 at 00:54:34 UTC, Michelle Long wrote:
 I've added a function to addOnDraw for a DrawingArea and it 
 paints using the code I have when I resize.

 I added a queueDraw in threadsAddIdle and it seems to draws the 
 screen immediately but it does not seem to be called again.

 If I put queueDraw inside the addOnDraw routine then the 
 animation works but it is quite slow, about 1 fps and cpu usage 
 is 100% without it, it is 0%.
I haven't dug into this stuff yet for my blog, but I have sourced some references. Here's one that may help: https://www.cairographics.org/threaded_animation_with_cairo/
Mar 19
parent Michelle Long <HappyDance321 gmail.com> writes:
On Tuesday, 19 March 2019 at 15:33:19 UTC, Ron Tarrant wrote:
 On Tuesday, 19 March 2019 at 00:54:34 UTC, Michelle Long wrote:
 I've added a function to addOnDraw for a DrawingArea and it 
 paints using the code I have when I resize.

 I added a queueDraw in threadsAddIdle and it seems to draws 
 the screen immediately but it does not seem to be called again.

 If I put queueDraw inside the addOnDraw routine then the 
 animation works but it is quite slow, about 1 fps and cpu 
 usage is 100% without it, it is 0%.
I haven't dug into this stuff yet for my blog, but I have sourced some references. Here's one that may help: https://www.cairographics.org/threaded_animation_with_cairo/
Not really what I'm after(maybe later). Seems the code was running quite fast but I thought it should have displayed the results faster
Mar 21
prev sibling parent reply Mike Wey <mike-wey example.com> writes:
On 19-03-2019 01:54, Michelle Long wrote:
 I've added a function to addOnDraw for a DrawingArea and it paints using 
 the code I have when I resize.
 
 I added a queueDraw in threadsAddIdle and it seems to draws the screen 
 immediately but it does not seem to be called again.
 
 If I put queueDraw inside the addOnDraw routine then the animation works 
 but it is quite slow, about 1 fps and cpu usage is 100% without it, it 
 is 0%.
You will probably want to use glib.Timeout to make the time between redraws consistent. The callBack for treadsAddIdle or glib.Idle is only called when the mainloop has nothing else to do. The cairo clock demo is a good example: https://github.com/gtkd-developers/GtkD/blob/master/demos/cairo/cairo_clock/clock.d If performance is an issue one option would be to save your context in a cairo surface and only redraw the parts that have changed. -- Mike Wey
Mar 19
next sibling parent Michelle Long <HappyDance321 gmail.com> writes:
On Tuesday, 19 March 2019 at 19:03:37 UTC, Mike Wey wrote:
 On 19-03-2019 01:54, Michelle Long wrote:
 I've added a function to addOnDraw for a DrawingArea and it 
 paints using the code I have when I resize.
 
 I added a queueDraw in threadsAddIdle and it seems to draws 
 the screen immediately but it does not seem to be called again.
 
 If I put queueDraw inside the addOnDraw routine then the 
 animation works but it is quite slow, about 1 fps and cpu 
 usage is 100% without it, it is 0%.
You will probably want to use glib.Timeout to make the time between redraws consistent. The callBack for treadsAddIdle or glib.Idle is only called when the mainloop has nothing else to do. The cairo clock demo is a good example: https://github.com/gtkd-developers/GtkD/blob/master/demos/cairo/cairo_clock/clock.d If performance is an issue one option would be to save your context in a cairo surface and only redraw the parts that have changed.
I will try the clock code and see if threading it will help though. Just not sure if it's limited by cario or the thread. It seems that blitting the image is not the slow down because I removed the code and it still is slow, so it seems like it is a thread. setSourcePixbuf(buf, 0,0); paint(); Thanks.
Mar 19
prev sibling parent Michelle Long <HappyDance321 gmail.com> writes:
On Tuesday, 19 March 2019 at 19:03:37 UTC, Mike Wey wrote:
 On 19-03-2019 01:54, Michelle Long wrote:
 I've added a function to addOnDraw for a DrawingArea and it 
 paints using the code I have when I resize.
 
 I added a queueDraw in threadsAddIdle and it seems to draws 
 the screen immediately but it does not seem to be called again.
 
 If I put queueDraw inside the addOnDraw routine then the 
 animation works but it is quite slow, about 1 fps and cpu 
 usage is 100% without it, it is 0%.
You will probably want to use glib.Timeout to make the time between redraws consistent. The callBack for treadsAddIdle or glib.Idle is only called when the mainloop has nothing else to do. The cairo clock demo is a good example: https://github.com/gtkd-developers/GtkD/blob/master/demos/cairo/cairo_clock/clock.d If performance is an issue one option would be to save your context in a cairo surface and only redraw the parts that have changed.
This seems to be not any different than calling queueDraw inside AddOnDraw. I did the timing code and it does seem to say that I'm getting max 60fps so maybe it is quite fast. I was bitting an imagine and moving a rect across the screen at 1px per frame. I though it should be moving much faster but apparently my mental calculations are not all that great. 1680/60 ~= 28 so it should take nearly half a minute to move the rect from one side to the other. The behavior was essentially identical. I'm curious if the drawing routine itself uses Timeout to get 60fps and adding another timeout is only useful to regulate a slower fps?
Mar 21