Re: deprecated gtk_cairo_create

[Jim Charlton]

On 2017-01-06 06:20 AM, Sergei Kolomeeyets wrote:

Hi, Emmanuele
thanks for your help in last days of last year. Well, in the
attachment there are codes of the (perhaps) simplest usage of Drawing
Area widget. It goes without gdk_window_create_similar_surface.

I'd like to summarize several ideas mentioned in "the deprecated
gtk_cairo_create()" thread.

1. On-screen drawing in Drawing Area against GTK+3 is much more easy
than in GTK+2. But this simplification has been achieved by
significant changes in API. In particular, the GtkWidget::draw signal
is quite different from GtkWidget::expose in GTK+2. GtkWidget::draw
takes a cairo_t* as the second parameter, not a GdkEventExpose like
did ::expose.  And here one can have the Cairo context required. In
other words one SHOULD DO NOTHING to create a cairo context BECAUSE IT
HAS BEEN ALREADY CREATED BEFORE A DRAW EVENT EMISSION and put by GTK+3
as the second parameter of a draw event callback function. Don't
create it, don't destroy it, just use it!

/*a standard main, except a new type of signal, "draw"*/
gint
main ()
{
GtkWidget *window;  /* pointer to the app main window */
GtkWidget *area;

window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
area = gtk_drawing_area_new();

gtk_widget_add_events(window,...);
gtk_widget_add_events(area,...);

g_signal_connect(G_OBJECT(area), "draw",
  G_CALLBACK(draw_callback),
  NULL);

g_signal_connect(G_OBJECT(area),
  "configure_event",
   G_CALLBACK(configure_callback),
   NULL);

gtk_container_add(GTK_CONTAINER(window), area);
gtk_widget_show_all(window);
gtk_main();

}
/*-*/
gboolean
draw_callback (GtkWidget *widget, cairo_t *cr)
{
GtkStyleContext *context;
context = gtk_widget_get_style_context (widget);
 // do your own drawing
}

It is sobering to be informed that the API reference is generated via
gtk-doc, which queries the type for signals and properties using the
GType API; Cairo provides GType wrappers for property and signal
marshalling, and those have CamelCase names to better fit in. This
means that a C `cairo_t` type is a `CairoContext` GType, and a
`cairo_surface_t` C type is a `CairoSurface` GType.


2. If you want to draw outside of the ::draw() handler and paint the
cached thing then, use a cairo_surface_t as the offscreen surface, and
paint on it then. You either create your own Cairo surface, or you ask
GDK to create a similar surface (or similar image surface) to the one
used by the GdkWindow that is the target of the rendering. Then, you
call 'cairo_create()` to get a Cairo context. The latter is possible
as cairo_create () is still not deprecated, but only
gtk_cairo_create() is.

GdkWindow *window = gtk_widget_get_window (widget);
cairo_surface_t *surface = gdk_window_create_similar_surface (window,
CAIRO_CONTENT_COLOR_ALPHA, width, height);

/* then create a Cairo context from it, and draw:*/

   cairo_t *cr = cairo_create (surface);
   // draw
   cairo_destroy (cr);

/* Now you can use the surface as a source on the Cairo context that
GtkWIdget::draw gives you:*/

   static gboolean
   on_draw (GtkWidget *widget, cairo_t *cr)
   {
 // render your surface on the widget's context
 cairo_set_source_surface (cr, surface, x, y);
 cairo_paint (cr);

 // do your own drawing
   }

