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%.

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/

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

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.

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?

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