Re: Working with images

[muppet <scott asofyet org>]

On Aug 22, 2004, at 8:18 PM, Daniel Kasak wrote:

> Ah. Yes, now I feel stupid. Man, I looked at that line for 20 minutes  
> without spotting that.

i know the feeling, i do that a lot.  ;-)


> > > At this point, $splash_frame certainly containts a  
> > > Gtk2::Gdk::Pixbuf. The only bit I'm unsure of is the  
> > > Gtk2::Gdk::InterpType bit, for which I used 'nearest'.
> >
> > if you're using scale factors of 1, then the interptype is rather  
> > uninteresting.
> ??? The scale factor of 1 is the only setting that gives me the image  
> scaled at the right size. Other settings make it ... well ... too big.

i meant: scale factors of 1 mean no scaling, and if there's no scaling,  
there's no interpolation to be done, so the interptype is not  
important; 'none' would be good, but 'nearest' is as close to a  
passthru as the api appears to offer.


>      $splash_screen = Gtk2::Window->new;

traditional slash screens are borderless windows that are centered.   
you'd do that with

    $splash_screen = Gtk2::Window->new ('popup');
    $splash_screen->set_position ('center-always');

>    $splash_screen->set_size_request (400, 300);

you're using hardcoded sizes all over the place.  why?  if/when you  
change the sizes of the images, that's going to be painful.  a  
GdkPixbuf knows its size; you can set the size of the drawing area  
based on the size of the image, and the window will size itself  
accordingly.

>    $splash_screen->set_title ("Pixbufs");
>    $splash_screen->set_resizable (0);
>      $splash_screen->signal_connect (destroy => sub  
> {$splash_screen=undef; 1});
>    $splash_screen->signal_connect (destroy => \&splash_screen_cleanup);
>      $splash_frame = Gtk2::Gdk::Pixbuf->new ('rgb', 'FALSE', 8, 400,  
> 300);
>    $background_image =  
> Gtk2::Gdk::Pixbuf->new_from_file("$currentdir/sales/background.jpg");
>    $fade_image =  
> Gtk2::Gdk::Pixbuf->new_from_file("$currentdir/sales/ 
> nus_consulting_group.png");
>      $splash_screen->signal_connect (destroy => sub  
> {$splash_screen=undef; 1});
>    $splash_screen->signal_connect (destroy => \&splash_screen_cleanup);

you have these lines in there twice, which means the handlers are  
getting connected and run twice, resulting in an assertion when  
Glib::Source::remove() gets called on the already-removed id.


>              $fade_image->composite(
>                                        $splash_frame,
>                                        0, 0,
>                                        400, 300,
>                                        50, 100,
>                                        1, 1,
>                                        'nearest',
>                                        $splash_counter * 2
>                              );

how big is the fade image?  it is actually 400x300?  if you're using an  
offset of 50x100 to put it in a different place, then i wager it's  
smaller than 400x300, and you're getting garbage rendered into the  
remainder.  this would be the source of the "rendering bugs" -- from  
the screenshot it looks like they are actually extrapolations of the  
edge pixels, to fill in missing pixel values since you asked it to draw  
pixels that don't exist.

i think what you actually want is to render only the bit that you need:

   # calculate the upper left corner such that the small image
   # is centered in the large one
   my ($x, $y) = (
       ($splash_frame->get_width - $fade_image->get_width) / 2,
       ($splash_frame->get_height - $fade_image->get_height) / 2,
   );
   $fade_image->composite(
       $splash_frame,
       $x, $y,  # dest x/y
       # render entire *source* image's area
       $fade_image->get_width, $fade_image->get_height,
       $x, $y,  # offset x/y (see below)
       1, 1, # no scaling
       'nearest',
       $splash_counter * 2
);

using the same values for dest_[xy] and offset_[xy] gives me the right  
results with my test images, but by the docs and by experience with  
other APIs that do the same operation, it doesn't make much sense.  my  
gut tells me that i want to use 0,0 for offset_[xy], but i had to do  
this to get non-garbage results.  this may be something that's fixed in  
your version of gdk-pixbuf -- i don't get the same streaked  
extrapolations you showed in your screenshots.



> Problem 1:
> The first one is probably just my lack of understanding. What I *want*  
> is to have the background image remain 'static' in the background, ie  
> always completely visible. Then I want the $fade_image to fade in.

did you set the transparency color correctly in the fade image?  (e.g.,  
when you were saving from the gimp or whatever.)


> What I'm getting is *both* images fading in, and towards the end the  
> $fade_image masks out the background completely. This last bit is fine  
> - I understand that if I set the overall_alpha value to 255 it will  
> mask everything else. But why does the background image fade *in*? I  
> thought it would be completely visible from the start, and then fade  
> out while the other image's overall_alpha caused it to be masked out.

i'm not seeing this.  try again with more correct region arguments to  
->composite() and see if this still happens.


> Other than that, it's working :)


--
"the ternary operator makes it a bit less ugly."
    -- kaffee