date:20110723

GdkDrawable from GtkDrawingArea and it's cairo surface

2011-07-23 Thread Carlos López Camey

Hello again,

Let's say I'd like to save a GtkDrawingArea 'screenshot' to a file.
I'm able to do

cairo_t *cr = gtkDrawingAreaWidget->window;
cairo_surface_t *screenshot = cairo_get_target(cr);
cairo_surface_write_to_png(screenshot,"screenshot.png");

but what this code does is save a screenshot for the *entire window*,
including other widgets in it (e.g. toolbar). I can't get a cairo
context for a GtkDrawingArea since it's not GdkDrawable, and it's not
possible to have child GtkWindow. I've seen
gtk_widget_set_has_window() but it didn't work, I think because it
says "This function should only be called by widget implementations".
Is there a work-around?

What I'm really trying to do: Save my drawing area surface everytime
it's modified (drawn on it), so I can later do "undos" and set the
surface source to a previous one.

Thanks,
Carlos
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: Is GTK+ 3.x 2x slower than GTK+ 2.x?

2011-07-23 Thread Sergei Steshenko



--- On Sat, 7/23/11, Jakub Misak  wrote:

> From: Jakub Misak 
> Subject: Is GTK+ 3.x 2x slower than GTK+ 2.x?
> To: gtk-list@gnome.org
> Date: Saturday, July 23, 2011, 12:30 PM
> 
> Is GTK+ 3.x 2x slower than GTK+ 2.x?
> 
> Hello,
> 
> When I upgraded to GTK+ 3.0, the first thing that struck me
> was how 
> sluggish it was compared to 2.24. The same dialogs in the
> same 
> application appear immediately on the screen in the 2x
> version, while 
> it takes time to paint them on the screen with the 3.x
> version. 
> Browsing through menus or switching between tabs consumed
> 2x or 3x more 
> CPU cycles in the 3.x version. The file open/save dialog is
> much slower 
> (slower to show up, slower to change directories). Or
> hovering over the 
> toolbuttons in 3.x-based Glade consumed 80% CPU cycles and
> the 
> highlighting could barely keep up with the mouse cursor.
> Application 
> startup is a bit slower with 3.x, too.
> 
> So I made a (very) simple and stupid benchmark that tests a
> couple of 
> basic things in a loop, to see how the two GTK+ versions
> compare. 
> If you're interested, you can download it here:
> 
> http://www.fileupyours.com/files/310686/perftest.tar.gz
> 
> (A simple "make" command should build both versions.)
> 
> I am testing it in xfwm4 with compositor turned off. If you
> test it in 
> a compositing WM with window effects (open/close),
> especially with 
> test #3 which opens/closes a dialog 50 times, it may
> measure something 
> else than GTK+ speed...
> 
> The default GTK+ theme (Raleigh) was used for both 2.24 and
> 3.0.11. 
> Both GTK+ 2.x and 3.x software was already running, so both
> library 
> versions were loaded in memory (so it was probably not an
> issue for the 
> startup speed).
> 
> The results from my 3GHz dual CPU desktop machine with the
> open-source 
> radeon driver (I ran each test 7 times and took the best
> result for each 
> test):
> 
> Startup, GTK+ 2: 0.11081 s, GTK+ 3: 0.14468 s
> Test 1, GTK+ 2:  4.34362 s, GTK+ 3: 8.83771 s
> Test 2, GTK+ 2:  1.72010 s, GTK+ 3: 2.33266 s
> Test 3, GTK+ 2:  2.27047 s, GTK+ 3: 4.79270 s
> 
> It's not just my computer, as I tried it on an HP 625
> laptop, again 
> using the radeon driver:
> 
> Startup, GTK+ 2: 0.09357 s, GTK+ 3: 0.13600 s
> Test 1, GTK+ 2:  3.27795 s, GTK+ 3: 5.20183 s
> Test 2, GTK+ 2:  1.47700 s, GTK+ 3: 1.46733 s
> Test 3, GTK+ 2:  1.35302 s, GTK+ 3: 5.14810 s
> 
> It's not the radeon driver either, as I tried it with the
> proprietary 
> fglrx driver, too:
> 
> Startup, GTK+ 2: 0.09058 s, GTK+ 3: 0.13770 s
> Test 1, GTK+ 2:  2.42151 s, GTK+ 3: 6.67091 s
> Test 2, GTK+ 2:  1.15294 s, GTK+ 3: 1.44557 s
> Test 3, GTK+ 2:  1.31779 s, GTK+ 3: 4.64865 s
> 
> It's probably not the default theme either. First, the
> default themes 
> look very similar in both versions. Second, test 2 does not
> seem to be 
> influenced by the GTK+ version too much. Third, when I use
> slow fancy 
> themes in both GTK+ versions (Victory, Adwaita, New
> Wave...), I still 
> get the same pattern again - even though a fancy theme
> makes both 
> versions (sometimes even 6x) slower, 3.x is still 50-150%
> slower than 
> 2.x (except for test 2, which seems to be mainly influenced
> by the 
> theme itself). And fourth, even a slow fancy GTK+ 2.x theme
> is faster 
> than the plain default 3.x theme.
> 
> Finally, it's not my Linux distribution either. I ran the
> tests in 3 
> different distros (Arch Linux, LMDE and Fedora 15, with
> Xfce in all of 
> them), and always got similar results.
> 
> So my question is - is there something in GTK+ 3.0 that
> could possibly 
> cause such a dramatic slowdown compared to 2.24?
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
> 

