On Thu, 3 Oct 2002, Marty Ross wrote: > We're using only a small set of graphics functions, such as might be named: > "setPixel(x,y,c)", "drawLine(p1, p2, c)", and "displayBitmap(bm)" (and maybe > a "fillArea(x,y,c)" fn).
We don't have an explicit "displayBitmap" but we do support "memory visuals" which make loading various image formats easier. > I'm trying to understand if/how we may benefit by switching to > GGI/framebuffer (or perhaps even just "framebuffer API", if there is such a > thing). There is a "just framebuffer API", yes. One benefit you might realize from running under GGI versus running under "just framebuffer" is that GGI has a set of software renderers. You have to write those yourself when programming directly to the framebuffer (or use another library like libart or embedded Qt and hope that it does not get in your way, as libraries of that type are slightly higher level than GGI and are intended for more specific purposes.) However, writing your own renderer is not much of a challenge if all your appliances are exactly the same, since you will not be confronted with multiple pixelformats and framebuffer layouts. Another benefit is that GGI will allow you to perform the application development in an X windows environment on a high-end desktop, and then to simply move the binary over to the appliance and run it there for final QA. > Is framebuffer support builtin to RedHat 7.2? Yes, "framebuffer API" is built into the kernel, not the distribution, as long as the kernel is compiled with the right options. In the other sense, I guess GGI is also "built in" to RedHat because rpms are available (don't know if they are included by default as I use Debian personally.) > Will the resource consumption (memory/disk/CPU) likely be smaller if we > switch to GGI/fbcon? Or GGI/some-other-lower-layer? svgalib is pretty slim, IIRC. If you were willing to invest some time into pairing down GGI (by default it installs a lot of modules, but it is modular so you could strip out the modules you don't need on the appliances themselves) you might realize some disk savings. CPU depends on what your app does and how often. > Is there likely to be better support for dual-headed applications? Than SVGAlib, yes. But don't get your hopes too high, you'll still have to work at it a bit. The easiest scenario would be if your hardware base does not consist of a large variety of different video cards, and the cards you have are of the right models. > Thanks for any answers or pointers you can give! There are plenty of docs and stuff linked off the GGI homepage, but my recommendation to anyone who knows C is to download and build the library, and then play with the programs under ggi-core/libggi/programs/demos, especially demo.c, which are well documented and demonstrate both good and bad GGI program practices :-) You learn the what, why, and how of LibGGI quickest that way. -- Brian
