On Thu, 24 May 2001, Brian S. Julin wrote:
>
> On 23 May 2001, Tijs van Bakel wrote:
> > #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?
>
> Well, more accurately, having blt ops will help solve the problem, and
> we'll be using batchops to access blt ops.
Exactly. IMO a pseude-target for libblt is the right way to do that.
It works the same way as libggi's sub-target with the difference
that libblt's scale-target provides scaling instead of a "sub-window"
on another visual.
> > 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?
>
> Check the db struct in the visual, that should say whether directbuffer
> access is there. The problem, though is that you have more than a
> simple bitdepth conversion; you also have a conversion between different
> pixelformats (RGB, BGR, 565, 555). Palemu had a very narrow purpose,
> so it did not have to deal with so many variables.
Inside the scale-target from above, you can ask libgalloc for the
storage and the _exact_ layout of each buffer.
> > #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?
>
> I think filter, which now is just another name for an input. Altering
> the filter-mouse to take simple translations via load-time options,
> instead of loading from a config file, would allow display-scale to
> open it as an input and get it to do what it needs.
Agree fully here.
> > #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.
Yes. We can add a BLT_DISPLAY env variable for libblt. Then you can
do BLT_DISPLAY="scale", which forces libblt to "render" on a default
visual through the scale-target or you can do BLT_DISPLAY="scale:X",
which forces libblt to "render" to the X-target through the
scale-target.
> All I'll say on this for now is that I'm keeping in mind stuff like
> this with the batchop/super-renderer stuff we talked a bit about on IRC.
Agree. We can start working on it as soon as libblt has a stable
API...
> > #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?
>
> I'm unclear as to what you mean here.
Me too.
> > #6 anyone interested in a rotozoom target? :-)
^^^^
What does "roto" mean? "ROTatiOn"?
> I sure someone would think it neat.
If I guess right, then it should be a pseude-target, too.
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