File a bug.

Regards,
  Sergei.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: How to improve performance of this example?

2011-07-23 Thread Carlos López Camey

Thank you Richard, the code you wrote works for me and it gave me
ideas on how to re-structure mine.

2011/7/23 richard boaz :
> hi,
> the problem isn't the mouse going "too fast" (this is "not possible", if it
> can go fast, it can), it's that you're wanting to draw a line using points.
> drawing a real line between the last point received by the drag event and
> the new/next point will get you what you want, example code below.
> and to answer your question, yes it can be made more efficient.
> cheers,
> richard
> p.s. be careful re: your callback parameters, your drag function defined the
> 2nd argument wrong.
>  BEGIN CODE EXAMPLE 
> #include 
> #include 
> enum {
> MOUSE_CLICK,
> MOUSE_DRAG,
> TTL_MOUSE_EVENTS
> };
> static inline void brush(cairo_t *cr, double x1, double y1, double x2,
> double y2)
> {
> cairo_move_to(cr, x1, y1);
> cairo_line_to(cr, x2, y2);
> cairo_stroke(cr);
> }
> static gboolean handle_mouse(GtkWidget *widget, void *e, gpointer *t)
> {
> static struct {
> gboolean isdragging;
> cairo_t *cr;
> double x, y;
> } mouseState;
> gint type = GPOINTER_TO_INT(t);
> switch(type)
> {
> case MOUSE_CLICK:
> {
> GdkEventButton *event = (GdkEventButton*) e;
> switch(event->type)
> {
> case GDK_BUTTON_PRESS:
> {
> mouseState.isdragging = TRUE;
> mouseState.cr = gdk_cairo_create(widget->window);
> cairo_set_source_rgb(mouseState.cr, 0, 0, 0);
> cairo_set_line_width(mouseState.cr, 2);
> mouseState.x = event->x; mouseState.y = event->y;
> }
> break;
> case GDK_BUTTON_RELEASE:
> {
> cairo_destroy(mouseState.cr);
> memset(&mouseState, 0, sizeof(mouseState));
> }
> break;
> default:
> break;
> }
> }
> break;
> case MOUSE_DRAG:
> {
> GdkEventMotion *event = (GdkEventMotion*) e;
> static GdkWindow *gdkWindow;
> if (!gdkWindow)
> { // initialize
> gdkWindow = gdk_get_default_root_window();
> memset(&mouseState, 0, sizeof(mouseState));
> return TRUE;
> }
> if (!mouseState.isdragging ||
>     (mouseState.x == event->x && mouseState.y == event->y))
> return TRUE;
> brush(mouseState.cr, mouseState.x, mouseState.y, event->x, event->y);
> mouseState.x = event->x; mouseState.y = event->y;
> {
> // even though we don't use the resulting information from this call,
> // calling it is an indication to the main_loop()
> // that we are ready to receive the next mouse motion notify event
> gint x, y;
> GdkModifierType state;
> gdk_window_get_pointer(gdkWindow, &x, &y, &state);
> }
> }
> break;
> default:
> break;
> }
> return TRUE;
> }
> int main( int argc,
>           char *argv[] )
> {
>   GtkWidget *window;
>   GtkWidget *main_vbox;
>   gtk_init (&argc, &argv);
>
>   window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
>   gtk_signal_connect (GTK_OBJECT (window), "destroy", GTK_SIGNAL_FUNC
> (gtk_main_quit), "WM destroy");
>   gtk_widget_set_usize (GTK_WIDGET(window), 300, 200);
>
>   main_vbox = gtk_vbox_new (FALSE, 1);
>   gtk_container_border_width (GTK_CONTAINER (main_vbox), 1);
>   gtk_container_add (GTK_CONTAINER (window), main_vbox);
>   gtk_widget_show (main_vbox);
>
>   //gtkdrawable + cairo
>   GtkWidget *canvas = gtk_drawing_area_new();
>   gtk_widget_set_size_request (canvas, 500, 600);
>
>   //gtk_widget_add_events(canvas, GDK_BUTTON_PRESS_MASK);
>   gtk_widget_add_events(canvas, GDK_ALL_EVENTS_MASK);
>   g_signal_connect(canvas, "button-press-event", G_CALLBACK(handle_mouse),
> GINT_TO_POINTER(MOUSE_CLICK));
>   g_signal_connect(canvas, "button-release-event", G_CALLBACK(handle_mouse),
> GINT_TO_POINTER(MOUSE_CLICK));
>   g_signal_connect(canvas, "motion-notify-event",G_CALLBACK(handle_mouse),
> GINT_TO_POINTER(MOUSE_DRAG));
>   gtk_box_pack_start (GTK_BOX (main_vbox), canvas, FALSE, TRUE, 0);
>
>   //ends gtkdrawable + cairo example
>   gtk_widget_show_all (window);
>   gtk_main ();
>
>   return(0);
> }
>  END CODE EXAMPLE 
> 2011/7/23 Carlos López Camey 
>>
>> Hello, I'm new to the list, GTK+ and C. I'm building a Paint-like
>> application and was trying how to simulate the Brush tool with an
>> example to see how it performs. I read about GtkImage, GtkBitmap and
>> GtkPixmap but was recommended in #gtk+ over at irc.gnome.org to use a
>> GtkDrawingArea + Cairo since in GTK3 some of these were deprecated,
>> and it's encouraged to use cairo surfaces instead.
>>
>> The problem with my example is, when you click and "brush" with the
>> mouse moving *too fast*, the signal doesn't come fast enough. What
>> could/would be faster? using pixbufs + GtkImage? I couldn't find
>> enough documentation about that, but that's why I am asking :)
>>
>> Here's what I got (or if you prefer http://paste.pocoo.org/show/444721/)
>>
>> Thank you!
>>
>> - canvas-test.c --
>> #include 
>>
>> int isdragging = 0;
>>
>> /* Brush, paints a single pixel in coordinate x,y*/
>> void brush(cairo_t *cr, double x, double y){
>>  cairo_set_source_rgb(cr, 0, 0, 0);
>>  cairo_set_line_width (cr, 1);
>>  cairo_rectangle(cr,x,y,1,1);
>>  cairo_stroke(cr);
>>  cairo_destroy(cr);
>> }
>>
>> gboolean handle

