Hi,
I have hacked up a simple scale target, which currently only doubles
pixels. (Tripling and n*m scaling is planned, as well as continuous
scaling.)
A simple version which seems to work for me to scale 320x200x8bpp to
640x400 in both 8bpp and 16bpp X11 (the latter using scale:palemu, for
some odd reason palemu:scale does not seem to work (yet)), is
available from http://vengeance.et.tudelft.nl/ecfh/ggi.php3
I was facing a number of problems here:
#1 implementing all drawops is near impossible, given that there are
so many bitdepths to support and perhaps there will be new drawops
for, say, libggi2d. Perhaps batchops will solve this problem?
#2 i have copied this from the palemu target, and the core routine
looks something like this:
/* do transfer */
for (; h > 0; h--, y++) {
ggiGetHLine(vis, x, y, w, src_buf);
(* priv->do_blit)(priv, dest_buf, src_buf, w);
ggiPutHLine(priv->parent, x, y*2, w*2, dest_buf);
ggiPutHLine(priv->parent, x, y*2+1, w*2, dest_buf);
}
Obviously it would be faster if the do_blit had access to src_buf and
dest_buf directly, without having to do a GetHLine or PutHLine. It
seems reasonable that dest_buf can be both directbuffered or not, so
I would have to support both cases here. However, can I be sure that
the source buffer is always a memory visual? Or are there specific
cases in which one would have a non-directbuffered source target
here?
Either way, what would be the best way to test for being able to
access the source and dest directly? Which fields in the visual
should I use for this? (I could try myself, but some guru here can
probably help me out faster :-)
#3 the input mouse events have to be translated. Now I noticed that
ggiReadEvent() can not be overloaded. Do I have to build a special
input target or filter in libgii as well? If so, should this be a
filter or a target?
#4 (less important for now) What would eventually be a good way to
combine targets for optimization? I.e., the palemu and scale target
could be combined to do a 320x200x8bpp to 640x400x16bpp conversion in
one pass.
#5 (also somewhat less important) What would be a good way to make the
zoom functions available to library functions as well? Should the
target use library functions? Should these go in the default/
directory, or does this still belong in the display/ directory?
#6 anyone interested in a rotozoom target? :-)
Thanks in advance,
--
Tijs van Bakel, <[EMAIL PROTECTED]>
