Re: surface

[control H <control h gmail com>]

On Mon, Jun 20, 2011 at 9:36 PM, Damon Chaplin
<damon karuna eclipse co uk> wrote:
> On Mon, 2011-06-20 at 15:10 +0100, Damon Chaplin wrote:
>> On Mon, 2011-06-20 at 15:42 +0200, control H wrote:
>> > I have successfully made new canvas items, all subclassed from simple
>> > item. One of these items has a fairly complex way of drawing in the
>> > paint method as it is depending on external data. So I wonder whether
>> > I can speed up the drawing a bit by rendering to a separate surface.
>> > When the bounds change ie the update method is called, I schedule a
>> > full redraw in the paint method. Otherwise I prefer to paint the
>> > already existing surface back to the cairo_t. For example in case part
>> > of the canvas has been covered by another window.
>> >
>> > Is the best way to create a surface myself and then paint the surface
>> > onto the cairo_t? Or can I use cairo_get_target to get the surface?
>> > How does goocanvas work internally, will a canvas item have the same
>> > cairo_t and surface as long as the item exists? Or can they be
>> > different each time the update, paint etc. is called? I have looked in
>> > the source code but could not find out easily.
>>
>> GooCanvas just uses the cairo_t passed to it from GTK+. I don't think
>> that is guaranteed to be the same between calls.
>>
>> I think creating your own image surface and drawing to that would be
>> best. Then copy that to the window in paint().
>
> Actually this is slightly wrong - GooCanvas uses gdk_cairo_create() to
> create the cairo context. The docs for gdk_cairo_create() say you
> shouldn't cache/reuse the context.
>
> So the advice remains the same - use your own image surface and paint
> that.
>
> Damon
>
>
>

OK thanks for the advice. I have implemented it with an own surface
which works fine. However, I noted that when I save the whole canvas
as a pdf like in the demo, somehow the item gets rendered as a picture
inside the pdf instead of something scalable. In addition, the text
that is rendered inside that item is not selectable in the pdf which
kind of shows it's no text anymore but a picture. I don't know whether
this can be a side effect of using a intermediate surface on my own. I
would say it should not make any difference.

One more question: what is the exact idea of having a root item on the
canvas? I have been experimenting a bit with it; I set the root item
to be my new subclassed item. But this results in a seg fault:

#0  goo_canvas_item_request_update (item=<value optimized out>)
    at goocanvasitem.c:1512
#1  0x00007fbcd98567f5 in goo_canvas_item_simple_changed (item=0x1cadf40,
    recompute_bounds=<value optimized out>) at goocanvasitemsimple.c:868

May I conclude a root item needs to satisfy specific conditions? In my
application I draw the complex item which is spanning the whole
canvas, and all other items should be on top of it.

Thanks for you help again.
regards,
CH