Is GTK+ 3.x 2x slower than GTK+ 2.x?

2011-07-23 Thread Jakub Misak


Is GTK+ 3.x 2x slower than GTK+ 2.x?

Hello,

When I upgraded to GTK+ 3.0, the first thing that struck me was how 
sluggish it was compared to 2.24. The same dialogs in the same 
application appear immediately on the screen in the 2x version, while 
it takes time to paint them on the screen with the 3.x version. 
Browsing through menus or switching between tabs consumed 2x or 3x more 
CPU cycles in the 3.x version. The file open/save dialog is much slower 
(slower to show up, slower to change directories). Or hovering over the 
toolbuttons in 3.x-based Glade consumed 80% CPU cycles and the 
highlighting could barely keep up with the mouse cursor. Application 
startup is a bit slower with 3.x, too.

So I made a (very) simple and stupid benchmark that tests a couple of 
basic things in a loop, to see how the two GTK+ versions compare. 
If you're interested, you can download it here:

http://www.fileupyours.com/files/310686/perftest.tar.gz

(A simple "make" command should build both versions.)

I am testing it in xfwm4 with compositor turned off. If you test it in 
a compositing WM with window effects (open/close), especially with 
test #3 which opens/closes a dialog 50 times, it may measure something 
else than GTK+ speed...

