Subject:
Re: [FLTK] FLTK on Microwindows
From:
"Greg Haerr" ####@####.####
Date:
18 Mar 2000 20:55:33 -0000
Message-Id: <05fc01bf911a$b1123180$15320cd0@gregh>
Bill Spitzak wrote:
: This project itself looks quite amazing! Although being advertised as
: designed for embedded systems, maybe this could be the long-anticipated
: replacement for X? It already does transparency, apparently! And if it
: copies the Win32 font routines it will be way ahead in font handling.
: Also modern "embedded" systems are much more powerful than the machines
: X was originally designed for, there is no reason the graphics system
: has to be the bloated mess it has become.
Thanks for looking at the Microwindows Project. I'm the creator
and maintainer of it, and I thought I'd let you know what we're doing.
Microwindows is not trying to be a replacement for X, instead,
it tries to implement a modern graphics system for the embedded systems
running higher powered processors, which are starting to show up
in droves. Rewriting X is too much work and noone wants it anyway...
I'm just finishing adding FreeType (truetype) and T1lib (adode type 1)
font support to Microwindows. We're trying to merge the alpha blending
code that's in Microwindows already with the font rendering's need for
blending, and that's changing our lower level design a touch. Basically,
we're going to need three blitters: Copy, CopyTransparent, and AlphaBlend.
:
: A little worried about the combined Xlib and Win32 interface layers. I
: would prefer they adopted the best of each. From X I would keep the
: "ask for the next event" model of event handling rather than the
: callbacks used by Windows, since it is FAR easier to program the X
: model, and it works better over a network. I would also use a "set the
: current X" state graphics model used by X and OpenGL (and not the
: object-based "brush and pen" model of Win32). These two botches were
: the biggest problem with making fltk work on Win32.
Yea, some of Win32's DC stuff is a little strange, but we've got to emulate
it fairly exactly, which it currently does. However, the Nano-X (xlib) api
is not an exact Xlib replacement, and easier to use font and color api's
are being added. Nano-X uses the "set the current X" state graphics model
just like X, and it works well. So really, Nano-X stands to adopt
the best from win32 and xlib...
:
: >From windows (or just from basic programmer intelligence) I would copy a
: font model where a font has a SIMPLE name and all fonts can scale (there
: is ZERO reason for even the Xlib emulation to copy the horrid X font
: scheme, any Xlib programmer would be happy to replace that part of their
: code). I would copy most other graphics functionality from windows to
: ease porting of windows programs.
Our current plan is something like
GrSelectFont(family, name, size, style)
where the name is a text string that can be aliased at a lower level, but
basically
names the font, like "Times". The size is in pixels and the style includes
flags like italic, bold and underline. The family parameter is normally left
out,
but could include an override like "bitmap" to indicate a compiled-in raster
font, or "bitstream" to indicate a particular family when the name isn't enough.
A font handle is returned with the closest-matched characteristics, and the
specified height. Fonts can then be rendered at a degrees rotation, and with
or without antialiasing and kerning.
:
: And add some obvious things missing from either one: filled bezier
: outlines, with floating point coordinates.
I'm looking for a good routine for bezier curves, as well as one for
Chords and Pies. Of course, the X server may be the place to start.
We currently have ellipses and [filled] polygons, although the polygon
filling is fairly basic.
And put in a call that looks
: like fl_draw_image!
Yes, a couple of image routines are on their way.
Regards,
Greg
