On Thu, 8 Jun 2000, Jon M. Taylor wrote:
> 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).
Ah... TNX. I hope you will implement it less buggy than the Microsoft ones...
:-)
> > > * 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.
But at first we should knock out the dynamic thrashing of the polygon-code at
first (see below).
> > 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.
This is what I suggest in my last mail.
> 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.
Well, I think today this makes only on embedded systems really sense.
> 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.
That's a good idea.
> 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.
No. No separate extension for any cache-managements. The application should set
flags for every cache policy (like OpenGL handles flags) and XMI pass it thru
to the target.
> > 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.
Oh, sorry.
Question: Make this fact any troubles maintaines LibXMI under the
usual licence-terms of GGI?
> > 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.
OK.
> > 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.
No. See my other mail.
> > 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.
OK.
> > Believe me, this is much faster for unaccelerated.
>
> I've seen _huge_ performance increases when running on a target
> with accelerated hlines.
Yes, you are right. But what I meant, was comparing a
unaccelerated polygon-drawer using malloc()-calls within it and a
unaccelerated polygon-drawer without using malloc()-calls within it, that the
last one is faster.
> I haven't compared write-combining, but I'm sure it will also speed things
> up.
Yes, because the OSS need's CPU-time for any malloc() and free()ing.
> > 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 |-/.
*hehe*
> > 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.
Great.
> > 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.
Err... but your miPixmap (if it is yours :-) contains also a ggi_visual. So how
it is more leightweight than the ggi_visual?
> > 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.
TNX for your advice. I will think about that.
> > > 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.
Fine. But Antialiasing should be disabled by default, if it is unaccelerated.
I think sprites and something like that would also nice, but Andy has already
implemented it into libbse and libgbl. And IMHO should this stuff stay there.
Christoph Egger
E-Mail: [EMAIL PROTECTED]
