Re: FreeType - A TrueType engine

[Johan Klockars <rand@cd.chalmers.se>]

> > What I would really like is a library that performs all the nice
> > stuff the graphics gurus do in their programs (blitting images,
> > dithering in various qualities, color management...) but don't

I think NVDI5 has such things built in and I plan to have a compatible
interface in fVDI sooner or later.
I probably have most of the necessary routines already from MGIF.

> > like to talk about.  In fact I've already started with such a library.

Who doesn't want to talk about those things?

You can find code for just about everything on the Internet and MGIF is
GPL nowadays if you want to have a look at the (usually fast) code in there.
(If anyone ever reqests those sources I'll have to add GPL notices first,
 but that can be done quickly if you just want a few of the files.)

> libmagick can do a lot of things. It's mainly made for X though, but
> can be used elsewhere too. Me and some others are making a graphics
> lib for Linux, oFBis, which handles the basic graphical things,
> bitblt, lines, pixels a.s.o. We've made a simple picture viewer that

fVDI of course has the same things, written in relatively well optimized
(at least for an '040) assembly.
Another place to look would be the sources to the W windowing system.

> > If this library shall ever run stable I will most probably need
> > help.  The biggest problem I currently have is the interleaved
> > format of some resolutions.  Am I right that this format is
> > only used for color depths of (1), 2, 4, and 8 bits (i.e. the

Yes.

> I have an assembler routine to convert 8-bit packed pixels (chunky)
> into 8 bitplanes. I got it from another guy, so I haven't looked into
> it much, but it works, and is fast.
> http://tomas.nocrew.org/stuff/c2p.tar.gz 

Do you have any speed numbers for that code?
I can't imagine that using tables for the conversion can be very good
compared to a proper 'bit-merge'. The Amiga people have been optimizing
this kind of code for ages (they don't have the equivalent of Falcon TC)
and they left the tables behind long ago.

My code in MGIF or Doug Little's very similar one in AtariQuake can easily
do a chunky to planar copy from Fast-RAM to ST-RAM at the same speed as a
straight copy on an AB040. Naturally, an '000 or '030 will be significantly
slower, but I'd be _really_ surprised if it didn't beat the code mentioned
above.
For one thing, it only reads from memory once (the actual chunky data).
The rest of the work is all done in the registers and the writes can be
interleaved with that to improve performance.

> > Another thing I've come across:  The Xlib specification distinguishes
> > between "TrueColor" and "DirectColor" visuals.  Can anybody
> > explain the difference to me?
...
> screen. In packed pixels or bitplanes, you have one index that points
> out a colour in a palette, but in Directcolour you have three
> palettes, one for each red, green and blue.
> 
> Please correct me someone, if I'm wrong.

That's how I recall Xlib Direct colour as well, but I may be wrong too.
Has any hardware every done it that way?

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johan@rand.thn.htu.se
                        | so hard to do |  WWW/ftp:  rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (MGIFv5, QLem, BAD MOOD)