GNOME Bugzilla – Bug 85911
Gdk::Drawable::draw_*_image functions
Last modified: 2004-12-22 21:47:04 UTC
(See bug #83244 for beginning of this discussion) In Gdk::Drawable class there are some images rendering function: -draw_rgb_image -draw_rgb_image_dithalign -draw_rgb_32_image -draw_rgb_32_image_dithalign -draw_gray_image -draw_indexed_image All of those functions takes as parameter a guchar* buffer containing the image data. I think, in a C++ view, the use of a vector can be usefull for some developper. Taking the draw_indexed_image function it have now the following prototype: void draw_indexed_image ( const Glib::RefPtr<const GC>& gc, int x, int y, int width, int height, RgbDither dith, const guchar* rgb_buf, int rowstride, GdkRgbCmap& cmap) Adding in Gdk::Drawable the same function with the following prototype can be usefull: void draw_indexed_image ( const Glib::RefPtr<const GC>& gc, int x, int y, int width, int height, RgbDither dith, vector<guchar>& rgb_buf, GdkRgbCmap& cmap) Also I know the rgb_buf may contain a huge amount of data. Typically, for an indexed image and a fullsize 1280x1024 display, it takes: 1.310.720 bytes... More than 1M. It's why I suggest adding a prototype using vector, not replacing the existing one.
How do we know how big the rgb_buf array should be?
With my proposed prototype, I asume the rgb_buf contains only image datas(so there's no need for a rowstride). For it's size, it can be simply calculated with a multiplication: width*height.
So what is row_stride for?
As said in the Gdk doc: rowstride: The number of bytes from the start of one row in buf to the start of the next. So you may have extra data in your buffer at each end of line. I'll publish tomorrow the code I'm writing that use all those functions(as well as the GModule).
The code using those features has been released: http://student.ulb.ac.be/~osamyn/fract/index.html
Please just paste some code so that we don't need to look through your whole tarball. I'm sure that you are halfway towards writing a gtkmm patch yourself anyway.
Created attachment 9551 [details] [review] draw_indexed_image impl
For the code example I think I posted one with the Gdk::RgbCmap bug... For the rest, I attach here a first patch that implements what I needed for the draw_indexed_image... I'll need to do the same with the other functions... I'll try to do it this week... and to create a small example.
Please submit a cvs patch. See www.gtkmm.org/bugs.shtml for details. At the moment you are patching generated files, and you have not patched the ChangeLog, or used the PATCH keyword in bugzilla. Also, for something that hold lots of data, it would probably be more efficient to use a typedefed vector instead of the ArrayHandle. Would people want to use anything other than a vector anyway?
Remember that we have an API freeze soon.
I didn't forget but I've so many work... I thinked about a better solution than the one I proposed. The new solution is to create some Helpers classes that handle images vectors for the user. For example we will have: void draw_indexed_image ( const Glib::RefPtr<const GC>& gc, int x, int y, int width, int height, RgbDither dith, Gdk::Drawable_Helpers::IndexedImage &img, GdkRgbCmap& cmap) Where Gdk::Drawable_Helpers::IndexedImage will give the user a simple interface like: get/set_color_at(int x, int y, int color_index); What do you think about this more powerfull Idea ?
Doesn't one of the existing images classes, such as Gdk::Pixmap/Pixbuf already do this? I think that this is too much work for one method which isn't used very much anyway.
This will be punted unless a suitable patch is supplied soon.
I don't have time for writing some code now (it's a month ago I done the last mod on my own project...) So for me we may forgot about this API change and close the bug.
Erm, we shouldn't enforce the use of std::vector<> for raw image data. That's only inconvenient in most cases. You can always do: &vector.front() to get a builtin array.
Does anyone still care about this?
The rowstride parameter is still important. If you have a large image, and you are responding to an expose event for just part of that image, you should only render the part of the image that you're being asked to. For example, if you have a 100 pixel wide image, and wish to display the column from 10px in to 90px in, you would pass in a pointer to the (image+10px), a width of 80px and a rowstride of 100px, so that the next row is drawn from the right part of the image.
It's only when you're drawing the whole image that width==rowstride.
Given this and Daniel Elstner's comment, I don't think there's anything to do for this bug.
Closing then.