The default GTK+ theme (Raleigh) was used for both 2.24 and 3.0.11. 
Both GTK+ 2.x and 3.x software was already running, so both library 
versions were loaded in memory (so it was probably not an issue for the 
startup speed).

The results from my 3GHz dual CPU desktop machine with the open-source 
radeon driver (I ran each test 7 times and took the best result for each 
test):

Startup, GTK+ 2: 0.11081 s, GTK+ 3: 0.14468 s
Test 1, GTK+ 2:  4.34362 s, GTK+ 3: 8.83771 s
Test 2, GTK+ 2:  1.72010 s, GTK+ 3: 2.33266 s
Test 3, GTK+ 2:  2.27047 s, GTK+ 3: 4.79270 s

It's not just my computer, as I tried it on an HP 625 laptop, again 
using the radeon driver:

Startup, GTK+ 2: 0.09357 s, GTK+ 3: 0.13600 s
Test 1, GTK+ 2:  3.27795 s, GTK+ 3: 5.20183 s
Test 2, GTK+ 2:  1.47700 s, GTK+ 3: 1.46733 s
Test 3, GTK+ 2:  1.35302 s, GTK+ 3: 5.14810 s

It's not the radeon driver either, as I tried it with the proprietary 
fglrx driver, too:

Startup, GTK+ 2: 0.09058 s, GTK+ 3: 0.13770 s
Test 1, GTK+ 2:  2.42151 s, GTK+ 3: 6.67091 s
Test 2, GTK+ 2:  1.15294 s, GTK+ 3: 1.44557 s
Test 3, GTK+ 2:  1.31779 s, GTK+ 3: 4.64865 s

It's probably not the default theme either. First, the default themes 
look very similar in both versions. Second, test 2 does not seem to be 
influenced by the GTK+ version too much. Third, when I use slow fancy 
themes in both GTK+ versions (Victory, Adwaita, New Wave...), I still 
get the same pattern again - even though a fancy theme makes both 
versions (sometimes even 6x) slower, 3.x is still 50-150% slower than 
2.x (except for test 2, which seems to be mainly influenced by the 
theme itself). And fourth, even a slow fancy GTK+ 2.x theme is faster 
than the plain default 3.x theme.

Finally, it's not my Linux distribution either. I ran the tests in 3 
different distros (Arch Linux, LMDE and Fedora 15, with Xfce in all of 
them), and always got similar results.

So my question is - is there something in GTK+ 3.0 that could possibly 
cause such a dramatic slowdown compared to 2.24?
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: Is goocanvas best for scrapbook type app?

2011-07-23 Thread Fred van Zwieten

Hi Paul,

Thanks for the link. That one was new to me. Seems like goocanvas, libccc
and clutter are the main candidates. I don't want to use clutter because I
do not want to depend on 3d stuff.

So i agree it seems GooCanvas is the way to go.

Greetz,

Fred 



2011/7/23 Paul Davis 

> On Sat, Jul 23, 2011 at 10:52 AM, Fred van Zwieten 
> wrote:
>
> > Now, i have been looking around for the best way to build this and it
> seems
> > to me goocanvas is the best widget to use for this kind of functionality
> > from vala.
>
> some kind of canvas widget is the best way to do this, yes. goocanvas
> is one such widget, and its probably the best choice at this point in
> time, but there are others.
>
> http://live.gnome.org/ProjectRidley/CanvasOverview
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: Is goocanvas best for scrapbook type app?

