Re: A request for future gdk_scale_pixbuf...

["Lewin A.R.W. Edwards" <larwe larwe com>]

> > The specific one is that scale_simple allocates a new pixbuf which
> > then has to be destroyed. I don't want to do this. I avoid dynamic
> > memory allocation STRENOUSLY in my application; in fact, I have a
>
> GTK in general will cause you problems here. Also, I don't see how to


Yes, but I don't want to create an additional LARGE allocation unless I 
have to.


> scale other than by scaling _to_ something, which means you have to


I scale to a second statically allocated pixbuf. I don't mind having 
this structure hanging around for the life of my program, because I'm 
always going to need it. The first few lines of my program are something 
like this (XPEG_Buffer and Screen_Buffer are statically allocated arrays 
of RGB data).

        mainwindow = gtk_window_new(GTK_WINDOW_POPUP);
        gtk_widget_set_usize(mainwindow, screenX, screenY);
        gtk_widget_set_uposition(mainwindow,0,0);

        // Create and clear load and scale pixbufs
        memset(XPEG_Buffer, 0, sizeof(XPEG_Buffer));
	pbLoadBuffer = gdk_pixbuf_new_from_data(XPEG_Buffer, GDK_COLORSPACE_RGB, 
FALSE, 8, JPEG_MAX_X, JPEG_MAX_Y, JPEG_MAX_X * JPEG_PIXEL_SIZE, NULL, NULL);
	pbScreenBuffer = gdk_pixbuf_new_from_data(Screen_Buffer, 
GDK_COLORSPACE_RGB, FALSE, 8, SCREEN_MAX_X, SCREEN_MAX_Y, SCREEN_MAX_X * 
SCREEN_MAX_PIXEL_SIZE, NULL, NULL);

        gtk_widget_show_all(mainwindow);

        // Get graphics context for main window
        gcWindow = gdk_gc_new(mainwindow->window);

Everything you see there remains allocated for the life of the program.

scale_simple would possibly be suitable for me, or at least no worse 
than the current scale function, if it took a "destpixbuf" parameter 
rather than internally allocating a new pixbuf.


> > changing its aspect ratio. This means that the destination blit
> > doesn't necessarily start at (0,0), and in "center" mode if the source
> > is larger than the screen (meaning that only a window out of the
> > center is being rendered), the source blit doesn't either.
>
> I don't think that should matter, because you are not rendering
> straight to the screen. So you can just compute the needed pixbuf
> size, then scale to that, then put it wherever you like on the screen,
> right?


Not quite. I want to have an offscreen copy of exactly what is going to 
be shown in the window. To achieve this using the current code, I need 
to have THREE buffers:

* source buffer
* scale source -> scaled (non-relocated) object
* relocate/clip to offscreen buffer

The reason I want to have an offscreen copy is so that I can bring in 
the new copy in an attractive or exciting way.


> > > In GTK 2 you can create a "subpixbuf" of the source image, in order to
> > Aha. That's more like what I'm looking for. Although I guess I can
> > achieve the same result in 1.0 by using gdk_pixbuf_new_from_data and
>
> Yes, you can do that. Just have to be a bit careful about the memory
> management (make sure your "subpixbuf" doesn't hang around later than
> your master pixbuf).


As above. I never deallocate anything.

> I would generally say the scaling API is too complicated. I just fixed
> the 2.0 docs to try to push people toward scale_simple() a bit more
> and explain InterpType.


*push push* Come on, 
gdk_scale_pixbuf_the_way_lewin_likes_it(sourcepbuf,sourcex,sourcey,sourcewidth,sourceheight,destpbuf,destx,desty,destwidth,destheight). 
How much more intuitive can you get? ;)

> If I were you I'd just implement with scale_simple(). I don't see
> where the annoying scale() variant is going to get you.


Less susceptible to memory fragmentation, for one thing.


--
-- Lewin A.R.W. Edwards (Embedded Engineer)
Work     http://www.digi-frame.com/
Personal http://www.larwe.com/
Tel (914) 937-4090 9am-6pm ET M-F