Re: getting an image from gtkdrawingarea

["Paul Davis" <pjdavis engineering uiowa edu>]

Michael,

If you go the route of rendering to a pixmap, there's no real need to have more than one expose method.

All you need to do is run your animation as you need it, then queue a redraw for the drawing area.

Basically, rendering everyting to a pixmap gives you the ability to
render to it as you please, and then schedule a redraw as you want
updates.

Paul

On 9/25/06, Michael L. Gualtieri <mikeg cs pitt edu> wrote:

Thanks for both the replies.  They have given me some good ideas.

Paul,
When I was putting together a small example I realised I wasn't having the same problems that I have in my big app.  I was assuming the problem was scale beforehand.

Richard,
I realised that my expose event was actually being bogged down with some extraneous code that I was able to optimize.  This has helped out a lot with the speed (I can't believe I didn't realise this earlier).

I still think the speed could improve however, since sometimes I do see the grey bg.  Your idea of drawing to a pixmap is a good one, one I didn't think I could do before.  After looking at the cairo API some more I discovered the call cairo_xlib_surface_create_for_bitmap().  I haven't messed with it yet, but it looks like I can use this to draw to a pixmap.

BTW - I do have an animation but it is controlled by the user, so there is no need to animate when it isn't being displayed, which reduces some of the complexity.  I also know when I need to animate and when I don't, so it would be possible to use a regular and optimized draw function if necessary.


Mike

--

On 9/25/06, Richard Boaz < riboaz xs4all nl> wrote:

Hi,

I'm a bit confused about some things in your original post and so don't
really know what's going on to be of precise help, but some thoughts
nonetheless:

1) the speed of the expose event, whether for a GtkImage or a
GtkDrawingArea, is a function of how much code must be executed as part of
the expose event itself, not a function of the type of widget displaying
the image.  In other words, I do not think your proposed solution is the
correct one.

2) when you say the background of the drawing area is displayed when
covered and then uncovered, why is this the case?  the expose event should
re-render the display area to contain the whole image currently displayed
there.  Meaning, I'm not convinced the problem is fully understood quite
yet, and unless the problem is correctly understood, searching for a
solution can only make things more confusing (and wronger) in the long
run.

One way of achieving the effect you want (while also guaranteeing quick
re-drawing of uncovered display areas, of whatever type) is to do no real
drawing in the expose event itself.
You achieve this by doing all drawing commands to a pixmap (generated from
within the configure event and/or explicit events, either internally- or
user-generated), and not to the screen.

The expose event should contain only one drawing command, namely,
gdk_draw_drawable(), responsible for rendering the pixmap to the screen.
This way, all expose events will immediately render the image to the
screen, leaving no display background to be seen.

You say you have an animation, which may necessarily complicate matters,
though conceptually nothing changes.  But, to that end, is your program
constructed such that the animation still occurs even when the display
area is partially or fully covered?  Is the user responsible for turning
it on and off or is it simply always 'on'?

Basically, if you manage an internal pixmap holding the current image to
be displayed, you can achieve what you require without all the gymnastics
of managing different types of display widgets depending on context; a
solution which should be avoided where possible.

cheers,

richard

> Hi all,
>
> I'm still stuck on this issue.  The previous post was my first to the
> list,
> so if I need to give extra info or add anything to the post I'd be happy
> to
> do so.
>
> Thanks
>
>
> On 9/22/06, Michael L. Gualtieri <mikeg cs pitt edu > wrote:
>>
>> I'm writing an app that has several cairo animations inside
>> gtkdrawingareas.  Unfortunately, everytime the window is covered and
>> uncovered the expose events show the ugly grey background of the drawing
>> area instead of my nice cairo surface.
>>
>> I have noticed that GtkImages expose much quicker than a GtkDrawingArea.
>> Is there a way to convert the contents of a gtkdrawingarea to a GtkImage
>> or
>> other type that is easily drawable on the screen?
>>
>> My idea is that I can draw an image of the drawing area while it is
>> static, and then when I need to animate it, I will replace it back with
>> the
>> drawing area.
>>
>> Thanks!
>>
>>
> _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>

_______________________________________________
gtk-list mailing list
gtk-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-list