2011-07-23 Thread Vivien Malerba

On 23 July 2011 16:52, Fred van Zwieten  wrote:

> Hello all,
>
> I am getting into vala development and want to make a scrapbook like app
> where one can put all kind of photo's, pictures, graphics and text blocks on
> a canvas. For each of these item's, one should be able to move them around,
> resize them, put one partly over the other, etc. (you get the picture, i
> hope). This will ultimately be a plugin for shotwell.
>
> Now, i have been looking around for the best way to build this and it seems
> to me goocanvas is the best widget to use for this kind of functionality
> from vala.
>

I don't know if there are any vala bindings for it, but you may also want to
have a look at Clutter:  http://www.clutter-project.org/

Regards,

Vivien
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: Is goocanvas best for scrapbook type app?

2011-07-23 Thread Paul Davis

On Sat, Jul 23, 2011 at 10:52 AM, Fred van Zwieten  wrote:

> Now, i have been looking around for the best way to build this and it seems
> to me goocanvas is the best widget to use for this kind of functionality
> from vala.

some kind of canvas widget is the best way to do this, yes. goocanvas
is one such widget, and its probably the best choice at this point in
time, but there are others.

http://live.gnome.org/ProjectRidley/CanvasOverview
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

GTK+ 3.1.10

2011-07-23 Thread Matthias Clasen

GTK+ 3.1.10 is now available for download at:

 ftp://ftp.gtk.org/pub/gtk/3.1/
 http://download.gnome.org/sources/gtk+/3.1/

976e90b97e978aecce988984eef04cb4a44720a3ddf863ee2b169f056fb91580  gtk
+-3.1.10.tar.xz
40bec15c44f95a269526e0aab3fad3c0d1d66f3d3445507887b20af6f4269f81  gtk
+-3.1.10.tar.bz2

Another release in the 3.1 development cycle.

This release is noteworthy for being the first which replaces the gail
module with builtin accessibility. Note that these changes are not
finalized, and one of the motivations for this release is to find
issues with third-party accessibility implementations.

Another set of large-scale changes in this release is in the file
chooser, where the focus is placed more on recent files. Please
report problems with these changes as well.



GTK+ is a multi-platform toolkit for creating graphical user
interfaces. Offering a complete set of widgets, GTK+ is suitable for
projects ranging from small one-off tools to complete application
suites.

GTK+ has been designed from the ground up to support a range of
languages, not only C/C++. Using GTK+ from languages such as Perl and
Python (especially in combination with the Glade GUI builder) provides
an effective method of rapid application development.

GTK+ is free software and part of the GNU Project. However, the
licensing terms for GTK+, the GNU LGPL, allow it to be used by all
developers, including those developing proprietary software, without
any license fees or royalties.


Overview of Changes in GTK+ 3.1.10
==

* Assorted file chooser improvements/redesign:
 - Remove the expander in Save mode
 - Move the path bar up in Save mode
 - Remember the last opened directory
 - Start in recently-used mode when no folder is set
 - Update recent-files when confirming in the file chooser

* Accessibility:
 - Gail has been merged into GTK+ and is no longer a module
 - A testsuite for a11y functionality has been added

* Theming:
 - Icon view cells can now have a border

* GtkMountOperation can now show processes on OpenBSD

* Gdk input devices now expose their XInput2 device ID
  via gdk_x11_device_get_id()

* Bugs fixed:
 653450 gtkfilechooser crashes when adding favorite
 653705 GtkAssistant doesn't notice destroyed pages
 653947 Crash in gdk/x11/gdkdevicemanager-xi2.c:get_event_window
 654125 gdkoffscreenwindow set any impl handlers to null...
 654179 iconview: make it possible for selected cells to render...
 654428 focusable labels are emitting inappropriate object:text-sel...
 654678 Message dialog's primary text font increases on every call...
 654695 Memory corruption in gtk_theming_engine_register_property()
 654720 void return issues cause compile issues for GTK 3.1.8
 655009 Clamp border radius following CSS specs
 654266 No longer possible to set empty text on a GtkProgressBar

