“X Windows and GTK+ are not the bloated monsters you think they are. Here’s how we modified GTK+/X for our device’s GUI.” Read the rest of the feature article at LinuxDevices.
Using GTK+ & X11 as an Embedded GUI
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Everyone who claims that X Windows and GTK+ are bloated are spreading FUD. They’re large, but not obscenely so. The real problem is that practical versions of them are bloated. Sure, X can be made to be quite small, but for a normal desktop that equals other OSs in functionality, you need XFree86 4.2 in all its bloated glory. The real reason things like QNX’s Photon are so cool is not that they’re small, but that they’re small yet incredibly functional.
2.9MB for X and GTK, severely squeezed down. Ok.
So lets look at a typical embedded device situation. Say a settopbox. Typical settopboxes mostly have 2MB or 4MB to store the complete OS, the core applications, all the bitmaps required, and so forth. And the core also does video overlaying, genlocking, and other functions. Compare.
Interesting experiment though. BTW is it just me or is that mock-up the Sonique PalmOS skin. I believe it is!
2.9 MB for GTK and X? If you call that small, what is then AmigaOS running in 512KB RAM?
Its nice to see that they managed to get it so small. I wonder if that thing will ever be in production or if it was just done to see if it was possible. Something to note though, is that 2.9megs is the size of the binaries, i dont know many binaries that can go in ram and not take more ram than the fileszie was. Creating structures and such in memory. In addition to the 2.9megs would be the linux kernel i suppose.
Hrmm, it seems to me that that device would benefit from a display that would not use a framebuffer. Framebuffers are soooo memory bandwidth intensive. ATI made a new graphics chip designed for PDAs, looks to be very nice.
To Dave Pourier and Raptor-32,about the UUU future GUI.
Quoted from Raptor-32: “we’ve begun porting (and i expect to be bashed here) Nano-X (http://www.microwindows.org), its X-like but uses very little memory.”
Could you please explain briefly why do you prefer porting the old Nano-X, instead of other minimal GUIs like the pointed on the article: OpenGUI, MiniGUI, PicoGUI? <a href=”http://pgui.sourceforge.net“>PicoGUI being the coolest of all of them inmho.
STAY AWAY FROM X please, you’ll envy the dead!!!> (:x
Thanks!
Thanks Raptor, I read the anwser at the whyLinux thread.
What’s X Windows? There is no such thing.
When an article mentions about X Windows instead of X, X11, or X Window System it’s not worth reading because the author has no idea what he/she’s talking about.
Tiny-X is part of the XFree86 distribution and you can compile Tiny-X from the source by enabling the KDRIVE option.
What it doesn’t say, is that KDRIVE is essentially for Linux only (unless you run it under full-X which defeats the purpose), as it uses Linux’s frame-buffer device (FBDev). This means you have to compile the Linux kernel with the appropriate FBDev drivers enabled. So, when calculating your memory savings, take into account you’ve basically taken the drivers out of XFree86 and put them in the OS instead. Nevertheless, Tiny-X does have many other memory saving enhancements.
Perhaps somebody can give me a round figure as to how larger the Linux kernel / OS footprint is with FBDev enabled.
Well, it look like they manage to make it smaller. GOOD. Most commentary comparing to other featureless GUI system (except QNX photon) whereas I think the author are thinking about the portability of currently available application.
If we think in term of desktop usage, it is worth to consider this situation since many that saying that “X ARE BLOAT”. In my opinion, it is true if they said it is slower compared to Window$ (I use it at little time for production purposes because of the lack of printing support under Linux), however you have to spent extra time to make it faster. My self built system from scratch on AMD K6-2 400 MHz are faster than standard distribution from Caldera, Suse or Redhat (I got several distrinution on separate bootable partition) on the same system and Mandrake on my office system of Pentium III 800 MHz. The secret is to use kdrive Xfbdev server. It far more better when using IceWM compared to KDE where KDE application running faster compare to running on KDE WM itself(but of course the font is not as beautifull as in KDE WM) Thank to Keith Packard.
Maybe a little more work may lead smaller and faster X binary. Uh I forgot to mention that currently I am running XFree86 version 4.3 which have smaller binary compare to 4.2
do you mean CVS developement build?
He.. Hee.. He….
Its also worth noting that Nano-X binaries are ~100kb, that includes a window manager, widget set, and a few applications. Maybe the size difference is caused by nano-X being only X-like and TinyX being an actual X implementation. XF86 is still a bloat in my opinion, if it wouldnt be they would be using it instead of tinyX, which they arent.
2.9 Megs is _not_ small.
As somebody else said, the Amiga A1000 managed a multi-tasking OS and
a full color GUI with windows, font selection, etc etc in a total of
less than 1 Meg (including the ROM). Although that original Amiga GUI
looks crude compared to a modern Amiga or other current desktop GUI,
it is of a suitable resolution (320×256) for a PDA, and better than
most PDA GUIs.
Likewise the first Macs had a WIMP GUI in about the same amount of RAM
(admittedly only a 1-bit display).
Starting from a big desktop OS and trying to cut it down is not the
way.
Don; you quote the Amiga OS as being an example of how an OS should be… Small enough to fit in a ROM!
I would agree entirely, and the tiny 512K Roms that held Atari’s TOS were an even better example. And it used SFA of RAM when running!