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 2019
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 2019
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 2019
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 2019
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 2019
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 2019