3. But reasons (except compatibility) for such a way of drawing are
*now* a bit hazy, taking into account your comment :"creating an
intermediate surface on configure-event (something that's there only
for backward compatibility with GTK+ 1.2, and it's an X11-ism) just to
source it again is much more expensive than drawing on the provided
Cairo context".  The obvious reason was to pack all redrawing
procedures hooked to configure_event into a special drawing function
and put it into configure call-back function. Configure event happens
much less often than draw event. So there is a hope to be more
efficient...  One could find additional discussions with almost the
same context here
https://lists.cairographics.org/archives/cairo/2007-December/012211.html
and here 
https://lists.cairographics.org/archives/cairo/2007-December/012211.html.
For example, when I draw a dynamic figure with complex axes (with
sophisticated ticks' marks and other elements) why should I draw them
(axes) every time I redraw the main line? It's definitely a good idea
to gather all codes of axes drawing into special function and put it
into a configure event handler. What do you recommend that I do now
(if "off-screen' drawing is much more expensive and in general is a
very niche use cases)?

Regards,
Sergey

In Plotting code that I have edited and updated to Gtk3 and Gtkmm3, 
(Plotmm, https://github.com/charlton0

Re: deprecated gtk_cairo_create

[Sergei Kolomeeyets]

Hi, Emmanuele
thanks for your help in last days of last year. Well, in the
attachment there are codes of the (perhaps) simplest usage of Drawing
Area widget. It goes without gdk_window_create_similar_surface.

I'd like to summarize several ideas mentioned in "the deprecated
gtk_cairo_create()" thread.

1. On-screen drawing in Drawing Area against GTK+3 is much more easy
than in GTK+2. But this simplification has been achieved by
significant changes in API. In particular, the GtkWidget::draw signal
is quite different from GtkWidget::expose in GTK+2. GtkWidget::draw
takes a cairo_t* as the second parameter, not a GdkEventExpose like
did ::expose.  And here one can have the Cairo context required. In
other words one SHOULD DO NOTHING to create a cairo context BECAUSE IT
HAS BEEN ALREADY CREATED BEFORE A DRAW EVENT EMISSION and put by GTK+3
as the second parameter of a draw event callback function. Don't
create it, don't destroy it, just use it!

/*a standard main, except a new type of signal, "draw"*/
gint
main ()
{
   GtkWidget *window;  /* pointer to the app main window */
   GtkWidget *area;

   window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
   area = gtk_drawing_area_new();

   gtk_widget_add_events(window,...);
   gtk_widget_add_events(area,...);

   g_signal_connect(G_OBJECT(area), "draw",
 G_CALLBACK(draw_callback),
 NULL);

   g_signal_connect(G_OBJECT(area),
 "configure_event",
  G_CALLBACK(configure_callback),
  NULL);

   gtk_container_add(GTK_CONTAINER(window), area);
   gtk_widget_show_all(window);
   gtk_main();

}
/*-*/
gboolean
draw_callback (GtkWidget *widget, cairo_t *cr)
{
   GtkStyleContext *context;
   context = gtk_widget_get_style_context (widget);
// do your own drawing
}

It is sobering to be informed that the API reference is generated via
gtk-doc, which queries the type for signals and properties using the
GType API; Cairo provides GType wrappers for property and signal
marshalling, and those have CamelCase names to better fit in. This
means that a C `cairo_t` type is a `CairoContext` GType, and a
`cairo_surface_t` C type is a `CairoSurface` GType.


2. If you want to draw outside of the ::draw() handler and paint the
cached thing then, use a cairo_surface_t as the offscreen surface, and
paint on it then. You either create your own Cairo surface, or you ask
GDK to create a similar surface (or similar image surface) to the one
used by the GdkWindow that is the target of the rendering. Then, you
call 'cairo_create()` to get a Cairo context. The latter is possible
as cairo_create () is still not deprecated, but only
gtk_cairo_create() is.

GdkWindow *window = gtk_widget_get_window (widget);
cairo_surface_t *surface = gdk_window_create_similar_surface (window,
CAIRO_CONTENT_COLOR_ALPHA, width, height);

/* then create a Cairo context from it, and draw:*/

  cairo_t *cr = cairo_create (surface);
  // draw
  cairo_destroy (cr);

/* Now you can use the surface as a source on the Cairo context that
GtkWIdget::draw gives you:*/

  static gboolean
  on_draw (GtkWidget *widget, cairo_t *cr)
  {
// render your surface on the widget's context
cairo_set_source_surface (cr, surface, x, y);
cairo_paint (cr);

// do your own drawing
  }

3. But reasons (except compatibility) for such a way of drawing are
*now* a bit hazy, taking into account your comment :"creating an
intermediate surface on configure-event (something that's there only
for backward compatibility with GTK+ 1.2, and it's an X11-ism) just to
source it again is much more expensive than drawing on the provided
Cairo context".  The obvious reason was to pack all redrawing
procedures hooked to configure_event into a special drawing function
and put it into configure call-back function. Configure event happens
much less often than draw event. So there is a hope to be more
efficient...  One could find additional discussions with almost the
same context here
https://lists.cairographics.org/archives/cairo/2007-December/012211.html
and here 
https://lists.cairographics.org/archives/cairo/2007-December/012211.html.
For example, when I draw a dynamic figure with complex axes (with
sophisticated ticks' marks and other elements) why should I draw them
(axes) every time I redraw the main line? It's definitely a good idea
to gather all codes of axes drawing into special function and put it
into a configure event handler. What do you recommend that I do now
(if "off-screen' drawing is much more expensive and in general is a
very niche use cases)?

Regards,
Sergey







2016-12-30 18:15 GMT+03:00 Sergei Kolomeeyets <kolomeey...@gmail.com>:
> Hi, Emmanuele
> thanks for not leaving me alone with my first attemts to navigate through
> 'uncharted' w

Re: deprecated gtk_cairo_create

[rbd]

On Fri, 30 Dec 2016, cecas...@aol.com wrote:


Hi Roger,

Would this be similar to using a GtkLayout and a GtkDrawingArea? If you add
a drawing area to a layout you get draw scrolling and the layout can update
the part of the drawing area shown on the screen even though the drawing
might be on a larger area.

Eric


Hi Eric,

Actually yes, I put my drawing area inside a layout inside a scrolled 
window inside a toplevel window. I wouldn't be surprised if there were a 
half-dozen better ways to the same end, but I got this to work for me and 
I'm stickin' with it 'til it breaks. ;-> The outer layers (layout through 
toplevel) actually constitute another principal object type of my toolkit 
(a Frame) which is used to encapsulate other non-Canvas objects such as 
large dialog panels and textwindows. Seemed like an easy way to make all 
of my toplevels downsizable and scrollable.


Roger
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: deprecated gtk_cairo_create

[Eric Cashon via gtk-app-devel-list]

Hi Roger,

Would this be similar to using a GtkLayout and a GtkDrawingArea? If you add a 
drawing area to a layout you get draw scrolling and the layout can update the 
part of the drawing area shown on the screen even though the drawing might be 
on a larger area.

Eric

 

 

 

-Original Message-
From: rbd <r...@soest.hawaii.edu>
To: gtk-app-devel-list <gtk-app-devel-list@gnome.org>
Sent: Fri, Dec 30, 2016 12:24 pm
Subject: Re: deprecated gtk_cairo_create

Hello Sergei,

Unfortunately the use of the gtk3 DrawingArea is a bit obscure and 
difficult to figure out. However, I have been able to make use of it very 
effectively in conjunction with Cairo drawing ops.

For various reasons I have created a GUI toolkit library which lies 
between my app code and gtk3. This library includes an object known as a 
Canvas, which is essentially a toplevel window with scrollbars parenting a 
DrawingArea. The Canvas object includes a private off-screen Cairo drawing 
surface which I create and control completely, and I do all of my 
application drawing onto that surface. Then, I use the gtk3 draw signal 
mechanism to copy whatever recatngular areas I want from my private 
surface onto the DrawingArea. gtk3 passes to my drawing event handler a 
pointer to a Cairo context which addresses the DrawingArea's own Cairo 
surface, so all I need to do in the draw event handler is set a source 
surface on that context (in my case, the source surface is my own private 
Cairo surface), and copy a rectangle. As far as I know there is no safe 
way to access the Cairo surface of a gtk3 DrawingArea other than through 
the Cairo context pointer passed into the drawing event handler.

Following is some incomplete, stripped down code which may help to explain 
the above ideas. I hope this helps!

Roger Davis
Univ. of Hawaii

# code follows ###

/* Here are the relevant parts of the Canvas structure */
typedef struct {
 ...
 GtkWidget *drawarea;/* created by gtk_drawing_area_new() */
 int width, height;  /* size of DrawingArea */
 cairo_surface_t *surface; /* my private Cairo surface */
 ...
} Canvas;

gboolean
canvasdrawevt(GtkWidget *w, cairo_t *cr, gpointer gp)
/*
This internal routine handles draw signals sent by GTK+3 to a Canvas'
GtkDrawingArea widget. These signals will typically be generated by
expose events or by program calls to gtk_widget_queue_draw_area()
generated from within canvasflushregion(). This routine merely copies
the rectangle(s) of interest from the off-screen Cairo drawing surface
of the canvas into the actual GtkDrawingArea widget.
*/
{
 Canvas *c;

 if (gp == (gpointer) 0)
return FALSE;
 c= (Canvas *) gp;
 if (w != c->drawarea)
  return FALSE;

 /* here I set the source to my private
surface which I have already drawn */
 cairo_set_source_surface(cr, c->surface, 0, 0);

 /* note that according to various (and occasionally obscure)
GTK+3 docs, the context cr passed into this routine has
already been clipped to any exposed rectangle(s) of interest
(or whatever canvasflush{reg}() has marked for redraw via
its call to gtk_widget_queue_draw_area()), so the following
   call to copy the whole drawing surface is not as expensive
as it looks! */
 cairo_rectangle(cr, 0, 0, (double) c->width, (double) c->height);
 cairo_fill(cr);

 return TRUE;
}

/* Here is how the important parts of the Canvas are created ... */

Canvas *
canvascreate(gint width, gint height, ... )
{
 Canvas *c;
 int i;
 GtkWidget *win, *lo, *sw;
 GdkGeometry geom;

   if ((c= (Canvas *) calloc((MemSizeType) 1, sizeof(Canvas))) == (Canvas 
*) 0)
   return (Canvas *) 0;

 ...

 /* create the DrawingArea */
  c->width= width;
 c->height= height;
 if ((c->drawarea= gtk_drawing_area_new()) == (GtkWidget *) 0) {
 canvasdestroy(c);
 return (Canvas *) 0;
 }
 gtk_widget_set_size_request(c->drawarea, width, height);
 gtk_widget_set_can_focus(c->drawarea, TRUE);
 ...

 /* attach the drawing event handler */
 g_signal_connect((gpointer) c->drawarea, "draw", 
G_CALLBACK(canvasdrawevt), (gpointer) c);
 ...

 /* create our private Cairo surface on which we will draw
everything */
 if ((c->surface= cairo_image_surface_create(CAIRO_FORMAT_ARGB32, (int) 
width, (int) height)) == (cairo_surface_t *) 0) {
 canvasdestroy(c);
 return (GITCanvas *) 0;
 }
...

 return c;
}

/* Call this routine to copy our private Cairo surface to the DrawingArea
whenever we want (i.e., after we have done all our drawing into the
form

Re: deprecated gtk_cairo_create

[rbd]

Hello Sergei,

Unfortunately the use of the gtk3 DrawingArea is a bit obscure and 
difficult to figure out. However, I have been able to make use of it very 
effectively in conjunction with Cairo drawing ops.


For various reasons I have created a GUI toolkit library which lies 
between my app code and gtk3. This library includes an object known as a 
Canvas, which is essentially a toplevel window with scrollbars parenting a 
DrawingArea. The Canvas object includes a private off-screen Cairo drawing 
surface which I create and control completely, and I do all of my 
application drawing onto that surface. Then, I use the gtk3 draw signal 
mechanism to copy whatever recatngular areas I want from my private 
surface onto the DrawingArea. gtk3 passes to my drawing event handler a 
pointer to a Cairo context which addresses the DrawingArea's own Cairo 
surface, so all I need to do in the draw event handler is set a source 
surface on that context (in my case, the source surface is my own private 
Cairo surface), and copy a rectangle. As far as I know there is no safe 
way to access the Cairo surface of a gtk3 DrawingArea other than through 
the Cairo context pointer passed into the drawing event handler.


Following is some incomplete, stripped down code which may help to explain 
the above ideas. I hope this helps!


Roger Davis
Univ. of Hawaii

# code follows ###

/* Here are the relevant parts of the Canvas structure */
typedef struct {
...
GtkWidget *drawarea;/* created by gtk_drawing_area_new() */
int width, height;  /* size of DrawingArea */
cairo_surface_t *surface; /* my private Cairo surface */
...
} Canvas;

gboolean
canvasdrawevt(GtkWidget *w, cairo_t *cr, gpointer gp)
/*
   This internal routine handles draw signals sent by GTK+3 to a Canvas'
   GtkDrawingArea widget. These signals will typically be generated by
   expose events or by program calls to gtk_widget_queue_draw_area()
   generated from within canvasflushregion(). This routine merely copies
   the rectangle(s) of interest from the off-screen Cairo drawing surface
   of the canvas into the actual GtkDrawingArea widget.
*/
{
Canvas *c;

if (gp == (gpointer) 0)
return FALSE;
c= (Canvas *) gp;
if (w != c->drawarea)
return FALSE;

/* here I set the source to my private
   surface which I have already drawn */
cairo_set_source_surface(cr, c->surface, 0, 0);

/* note that according to various (and occasionally obscure)
   GTK+3 docs, the context cr passed into this routine has
   already been clipped to any exposed rectangle(s) of interest
   (or whatever canvasflush{reg}() has marked for redraw via
   its call to gtk_widget_queue_draw_area()), so the following
   call to copy the whole drawing surface is not as expensive
   as it looks! */
cairo_rectangle(cr, 0, 0, (double) c->width, (double) c->height);
cairo_fill(cr);

return TRUE;
}

/* Here is how the important parts of the Canvas are created ... */

Canvas *
canvascreate(gint width, gint height, ... )
{
Canvas *c;
int i;
GtkWidget *win, *lo, *sw;
GdkGeometry geom;

if ((c= (Canvas *) calloc((MemSizeType) 1, sizeof(Canvas))) == (Canvas 
*) 0)
return (Canvas *) 0;

...

/* create the DrawingArea */
c->width= width;
c->height= height;
if ((c->drawarea= gtk_drawing_area_new()) == (GtkWidget *) 0) {
canvasdestroy(c);
return (Canvas *) 0;
}
gtk_widget_set_size_request(c->drawarea, width, height);
gtk_widget_set_can_focus(c->drawarea, TRUE);
...

/* attach the drawing event handler */
g_signal_connect((gpointer) c->drawarea, "draw", 
G_CALLBACK(canvasdrawevt), (gpointer) c);
...

/* create our private Cairo surface on which we will draw
   everything */
if ((c->surface= cairo_image_surface_create(CAIRO_FORMAT_ARGB32, (int) 
width, (int) height)) == (cairo_surface_t *) 0) {
canvasdestroy(c);
return (GITCanvas *) 0;
}
...

return c;
}

/* Call this routine to copy our private Cairo surface to the DrawingArea
   whenever we want (i.e., after we have done all our drawing into the
   former).  A call to this routine will result in our drawing event
   handler above being called asynchronously at some later time (but
   probably just about immediately). */
void
canvasflushregion(Canvas *c, int x0, int x1, int y0, int y1)
{
unsigned int w, h;

/* my real code checks x0/x1/y0/y1 for
   correctness before proceeding! */
...

w= (unsigned int) (x1-x0+1);
h= (unsigned int) (y1-y0+1);

/* the following call will result in GTK+3/GDK sending a draw
   signal 

Re: deprecated gtk_cairo_create

[Emmanuele Bassi]

Hi;

On 30 December 2016 at 13:45, Colomban Wendling
 wrote:

> [1] which says "CairoContext", but that's a weird lie on the API… not
> sure why, maybe the GType has this name so introspection is confused.
> Anyway, it's cairo_t.

The API reference is generated via gtk-doc, which queries the type for
signals and properties using the GType API; Cairo provides GType
wrappers for property and signal marshalling, and those have CamelCase
names to better fit in. This means that a C `cairo_t` type is a
`CairoContext` GType, and a `cairo_surface_t` C type is a
`CairoSurface` GType.

It should be possible to override the type inside gtk-doc, but nobody
looked into it as of yet.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: deprecated gtk_cairo_create

[Emmanuele Bassi]

Hi;

On 30 December 2016 at 17:25, Jim Charlton  wrote:

> If one does want to draw into a cairo_surface_t, one can create a cairo
> context for drawing? E.g.

Yes, that's the expected approach.

You either create your own Cairo surface, or you ask GDK to create a
similar surface (or similar image surface) to the one used by the
GdkWindow that is the target of the rendering. Then, you call
`cairo_create()` to get a Cairo context.

> cairo_t   *
> cairo_create (/|cairo_surface_t
> 
> *target|/);
>
> That use of cairo_create() is not deprecated... (I assume).

Indeed, it's not deprecated.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: deprecated gtk_cairo_create

[Colomban Wendling]

Le 30/12/2016 à 18:25, Jim Charlton a écrit :
> If one does want to draw into a cairo_surface_t, one can create a cairo
> context for drawing? E.g.
> 
> cairo_t   *
> cairo_create (/|cairo_surface_t
> 
> *target|/);
> 
> That use of cairo_create() is not deprecated... (I assume).

cairo_create() is not deprecated, only gdk_cairo_create() is.
And yeah, that use is perfectly valid and fine.

Regards,
Colomban
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: deprecated gtk_cairo_create

[Jim Charlton]

On 2016-12-30 05:45 AM, Colomban Wendling wrote:

Hi,

Le 30/12/2016 à 12:20, Sergei Kolomeeyets a écrit :

Hi, everyone
[…]

{draw_callback}

gboolean draw_callback(GtkWidget *area, GdkEventExpose *event, GArray
*ptLinePoints) {

That's not the right signature for the GtkWidget::draw signal: it takes
a cairo_t* as the second parameter, not a GdkEventExpose like did
::expose.  And here you have your Cairo context :)

See
https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget-draw [1]

Also, read
https://developer.gnome.org/gtk3/stable/ch26s02.html#id-1.6.3.4.11, and
more generally
https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html

So basically you don't need gdk_cairo_create() at all.  If you want to
draw outside of the ::draw() handler and paint the cached thing then,
use a cairo_surface_t as the offscreen surface, and paint it then.

Hope this helps.

Cheers,
Colomban

[1] which says "CairoContext", but that's a weird lie on the API… not
sure why, maybe the GType has this name so introspection is confused.
Anyway, it's cairo_t.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


If one does want to draw into a cairo_surface_t, one can create a cairo 
context for drawing? E.g.


cairo_t   *
cairo_create (/|cairo_surface_t 
 
*target|/);


That use of cairo_create() is not deprecated... (I assume).

https://developer.gnome.org/gtk3/stable/ch01s05.html

jim...




___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: deprecated gtk_cairo_create

[Colomban Wendling]

Le 30/12/2016 à 15:09, Sergei Kolomeeyets a écrit :
> Hi, Colomban
> Thanks a lot for you hint! I realised the idea of wrong event hanling.
> Do you mean that I SHOULD DO NOTHING to create a cairo context BECAUSE
> IT IS in the draw event callback function obligatory parameters? And, if
> yes, I could think as if GTK+ itself prepares it for me BEFORE emmit
> that event?

Yes, GTK prepares it for you.  Don't create it, don't destroy it, just
use it.

> Thanks again and Happy New Year!

Thanks, to you too!

Regards,
Colomban
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: deprecated gtk_cairo_create

[Colomban Wendling]

Hi,

Le 30/12/2016 à 12:20, Sergei Kolomeeyets a écrit :
> Hi, everyone
> […]
>
> {draw_callback}
> 
> gboolean draw_callback(GtkWidget *area, GdkEventExpose *event, GArray
> *ptLinePoints) {

That's not the right signature for the GtkWidget::draw signal: it takes
a cairo_t* as the second parameter, not a GdkEventExpose like did
::expose.  And here you have your Cairo context :)

See
https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget-draw [1]

Also, read
https://developer.gnome.org/gtk3/stable/ch26s02.html#id-1.6.3.4.11, and
more generally
https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html

So basically you don't need gdk_cairo_create() at all.  If you want to
draw outside of the ::draw() handler and paint the cached thing then,
use a cairo_surface_t as the offscreen surface, and paint it then.

Hope this helps.

Cheers,
Colomban

[1] which says "CairoContext", but that's a weird lie on the API… not
sure why, maybe the GType has this name so introspection is confused.
Anyway, it's cairo_t.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

deprecated gtk_cairo_create

[Sergei Kolomeeyets]

Hi, everyone
I'm struggling with migration from gtk2. Well gtk_cairo_create is
deprecated in gtk3. And it looks  the changes are very serious (or I'm sach
silly that even do not understand what should I do instead of it ). Is
there anybody who use Drawing Area in GTK3 and can explain the right way of
its cairo context creation and drawing on it to me. It would be so
appreciated.

Documentation says the following:
***gtk_cairo_create
gdk_cairo_create has been deprecated since version 3.22 and should not be
used in newly-written code. Use gdk_window_begin_draw_frame()

and gdk_drawing_context_get_cairo_context()

instead.

***gdk_window_begin_draw_frame
[bla-bla-bla...] When using GTK+, the widget system automatically places
calls to gdk_window_begin_draw_frame()

and gdk_window_end_draw_frame()

around emissions of the GtkWidget::draw signal. That is, if you’re drawing
the contents of the widget yourself, you can assume that the widget has a
cleared background, is already set as the clip region, and already has a
backing store. Therefore in most cases, application code in GTK does not
need to call gdk_window_begin_draw_frame()

explicitly.

I use GTK+, so I can forget about gdk_window_begin_draw_frame for some
time. Right?
And there is only gdk_drawing_context_get_cairo_context in the rest of
options. So I write the following:

{main}
...
/*Drawing area and text_entry at the bottom of it */
area = gtk_drawing_area_new();
text_entry = gtk_entry_new();
vbox = gtk_vbox_new (FALSE, 0);

gtk_box_pack_start(vbox, area, TRUE, TRUE, 0);
gtk_box_pack_start(vbox, text_entry,  FALSE, FALSE, 0);

gtk_container_add(GTK_CONTAINER(window), vbox);
gtk_widget_show_all(window);
gtk_main();
...

{draw_callback}

gboolean draw_callback(GtkWidget *area, GdkEventExpose *event, GArray
*ptLinePoints) {
...
cairo_t *cr = gdk_drawing_context_get_cairo_context (area);
...
}

But linker (gcc package) writes  "undefined reference to
`gdk_drawing_context_get_cairo_context"... :-(
Everything indicated that I missed several lines of code before
gdk_drawing_context_get_cairo_context. But what lines exactly? Googling
gives nothing...

Is there anybody who use Drawing Area in GTK3 and can explain the right way
of its cairo context creation and drawing on it to me. It would be so
appreciated.

Thanks in advance!

Best Regards, (and Happy New Year for everyone here!!!)
Sergey.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list