* Translation updates:
 Galician
 German
 Hebrew
 Latvian
 Lithuanian
 Norwegian bokmål
 Persian
 Polish
 Slovenian
 Spanish
 Uighur


Thanks to all contributors:
Benjamin Otte
Joachim Breitner
Rico Tzschichholz
Javier Jardón
Johan Dahlin
Cosimo Cecchi
Federico Mena Quintero
Juan Pablo Ugarte
Ignacio Casal Quinteiro
Chun-wei Fan
John Ralls
Kristian Rietveld
Carlos Garnacho
Florian Müllner
Brian Cameron
Philip Withnall
Ryan Lortie
Andrea Cimitan
Andre Klapper
Patrick Welche


July 22, 2011
Matthias Clasen


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

Is goocanvas best for scrapbook type app?

2011-07-23 Thread Fred van Zwieten

Hello all,

I am getting into vala development and want to make a scrapbook like app
where one can put all kind of photo's, pictures, graphics and text blocks on
a canvas. For each of these item's, one should be able to move them around,
resize them, put one partly over the other, etc. (you get the picture, i
hope). This will ultimately be a plugin for shotwell.

Now, i have been looking around for the best way to build this and it seems
to me goocanvas is the best widget to use for this kind of functionality
from vala.

Would you agree? Are there better ways?

Thank you for any advise on this.

Greetz,

Fred 
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Gtk:ERROR:gtkrecentmanager.c

2011-07-23 Thread Dmitry Shkirmanov

Hello, list, i installed gtk 3 from sources in my home directory, 
compilled and installed the anjuta program that requires gtk 3.  Anjuta 
starts by a script in which LD_LIBRARY_PATH is written. When i try to 
start anjuta it returns :


Gtk:ERROR:gtkrecentmanager.c:1936:get_icon_fallback: assertion failed: 
(retval != NULL)



and crashes.
Is it possible to fix it?

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

Re: How to improve performance of this example?

2011-07-23 Thread richard boaz

hi,

the problem isn't the mouse going "too fast" (this is "not possible", if it
can go fast, it can), it's that you're wanting to draw a line using points.

drawing a real line between the last point received by the drag event and
the new/next point will get you what you want, example code below.

and to answer your question, yes it can be made more efficient.

cheers,

richard

p.s. be careful re: your callback parameters, your drag function defined the
2nd argument wrong.

 BEGIN CODE EXAMPLE 

#include 
#include 

enum {
 MOUSE_CLICK,
MOUSE_DRAG,
 TTL_MOUSE_EVENTS
};

static inline void brush(cairo_t *cr, double x1, double y1, double x2,
double y2)
{
cairo_move_to(cr, x1, y1);
 cairo_line_to(cr, x2, y2);
cairo_stroke(cr);
}

static gboolean handle_mouse(GtkWidget *widget, void *e, gpointer *t)
{
static struct {
 gboolean isdragging;
cairo_t *cr;
 double x, y;
} mouseState;
 gint type = GPOINTER_TO_INT(t);
 switch(type)
 {
case MOUSE_CLICK:
 {
GdkEventButton *event = (GdkEventButton*) e;
 switch(event->type)
{
 case GDK_BUTTON_PRESS:
{
 mouseState.isdragging = TRUE;
mouseState.cr = gdk_cairo_create(widget->window);
 cairo_set_source_rgb(mouseState.cr, 0, 0, 0);
cairo_set_line_width(mouseState.cr, 2);
 mouseState.x = event->x; mouseState.y = event->y;
 }
break;
 case GDK_BUTTON_RELEASE:
{
 cairo_destroy(mouseState.cr);
memset(&mouseState, 0, sizeof(mouseState));
 }
break;
 default:
break;
 }
}
 break;
 case MOUSE_DRAG:
{
 GdkEventMotion *event = (GdkEventMotion*) e;
static GdkWindow *gdkWindow;

if (!gdkWindow)
 { // initialize
 gdkWindow = gdk_get_default_root_window();
memset(&mouseState, 0, sizeof(mouseState));
 return TRUE;
}

if (!mouseState.isdragging ||
 (mouseState.x == event->x && mouseState.y == event->y))
 return TRUE;

 brush(mouseState.cr, mouseState.x, mouseState.y, event->x, event->y);
 mouseState.x = event->x; mouseState.y = event->y;

{
 // even though we don't use the resulting information from this call,
 // calling it is an indication to the main_loop()
// that we are ready to receive the next mouse motion notify event
 gint x, y;
GdkModifierType state;
 gdk_window_get_pointer(gdkWindow, &x, &y, &state);
}
 }
break;
 default:
break;
 }

 return TRUE;
}

