On Thu, 21 Sep 2000, Lee Brown wrote:
> Mr. Taylor wrote,
>
> > We do assume that readback is always possible and >consistent,
>
> Jon,
>
> Readback is consistent if getLength, getLine, and putLine are
> consistent (there's no need to do a get on a drawLine since a drawLine
> is monocolor).
Not necessarily. There are many places to trip up here which are
not at all obvious. For example, there is a well-known problem with
mixing hardware and software drawing accelerations (in this case clipping)
called Guard Band Clipping. If you mix hardware and software clipping
where the 2D coordinates of the clip region are ever calculated using
floating-point coordinates, you have to make sure that issues of precision
and cumulative errors, especially when mixing hardware and software
clipping, don't lead to the clipping region coordinates being subject to
off-by-one errors. With as much crazy floating, fixed and
integer-fractional math that is done in video hardware these days, you
often need to save a large amount of cached rendering state in order to
work backwards and keep everything 100% per-pixel with readback. In an
environment where cross-platform issues dominate, readback capabilities
_cannot_ be assumed.
> Who says these functions won't ever be hardware accelerated?
They are, in many cases. They are also not, in many other cases,
or they do but the implementation of lines uses wierd techniques like
short-stroke vectors with tail chaining (S3 chipsets). Some hardware just
doesn't have a framebuffer, either. Readback and per-pixel coordinate
consistency cannot be assumed once fractional or floating-point elements
become involved in the rendering algortihms on either the hardware or
software side. That's why "color key" as a hardware feature is now
commonly deprecated in favor of alpha/stencil buffers.
> A
> library as influential and powerful as GGI could turn heads in the
> hardware industry.
It already has.
> As a user, these functions fit in quite well (the code fits in
> well too) with the others. No need to look around in other libraries.
> To me it "completes" (a la Jerry Maguire) the set functions.
You must see the slippery slope inherent in that |->. We lose the
advantage of fine-grained componentry and abstractions at runtime if we
don't keep to a fairly religious stance on minimizing API bloat, most of
which arises from adding API functional capabilities that don't 'fit'
within a commonly-seen cluster of capabilities.
If you ever encounter any target environments which you want to
support with LibGGI that don't have per-pixel readback capabilities for
those linedrawing functions, you'll have to emulate that capability in
those targets or lose 100% cross-platform capability. If you have to
emulate something important in any significant percentage of your targets,
that's a fairly clear sign that you are trying to make your API do too
much.
LibXMI actually needs to resolve this issue as well. Currently,
some of the blending abstractions I've added require destination pixel
readback, and if I want to make the targeting API system for those
per-pixel shaders work consistently and cleanly ,I need to define what to
do if the target doesn't have that functionality. Chained targets with
shadow buffer management is the first solution that pops into my mind, but
it isn't an easy issue to solve cleanly. Not at all.
> In short, why not? I'll do the work. GGI doesn't lose anything, it only gains.
I'd be the last to dissuade you from hacking on GGI, but if you
really want to do this I'd hack LibXMI. It seems to me a much more
logical place to put pixel readback as an abstraction.
> > LibXMI
> I have only had a brief look at XMI. From what I have seen you
> have done a beautiful job with it and I will certainly take a closer
> look at it.
Great! Hope you like it, and suggestions for improvement are
welcome.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
