On Thu, 8 Jun 2000, Christoph Egger wrote:
>
>
> On Wed, 7 Jun 2000, Jon M. Taylor wrote:
>
> Hi!
>
> I've just waited until your updates are in the snapshots.
>
> > This is kind of a long post. You may want to skim or skip it if
> > you aren't into LibXMI development or 2D graphics.
> >
> > The pixel pipe portion of LibXMI seems to be up and running fairly
> > well now. Texture mapping (and tiling) is working, as well as the alpha
> > blending that people have been wanting for a while now in GGI. It ain't
> > too fast just yet (unaccelerated), but it works properly. I've got types
> > made up for every kind of blending/testing operation I can think of:
> >
> > * ROP256
>
> What is that? I have no book about any Microsoft-Product.
ROP256 == 8-bit ternary logical raster operation. The high and
low nybbles hold the logical operation codes for blending
src1->src2->dest. The codes are not defined yet for XMI, but they will
probably follow the Microsoft GDI scheme (miRopSrc, miRopAnd, miRopNAnd,
miRopNot, miRopDst, etc).
> > * Colorkey (transparency)
> > * Texture filter (pixel multiply, bilinear, anisotropic, etc)
> > * Alpha blend
> > * Alpha test
> > * Stencil mask
> > * Z-buffer update/test/mask passthru (Here you go Christoph)
> > * Multitexture blending with an arbitrary number of stages
> >
> > Not all of these are implemented yet |->.
>
> Well, I look through your polygon-code, and I think the z-buffer stuff is one
> of these, right?
Yes. Implementing that will be a challenge. We will have to have
a different z-buffer blend target for each target _and_ extension which
has z-buffer support.
> Aehm, why you don't remove all malloc() and free() -calls out of the
> polygon-code? This calls makes the polygon-drawing-code very slow.
I haven't yet had the courage to do much structural repair work on
that ancient X consortium code. But you are correct, there is way too
much dynamic memory thrashing taking place. We should be preallocating
some working memory buffers and re-useing them instead. X did (does?
say it ain't still so!) things this way because RAM was a lot more
precious back in the day. Especially in those networked X terminals,
where you don't have VM swap to disk to fall back on. In such an
environment, you have to be fanatical about malloc()ing only what you need
and freeing it as quickly as possible after it is used.
Cache management is also a must in such an environment, to avoid
any unnecessary copies and thus reduce the need for intermediate buffer
space to be malloc()ed. The original GNU LibXMI code _did_ have support
for persistent ellipse cache objects, which I removed because it was being
used by reentrant versions of the ellipse drawing functions and it was
making my brain hurt trying to debug. If we ever gets around to
re-implementing the XMI primitive cache system, we should probably
implement a more weakly typed system, where you don't have separate caches
for each primitive type exposed at the API level. Let the target code
decide where to store the cached data, how to apply cache management
policy, what the optimal cached data formats are, etc.
But this all still assumes that we are better off exposing the
cache management through the API _at all_, as opposed to handling it all
internally at the target level. The target code knows what usage costs
various resources under its control have, and therefore how to weigh cache
policy to compensate. The application level should never have to care
about such target-specific things. OTOH, the application level also has
information which should be used to tune cache policy - it knows what the
useage pattern of the cached object will look like (well, moreso than the
target code does |->). Thus, the application needs to be able to pass
cache policy hints to the target code. Perhaps the answer is that we need
a separate extension library dedicated to managing caches of rendering
primitives. I don't know.
> If I read your code correctly,
^^^^
Most of the XMI stubs code isn't mine. It comes from the original
1987-era X11 consortium codebase.
> you are using a left and a right edge table for
> any kind of polygon.
> Make a malloc()-call in xmiAttach() and a free()-call in xmiDetach().
Yes, this is what will be done.
> The malloc()-call allocates enough memory for each scanline (depends on the
> current visual->virt.y).
As big as the framebuffer? That's a bit overkill when most span
sets will probably be for smallish GUI elements.
> You have to check at every miFillPolygon()-call, for
> the case a ggiSetMode()-call is made by an app. Then you have to resize it.
I'd rather use a smaller DirectBuffer-mapped buffer cache. No
need for all the overhead of a ggi_visual which handles events etc which
we don't need here. All we need to do is malloc() some persistent
scratch/cache space which we can reuse with multiple different graphtypes
without any mode setting or dynamic memory stuff. We can map and remap
multiple DBs over different patches of the same cache memory.
> Believe me, this is much faster for unaccelerated.
I've seen _huge_ performance increases when running on a target
with accelerated hlines. I haven't compared write-combining, but I'm sure
it will also speed things up. The mga2164w Matrox stubs target code,
which I have been using recently with matroxfb and my G200, has both of
these and it screams through the XMI demos.
> Note: My 3dtk has an own bitmap_t-Type, which comes from an old development
> under DOS. It's similar to the ggi_visual. Your polygondrawer is much cleaner
> than the mine, but it is faster than your unaccelerated one.
Not my code, I disclaim all responsibility |->. That X consortium
code will sit in the stubs library code where it can't hurt anyone else,
and (hopefully) slowly metamorphose into a less crufty form. Either that
or be replaced someday |-/. If I had to sit down and code up the
equivalent of LibXMI from scratch, I would do a lot of things differently
for sure.
> I have also an special code for triangles.
That could be useful for 3D accelerated targets which don't
directly support drawing of non-triangle polygons.
> BTW: I will make a ground up redesign in the alpha5-developent-series. There
> will be the bitmap_t-Type replaced by the ggi_visual.
Again, I mention that the ggi_visual struct is too heavy for this
application.
> I am going to use your
> libxmi for the basic 2d-stuff there.
If so, you should also use the miPixmap type instead of a
ggi_visual for your bitmap_t. You'll have to use it anyway, since all the
blend stages take pointers to miPixmap structs as input parameters.
> > But I think I got everything important in the world of 2D (except more
> > powerful clipping, see below) accounted for. If anyone knows of any good 2D
> > drawing abstractions/blendmodes/buffer update/check/whatever in any other 2D
> > graphics APIs which I've neglected to snarf up for use in XMI, please let
> > me know.
>
> Have a look at Allegro (http://www.talula.demon.co.uk/allegro/).
I see that I missed at least rotation and antialiasing. I'll add
some types for those soon.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