int main( int argc,
  char *argv[] )
{
  GtkWidget *window;
  GtkWidget *main_vbox;

  gtk_init (&argc, &argv);

  window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
  gtk_signal_connect (GTK_OBJECT (window), "destroy", GTK_SIGNAL_FUNC
(gtk_main_quit), "WM destroy");
  gtk_widget_set_usize (GTK_WIDGET(window), 300, 200);

  main_vbox = gtk_vbox_new (FALSE, 1);
  gtk_container_border_width (GTK_CONTAINER (main_vbox), 1);
  gtk_container_add (GTK_CONTAINER (window), main_vbox);
  gtk_widget_show (main_vbox);

  //gtkdrawable + cairo
  GtkWidget *canvas = gtk_drawing_area_new();
  gtk_widget_set_size_request (canvas, 500, 600);

  //gtk_widget_add_events(canvas, GDK_BUTTON_PRESS_MASK);
  gtk_widget_add_events(canvas, GDK_ALL_EVENTS_MASK);
  g_signal_connect(canvas, "button-press-event", G_CALLBACK(handle_mouse),
GINT_TO_POINTER(MOUSE_CLICK));
  g_signal_connect(canvas, "button-release-event", G_CALLBACK(handle_mouse),
GINT_TO_POINTER(MOUSE_CLICK));
  g_signal_connect(canvas, "motion-notify-event",G_CALLBACK(handle_mouse),
GINT_TO_POINTER(MOUSE_DRAG));

  gtk_box_pack_start (GTK_BOX (main_vbox), canvas, FALSE, TRUE, 0);

  //ends gtkdrawable + cairo example
  gtk_widget_show_all (window);
  gtk_main ();

  return(0);
}

 END CODE EXAMPLE 

2011/7/23 Carlos López Camey 

