- From: "Greg Haerr" <greg censoft com>
- To: <gtk-devel-list redhat com>
- Cc: <mcrichto ecs umass edu>, <otaylor redhat com>
- Subject: Re: Framebuffer port of GTK/GDK !! (long)
- Date: Tue, 28 Mar 2000 23:36:50 -0700
Hello, I'm the lead developer of the Microwindows Project, http://microwindows.org, a graphical windowing system primarily intended for embedded Linux-based systems using the kernel framebuffer interface. Owen Taylor kindly prepared a critique of the project, and I wanted to respond and give more input on the critique. We are very interested in a GDK/GTK+ port and have had quite a few folks ask about it. I'm not subscribed to the gtk developer list so please cc me with any replies. Note: this email is long; press delete now if off-topic. : > On 03/23/00 Owen Taylor wrote: : > > MicroWindows/Nano-X is a much more active project. But, I was not : > > particularly impressed with the code, the amount of documentation, or : > > the APIs when I looked at a few weeks ago. It struck me as an attempt : > > to write a windowing system done by people who weren't all that : > > familiar with windowing systems. It inherits many of the limitations : > > and bad parts of the X design, without necessarily inheriting all the : > > good parts. : > > : > > (Caveat: perhaps the lack of documentation and the ugly header : > > files have prejudiced me against the system.) The Nano-X system was originally written by David Bell in 1991 called Mini-X and was a very small X-like server written for the MINIX system. The Nano-X api looks like GrXXX and was designed by Bell. Alan Cox then took it, hacked a framebuffer interface from BOGL onto it, and gave it to Alex Holden, who named it NanoGUI. There it sat, as 0.1, which didn't run at all, until I came around, and decided that it could be used as a base for a small graphical environment, running on framebuffer. The only problem was, it didn't have a well-defined architecture, and wasn't modular. So I started a now nine-month project redesigning it. I happen to be a Win32 and X Window System programmer. A complete rewrite has occured, EXCEPT for the Nano-X API portion. The first was a very clear distinction between an "engine" layer that performed api-dependent drawing functions, as well as a well-defined low-level interface that provides easily replacable drivers for the screen, mouse/touchpad, and keyboard. Drivers were written for 1,2,4,8,16,24 and 32bpp framebuffer, X11, hardware 4-planes VGA, SVGAlib, and other low level screen device interfaces. Mouse drivers were written for raw serial port, GPM, vr4171 and new kernel-based touchscreens. The driver interfaces allow the Microwindows system to run on Linux, UNIX, X11, MSDOS, RTEMS and others, as well as MIPS, ARM, PowerPC and x86 cpu's and associated devices. The "engine" layer API looks like GdXXX. It's purpose it to provide device-independent drawing with full arbitrary clipping regions and a single RGB color model across all ranges of output devices, pseudo color, truecolor, palettized, grayscale, as well as portrait and landscape mode x/y coordinates for differing displays. Although there's more work to be done, this portion is well designed, highly portable, and relatively fast. No, the polygon fill and outline code isn't up to X's level, but it works and can be replaced when the time comes. Same for ellipses. The important thing is that the core capabilities, including arbitrary y-x-banded region clipping, a color model, and blitting (srccopy, constant-alpha blend, etc) are there. Actually, I'm in the middle of a major enhancement in this blitting area. We've also recently completed the first round of adding Adobe T1 and Truetype font rendering support with antialiasing, scaling and rotations completed. (ok, bear with me, hopefully I'm not putting everyone to sleep :) The next piece was a creation, from scratch, of an exact Win32 GDI API on top of this engine. Yes, there is name confusion and this is called Microwindows. I felt there was a need for a small graphics environment that implemented the Win32 graphics-only api. This API is implemented EXACTLY in terms of API signatures and user-modifyable structures. The font and color models are taken from the Win32 api, rather than X. Ok. Now, most Linux programmers could give a damn about Windows systems or APIs. So I kept up the Nano-X api, and made sure that it worked well with the engine. As a result, alot of folks started writing applications for both the X-like Nano-X api, as well as the Win32 api. In truth, the Nano-X api is way behind the Win32 api, for alot of reasons. One is, it isn't X nor Windows, and is something in between, which, as Owen points out, sometimes has bad features of X. But it is id-driven, uses the X-based GC concept, however uses the superior RGB color model (for consistency, not flexibility). Since Win32 includes built-in window management, I wrote it implicitly in the API implementation. Nano-X doesn't have any window management, inside or out. Well, thats some history. More comments follow Owens' critique. : : I guess the biggest problem I'm having right now is that there are : effectively no docs, so I don't really know what the interfaces are : for the basic library and for nano-X, and I have to try and figure out : what is public and what is not in the header files. There only one public header file for Nano-X: microwin/src/include/nano-X.h All routines start with GrXXX. There's a (incomplete now) detail of the Nano-X api in microwin/doc/original_mini-x.txt. : : > Maybe the windows-alike windowing library could be a better choice : > for the porting, but I know nothing about win32, so I'll let others : > try that route:-) There is some truth to that, but I think that the Nano-X api should be used. : : NanoGUI critique: : ================ : : * Name confusion. MicroWindows, NanoGUI, NanoX, etc. : : It's very hard to keep track of what is what. You won't get : people to write to an API unless you can present a clear, : unified picture. : : In fact, I doubt the double-API system that MicroWindows has now is : a good idea at all. They should just pick one or the other, having : two is just inviting confusion. At this point in the project, Owen makes a good point. We're working on real documentation. : : : * Lack of documentation, and an apparent lack of principles for : how things should be designed. We are extensively haunted : in GTK+ now by some of the careless design decisions that were : was made early on. It's even more crucial for a windowing : system. I'd be interested in more details of your GTK+ experience. : : Where are the API calls documented? Which calls are part of the : API and what is internals? What are the semantics of the : drawing calls? (X typically specifies which _pixels_ will : be drawn, and when that is not defined, clearly states.) : : (The Architecture document on microwindows.censoft.com is something : but falls short of careful documentation of the interfaces.) I wrote the Arch document to try to get a bigger view out, but, Owen is correct, the only Nano-X api doc is original_mini-x.txt. The Win32 api is exactly the same as M$, and is doc'd all over the place. : : : * API ugliness : : I actually consider having "nice" API's to be pretty crucial. : This is one of the things that has really helped GTK+ and GLib - : nice "pretty" APIs. The Micro/Nano* APIs fail on this regards. : : - There is extensive namespace pollution. (A failing also : of Xlib) Use a namespace prefix and stick to it I agree. : : typedef COORD GR_COORD; /* coordinate value */ The reason for this is that, currently, the upper level APIs "inherit" certain typedefs from the device level, which permits the entire system to be compiled and run very efficiently on known hardware platforms, using as little RAM as possible for certain structures. : : (Actually, the failing here is at the device level, not : the library API level, but there is plenty of pollution from the : included header files) Agreed. Actually, I don't like the ugly GR_XXX nano-X convention. I am working on the device side of the equation; for simplicity, too many symbols are exported and shouldn't be. This was originally done in the name of "simplicity first, optimization second." Maybe it wasn't the right choice, but isn't a hard thing to fix, actually. : * The nano-X API, which is supposed to be "X-ish" is gratuitously : incompatible in many places. eg: : : void GrSetCursor(GR_WINDOW_ID wid, GR_SIZE width, GR_SIZE height, : GR_COORD hotx, GR_COORD hoty, GR_COLOR foreground, : GR_COLOR background, GR_BITMAP *fbbitmap, : GR_BITMAP *bgbitmap); : : The X API has a bitmap and mask, not fg and bg bitmaps So does Nano-X. This call works just like X, but I never changed the original Mini-X definition. Actually, I think I rewrote it to use bitmap and mask, but didn't change the definition. : : * Parts of the API are perhaps a little random. For instance: : : void GrBMP(GR_DRAW_ID id, GR_GC_ID gc, GR_COORD x, GR_COORD y, GR_SIZE width, : GR_SIZE height,char* filename); : void GrJPEG(GR_DRAW_ID id, GR_GC_ID gc, GR_COORD x, GR_COORD y, GR_SIZE width, : GR_SIZE height, BOOL fast_grayscale, char* filename); : : BMP and JPEG are not exactly the best image formats out there. : Image loading should almost certainly be left client side. This was discussed on the list, and was put in for speed reasons. But I have a config option to compile it out. : : I get the feeling in some places that the Micro/Nano* API is "small : subset of X and Windows plus random extra features that were easy : to implement". Yes, sometimes that was true. But the Windows API implementation has been gone thru with quite a bit of thought and study. It's now time for the same with the Nano-X api. : : * There seems to be no attention to race conditions - for instance, : there is no way of correlating expose events with CopyArea : calls. There's quite a lot of discussion that needs to take place on this subject, in regards to simple vs complex expose/drawing semantics. It get's even more complicated when you have to make a decision on whether we want to try to emulate a given upper level widget-set's behaviour and programming. I've tried to keep it simple, since there's no future in re-writing X, IMO. : : * The Nano-X lib seems to mix the drawing commands together with the : main loop into a single unit; this violates the separation of labor : that every X toolkit relies upon. This is true for the sample distribution. There's a set of functions in Nano-X that allows the entire library to be used as a toolkit, with the application completely handling it's own main loop and select()'s, and calling auxillary functions to let the graphics routines do their thing. (GrPrepareSelect, GrServiceSelect, et al) : : * Some bad parts about X are preserved; to list a few: : : - Ellipses turned out to be nightmare to implement and get : right in X. The right thing to do is to do beziers and approximate : ellipses with beziers : I'd really like to talk with you about your experience in this area. I'm trying to do it the right way with Microwindows. : - Window borders in X are basically X10 legacy, are are universally : not used. Yep. We don't want to use them in nano-X either. : : [ There is a paper "Why X Is Not Our Ideal Window System" : Software Practice and Experience, Volume 20, #S2 which has : some useful commentary about problems that the X implementors : found over time. ] Online url? : : * The font API has no ability to make a character/glyph distinction. : There are quite a few languages that to handle properly, this : distinction needs to be exported to the client. The font support is new. We'd be happy to make changes in this area. : : The font API also seems to be very unclear about how it handles : font styles and there is no way of getting a list of available : fonts as far as I can tell. : Yes, we still don't have enumerations. Currently, font selection is too simple, the client has to specify a "name", which translates currently to a filename. This needs enhancement. However, we do have the rendering working quite well. : I guess the lack of docs and the lack of clear interfaces bothers : 'me most. "Lack of docs" may sound hypocritical coming from one : of the GTK+ maintainers, but we've found out the hard way that : when you don't document, you are creating problems for yourself. Owen, thank you very much for your critique of Microwindows. I appreciate the serious inspection you've given our project. I'd like to work to getting a GDK/GTK+ port though. Would you like me to take a pass at getting an alpha version running? Although Microwindows is nowhere near done, it's at a point where the experiences learned in getting a well-designed widget set ported would be a good thing. We've got FLTK running, although there's lots of issues. FLTK has a poorly designed interface between the widget set and the windowing system, meaning it entirely lacks the GDK layer. As a result, we have to have identical semantics to X or Win32 or there's trouble... Regards, Greg