Re: Speed of Gdk-Pixbuf Vs. GdkRGB
Hi, David J. Singer wrote: My question is, if drawing speed is an issue, is it faster to use the slightly lower-level GdkRGB method rather than the Gdk-Pixbuf one? More generally, how does the Gdk-Pixbuf stuff rate in terms of drawing speed compared to GkdRGB? They are equivalent (AFAIK). You only need the lower-level stuff if you want to avoid loading the whole image into memory, or I guess if your image is procedurally generated. It should be easy to benchmark I guess. On a related point, I usually define a backing pixmap in a 'configure' callback, draw the graphical content into the pixmap, then copy it to the drawing-area in one go in an 'expose' callback. (based loosely on the "simple example program using GdkRGB" in the Gdk docs). Is this still the best way to go for fast, flicker-free graphic updates? Gtk now does this for you. Before calling your expose callback, gtk allocates an offscreen pixmap the size of the expose area, redirects gdk_* to that off screen pixmap, calls your expose handler, then copies the offscreen pixmap to the display. Smarter expose compression makes this acceptably quick in most cases: exposes are batched up and your handler will be called with the bounding box of the area to be repainted. If this is too coarse, you can get the exact minimal list of dirty rects out of the expose structure. The downside is you must only ever paint in the expose handler. For video stuff, you need to call gtk_widget_queue_draw_area( widget, x, y, w, h ) when a frame comes in to get a repaint queued for the right part of your widget. John ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Speed of Gdk-Pixbuf Vs. GdkRGB
On Wednesday 21 April 2004 6:13 pm, John Cupitt wrote: > > They are equivalent (AFAIK). You only need the lower-level stuff if you > want to avoid loading the whole image into memory OK. That's interesting. I kinda assumed GdkRGB would be loads faster because it has a much "lower-level" feel to it... I was using it to display simple (widget-type) animations by manually loading all the frames into memory then calling up each frame using 'gdk_draw_rgb_image' with the required offset.. The prospect of using the built-in animation stuff seems tempting, but only if it is *at least* as quick as my current method! :) > Before calling your expose callback, gtk allocates an offscreen pixmap the > size of the expose area, redirects gdk_* to that off screen pixmap, calls > your expose handler, then copies the offscreen pixmap to the display. So I just use the standard gdk_draw_xxx type stuff in the expose callback and that's it? Interesting. > The downside is you must only ever paint in the expose handler. That's the catch. It's usually far more useful to be able to assemble the backing pixmap piece by piece, then just allow it to get "automatically" updated (as it were) when an expose event occurs... So I guess in this case I need to stick to my old method of doing it? Right? -- David J. Singer [EMAIL PROTECTED] "Time flies like an arrow, fruit flies like a banana" ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Speed of Gdk-Pixbuf Vs. GdkRGB
Hi, "David J. Singer" <[EMAIL PROTECTED]> writes: > On Wednesday 21 April 2004 6:13 pm, John Cupitt wrote: > > > > They are equivalent (AFAIK). You only need the lower-level stuff if you > > want to avoid loading the whole image into memory > > OK. That's interesting. I kinda assumed GdkRGB would be loads faster > because it has a much "lower-level" feel to it... You are right about that since you are comparing apples and pears here. GdkRGB and GdkPixbuf aren't exchangeable. Actually if you draw a GdkPixbuf, GdkRGB might be used. What happens exactly depends on the type of pixbuf. Pixbufs with alpha channel are blended with the screen content using the XRender extension. This will in most cases be faster that getting the screen content, blending with it and writing the blended result back. If there's no need for blending because the pixbuf is opaque, a GdkImage (or rather a set of pre-allocated scratch images) is being used to render the pixbuf to screen. If you need to render the pixbuf often and don't need blending, you should consider to draw it to an offscreen pixmap (a GdkPixmap) and use that to blit the image to the screen. Sven ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Speed of Gdk-Pixbuf Vs. GdkRGB
Hi again, David J. Singer wrote: On Wednesday 21 April 2004 6:13 pm, John Cupitt wrote: They are equivalent (AFAIK). You only need the lower-level stuff if you want to avoid loading the whole image into memory OK. That's interesting. I kinda assumed GdkRGB would be loads faster because it has a much "lower-level" feel to it... I was using it to display simple (widget-type) animations by manually loading all the frames into memory then calling up each frame using 'gdk_draw_rgb_image' with the required offset.. The prospect of using the built-in animation stuff seems tempting, but only if it is *at least* as quick as my current method! :) Ah OK. I always think in terms of image display widgets (what I've worked on). If you're doing a lot of animation I guess it's different and maybe the lower level stuff would offer savings. Have you looked at the pixbuf demo? gtk+-2.4.0/demos/pixbuf-demo It animates with scaling and transparency, you might be able to make a simple benchmark out of it too. testpixbuf-scale is rather cool as well. The downside is you must only ever paint in the expose handler. That's the catch. It's usually far more useful to be able to assemble the backing pixmap piece by piece, then just allow it to get "automatically" updated (as it were) when an expose event occurs... So I guess in this case I need to stick to my old method of doing it? Right? I guess you'll need to experiment :-( I have simple animations in my application (rubber-band lines are drawn with crawling dashes, selection outlines are drawn with a 3D appearance and slide over the image and over each other as you drag, and so on) and they all work like this: - event occurs, for example a timer callback or a mouse action - queue an expose for the current position of the object - update the object position and state - queue an expose for the new object position The expose handler works like this: - loop for all dirty rects - set the clip to the rect outline - loop for the set of screen objects which touch this rect, in Z order - ask object to repaint So updating the internal model and painting it are decoupled. Sorry if this is obvious or unclear. John ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Speed of Gdk-Pixbuf Vs. GdkRGB
Steffen, John, > If you need to render the pixbuf often and don't need blending, you > should consider to draw it to an offscreen pixmap (a GdkPixmap) and > use that to blit the image to the screen. I'm a little confused now! In my original posting I mentioned that I usually "define a backing pixmap in a 'configure' callback, draw the graphical content into the pixmap, then copy it to the drawing-area in one go in an 'expose' callback". I guess this is what you are recommending I do. John Cupitt mentioned in a previous posting in this thread that "Gtk now does this for you" which suggests to me that if I'm using my own backing pixmap and Gtk is using *its* own backing pixmap, there's some redundancy...! So what's the answer? Sorry to labour the point, I'd just like to be sure I understand what's going on. :) Regards, -- David J. Singer [EMAIL PROTECTED] "Time flies like an arrow, fruit flies like a banana" ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Speed of Gdk-Pixbuf Vs. GdkRGB
Hi, "David J. Singer" <[EMAIL PROTECTED]> writes: > I'm a little confused now! In my original posting I mentioned that > I usually "define a backing pixmap in a 'configure' callback, draw > the graphical content into the pixmap, then copy it to the > drawing-area in one go in an 'expose' callback". I guess this is > what you are recommending I do. That's not a backing pixmap, it's a background pixmap. So instead of erasing your window background to the background color, the background pixmap is being used. > John Cupitt mentioned in a previous posting in this thread that "Gtk > now does this for you" which suggests to me that if I'm using my own > backing pixmap and Gtk is using *its* own backing pixmap, there's > some redundancy...! So what's the answer? If GDK uses pixmaps to double-buffer your drawing (as it does in 2.x), this backbuffer will be initialized from your background pixmap so that any drawing ends up being drawn on top of it. Then, when all drawing is completed, the backbuffer pixmap is blitted to the window. > Sorry to labour the point, I'd just like to be sure I understand > what's going on. :) Well, you are obviously suffering from some fundamental misunderstandings. Don't worry though, the X rendering concept is not easy to understand and GTK+/GDK as well as all the nifty new X extensions add quite some complexity. Sven ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Speed of Gdk-Pixbuf Vs. GdkRGB
Sven, > Well, you are obviously suffering from some fundamental > misunderstandings. Don't worry though, the X rendering concept is not > easy to understand and GTK+/GDK as well as all the nifty new X > extensions add quite some complexity. An understatement! :-) OK. I'm going to have to go and think about all this now. Many thanks to you (and John) for the advice. Regards -- David J. Singer [EMAIL PROTECTED] "Time flies like an arrow, fruit flies like a banana" ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Speed of Gdk-Pixbuf Vs. GdkRGB
On Thursday 22 April 2004 6:48 pm, Sven Neumann wrote: > > That's not a backing pixmap, it's a background pixmap. So instead of > erasing your window background to the background color, the background > pixmap is being used. OK. I'm doing some reading-up on this offline now and going throught the Gtk/Gdk examples. OK. A further question :) I understand how the drawing is done to a backing pixmap and then copied to the screen during an expose event. However, if I need to update graphics on the screen asynchronously (i.e. not just when an expose occurs due to a resize or whatever) I guess I need to (a) update the backing pixmap, then (b) call expose manually. I notice the scribble example uses 'gtk_widget_queue_draw_area' to basically call expose to redraw the bit that's changed. Is this the approved (and optimal - in a speed sense) way to do it or just a simplification for the example? Regards -- David J. Singer [EMAIL PROTECTED] "Time flies like an arrow, fruit flies like a banana" ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Speed of Gdk-Pixbuf Vs. GdkRGB
Hi, "David J. Singer" <[EMAIL PROTECTED]> writes: > I notice the scribble example uses 'gtk_widget_queue_draw_area' to > basically call expose to redraw the bit that's changed. Is this the > approved (and optimal - in a speed sense) way to do it or just a > simplification for the example? gtk_widget_queue_draw() would certainly have been simpler (but quite inefficient). Sven ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
