On Sat, 11 Mar 2000, teunis wrote:
> [on reimplementation of libGGI2D]
>
> On Fri, 10 Mar 2000, Andreas Beck wrote:
>
> [clip]
> > - There is an urgent need for 2D drawing functionality by several groups.
> > - LibGGI2D is unmaintained and doesn't carry the usual GGI License.
> >
> > So please - those who need it: Get together and rewrite it. Specify all
> > your needs and make a header-style proposal.
> >
> > A few proposals to get you started:
> >
> > - ROP 256
>
> What's this mean?
Microsoft's Win32 ROP256 standard. Look in any windows
programming book.
> > - arbitrary length patterns for lines and background.
> > - ggi2D equivalents of all LibGGI drawing primitives that obey the extended
> > markups above.
> > - triangles, trapezoids (PM2 can accelerate aligned trapezoids) polygons,
> > arbitrarily positioned ellipses and arcs
> > - rounded-edge rectangles ?
>
> special case of circle draw. Really quite simple.
>
> > - spline/bezier shapes ?
>
> Okay a little more complicated. Okay a lot. Look how Java 2.0 handles
> this one it's not too bad...
>
> > - streched (Cross-)blitting.
>
> Frequently accelerated. BITBLT's are almost -always- accelerated though.
>
>
> I would -love- to see a pipeline proposal:
> how to handle rendering pipeline. AKA OpenGL's specs :)
You have already seen mine, it is LibGGI3D
> I'm not saying OpenGL is the best way of looking at things... but that
> style's quite suitable to most accels + most libs.
>
> something like:
> [complex command]
> -> handle clipping; can insert "stencil" bitop to for this...;
> -> [select bitop]
> -> [run series of render-ops]
>
> I dunno.
The GL state-machine thing is designed the way it is because it
was designed to be embedded into hardware. 2D hardware acceleration is
not nearly as consistently designed as 3D hardware, usually it is a
crazy-quilt of different ways to do things. The only stuff that's really
common is the 8514/A style 2D accel set. What this all means is that,
unlike GL, we don't have a nice abstraction of a rendering pipeline to
stuff everything into. We have to tune the nature of the pipeline code to
the hardware in order to optimize it, and having one standard type of 2D
graphics pipeline would be too restrictive. X is a good example of why
this is bad.
> bitop -> eg. AND/XOR/OR/... + bitmasks...
> renderops -> simpler render commands that are usually acceled. Like
> lines. And points. And rectangular fills... And BITBLT's.
Multisource blits with generic and extensible ROPs can take care
of most of that stuff.
> (and the only request I have for clipping is... Be able to handle
> stencils and rectangular clipping regions.... and be able to draw onto
> stencils :)
Sure.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