> Hello, I'm new to the list, GTK+ and C. I'm building a Paint-like
> application and was trying how to simulate the Brush tool with an
> example to see how it performs. I read about GtkImage, GtkBitmap and
> GtkPixmap but was recommended in #gtk+ over at irc.gnome.org to use a
> GtkDrawingArea + Cairo since in GTK3 some of these were deprecated,
> and it's encouraged to use cairo surfaces instead.
>
> The problem with my example is, when you click and "brush" with the
> mouse moving *too fast*, the signal doesn't come fast enough. What
> could/would be faster? using pixbufs + GtkImage? I couldn't find
> enough documentation about that, but that's why I am asking :)
>
> Here's what I got (or if you prefer http://paste.pocoo.org/show/444721/)
>
> Thank you!
>
> - canvas-test.c --
> #include 
>
> int isdragging = 0;
>
> /* Brush, paints a single pixel in coordinate x,y*/
> void brush(cairo_t *cr, double x, double y){
>  cairo_set_source_rgb(cr, 0, 0, 0);
>  cairo_set_line_width (cr, 1);
>  cairo_rectangle(cr,x,y,1,1);
>  cairo_stroke(cr);
>  cairo_destroy(cr);
> }
>
> gboolean handle_mouse_click(GtkWidget *widget, GdkEventButton *event,
> gpointer user_data){
>  brush(gdk_cairo_create(widget->window), event->x, event->y);
>  isdragging = 1;
>  return TRUE;
> }
>
> gboolean handle_mouse_release(GtkWidget *widget, GdkEventButton
> *event, gpointer user_data){
>  if (event->button == 1) {
>isdragging = 0;
>  }
>
>  return TRUE;

How to improve performance of this example?

2011-07-23 Thread Carlos López Camey

Hello, I'm new to the list, GTK+ and C. I'm building a Paint-like
application and was trying how to simulate the Brush tool with an
example to see how it performs. I read about GtkImage, GtkBitmap and
GtkPixmap but was recommended in #gtk+ over at irc.gnome.org to use a
GtkDrawingArea + Cairo since in GTK3 some of these were deprecated,
and it's encouraged to use cairo surfaces instead.

The problem with my example is, when you click and "brush" with the
mouse moving *too fast*, the signal doesn't come fast enough. What
could/would be faster? using pixbufs + GtkImage? I couldn't find
enough documentation about that, but that's why I am asking :)

Here's what I got (or if you prefer http://paste.pocoo.org/show/444721/)

Thank you!

- canvas-test.c --
#include 

int isdragging = 0;

/* Brush, paints a single pixel in coordinate x,y*/
void brush(cairo_t *cr, double x, double y){
  cairo_set_source_rgb(cr, 0, 0, 0);
  cairo_set_line_width (cr, 1);
  cairo_rectangle(cr,x,y,1,1);
  cairo_stroke(cr);
  cairo_destroy(cr);
}

gboolean handle_mouse_click(GtkWidget *widget, GdkEventButton *event,
gpointer user_data){
  brush(gdk_cairo_create(widget->window), event->x, event->y);
  isdragging = 1;
  return TRUE;
}

gboolean handle_mouse_release(GtkWidget *widget, GdkEventButton
*event, gpointer user_data){
  if (event->button == 1) {
isdragging = 0;
  }

  return TRUE;
}

gboolean handle_mouse_drag(GtkWidget *widget, GdkEventButton *event,
gpointer user_data){
  if (isdragging)
brush(gdk_cairo_create(widget->window), event->x, event->y);
  return TRUE;
}

int main( int argc,
  char *argv[] )
{
  GtkWidget *window;
  GtkWidget *main_vbox;

  gtk_init (&argc, &argv);

  window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  gtk_signal_connect (GTK_OBJECT (window), "destroy", GTK_SIGNAL_FUNC
(gtk_main_quit), "WM destroy");
  gtk_widget_set_usize (GTK_WIDGET(window), 300, 200);

  main_vbox = gtk_vbox_new (FALSE, 1);
  gtk_container_border_width (GTK_CONTAINER (main_vbox), 1);
  gtk_container_add (GTK_CONTAINER (window), main_vbox);
  gtk_widget_show (main_vbox);

  //gtkdrawable + cairo
  GtkWidget *canvas = gtk_drawing_area_new();
  gtk_widget_set_size_request (canvas, 500, 600);

  //gtk_widget_add_events(canvas, GDK_BUTTON_PRESS_MASK);
  gtk_widget_add_events(canvas, GDK_ALL_EVENTS_MASK);
  g_signal_connect(canvas, "button-press-event",
G_CALLBACK(handle_mouse_click), NULL);
  g_signal_connect(canvas, "button-release-event",
G_CALLBACK(handle_mouse_release), NULL);
  g_signal_connect(canvas,
"motion-notify-event",G_CALLBACK(handle_mouse_drag), NULL);

  gtk_box_pack_start (GTK_BOX (main_vbox), canvas, FALSE, TRUE, 0);

  //ends gtkdrawable + cairo example
  gtk_widget_show_all (window);
  gtk_main ();

  return(0);
}
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

GdkDrawable from GtkDrawingArea and it's cairo surface

Re: Is GTK+ 3.x 2x slower than GTK+ 2.x?

Re: How to improve performance of this example?

Is GTK+ 3.x 2x slower than GTK+ 2.x?

Re: Is goocanvas best for scrapbook type app?

Re: Is goocanvas best for scrapbook type app?

Re: Is goocanvas best for scrapbook type app?

GTK+ 3.1.10

Is goocanvas best for scrapbook type app?

Gtk:ERROR:gtkrecentmanager.c

Re: How to improve performance of this example?

How to improve performance of this example?

12 matches

Site Navigation

Mail list logo

Footer information