> I've finally gotten around to writing a scaled version of ggiPutBox()
> /* put the contents of 'buffer' on the visual at pixel (x,y);
>    the size of 'buffer' is (w * h), the resulting image on the visual
>    will be (scale_factor*w * scale_factor*h) */
> int ggiPutBoxScaled (ggi_visual_t vis,
>                      int x, int y, int w, int h,
>                      void *buffer,
>                      int scale_factor);
> Note that this is not a general zooming function, but a 
> pixel-doubling (or tripling, ..) routine, which should be fast.

I see. It's kind of a blitting thing, so maybe it should go into that
Libblit many here seem to be pondering.

> If anyone is interested, I could write some general zooming routines;
> but the following problem arises:
> Not knowing exactly where to put it, I placed this in the 'misc'
> extension, because that seemed to be the easiest way.

Yeah, but wrong. The misc extension was intended only for a few extras that
some targets have and as an example. 

I'd prefer if you would put it into the blit extension as said above. I will
send you LibBSE in a minute to give you a starting point. It might need
conversion to the new extension scheme, but that's not a big thing.

>  However, I'm not_ "overloading" ggiPutBox as found in libggi/display/,
> _but also the ones in libggi/default/;  How should I do this?

This works in exactly the same way. Nothing special about it. you just add
the directories and Makefiles and add a line to the configuration file.

The extension mechanism is generic and will allow to overload any library
that gets loaded by the primary LibGGI target.

The main hub that does all that stuff is the 

static int changed(ggi_visual_t vis,int whatchanged)

routine, like the one in libwmh/ggiwmh/init.c

Basically it iterates over all loaded APIs and loads the corresponding
extension library if available.

> The function I have now works only for 8bpp X, and I've placed it in
> extensions/misc/display/X/;  of course I should add routines for many other
> displays and bitdepths, but I couldn't figure out how to handle
> overloading the "default/" routines.  

See above. It's simpler than you thought ...

> A big switch-statement handling all bitdepths would be a possibility, but
> this would have to be copied over to all targets using the "default/"
> routines.

Yes. Such stuff (rendering) should only be placed in target libs, when the
target has special provisions to kind of accelerate the call or to make it
possible at all.

CU, Andy

-- 
= Andreas Beck                    |  Email :  <[EMAIL PROTECTED]>        =

Reply via email to