On Mon, 2 Sep 2002, Tomasz wrote:
> There is, however, one > more thing I'd like to ask: what is it that you call an "incremental loader"? Most graphics utilities available today read the entire image from a image file into an intermediate buffer, before converting it into the display's pixel format. Some image libraries like libpng allow you to read the image line-by-line, or in some other smaller unit. This is preferrable, because when you have a large image, you do not have to allocate memory to contain the whole image in the intermediate buffer, and your smaller buffer stays in cache so the loading proceeds faster. One of the objectives of the new library LibGPF which is under development here is to provide such incremental loading/conversion for all image formats. There is actually another use for the term -- certain image formats like GIF, JPEG and PNG store the image information in such a way that the first part of the file contains a low resolution copy of the image, and the rest of the file contains more data which increases the resolution of the image. This allows web broswers to quickly present the user with a viewable web page before all of the image data has actually been received. An example of this is presented on the PNG website at http://www.libpng.org/pub/png/pngintro.html in the section under interlacing. If your web browser correctly supports animated GIF images the image there shows the incremental loading process. > Besides, could you advise me on possible written references (available on the > Internet) to graphics programming, as understood by the ggi creators? > Specifically, I'd like to have an deeper understanding of such concepts as: > bit convertion, single-frame, blitting (can't see this word in my big > dictionary), framebuffer, direct access and the like. Right now the best we have in this area is the well documented demo code in the libggi source tree and of course the documentation at http://www.ggi-project.org/xmldoc/ggi-apis-core-libs.html. Eric Faurot, our documentation manager, is working on a basic GGI-centric graphics programmer's guide, but I do not know how far along he is with that project. I started to do such a thing a long time ago, but I only got so far -- that material is still available at http://mojo.calyx.net/~bri/projects/GGI/GGPG/gghpg.html. Most of the material there covers basics and the documentation about the GGI formalization of the concepts is not complete, but I think you will find it helpful. Under GGI we try to hide the details of bit-conversion, which we refer to as pixel-format conversion, from the user unless the user wants to do this part themselves. Bit-conversion is not a very complicated thing, but the number of permutations and combinations of possible conversions are actually pretty large. GGI provides the Pack/Map/Unpack/Unmap function set to abstract the process for easy use. You can probably find the information you need on "single-frame" by searching under the term "double buffering". The associated GGI manpage is ggiSetDisplayFrame. "blitting" is a technical term created (IIRC) by IBM. Often in source code or hardware documents it is abbreviated BLT or BITBLT. Blitting is basically the process of copying of a rectangular region of data from a source buffer to a destination buffer, with a lot of optional mathematical conversions including alpha, Z, "raster operations" a.k.a. ROPs, and of course the conversion between the pixel formats and the pixel layouts of the two buffers. Most often, the source is some data you want to display on the screen, and the destination is a rectangular sub-area of the screen. Since ggiCrossBlit copies data between two sub-areas of two visuals, each of which may have its own pixel format and pixel layout, this was a better name for the function that "ggiCrossCopyBox". ggiCrossBlit doesn't do the optional mathematical conversions, however, it only converts the pixel format. We are working on the ROPs, Z, and alpha support in separate extensions to LibGGI. The framebuffer is simply the word for the data that represents the final image which you see on the screen. Direct access simply means that the framebuffer can be mapped into the program's memory space, such that it can be directly modified using a C pointer address. Direct Access, which we call "directbuffer" is not available on many display systems, and when you use it you have to do all pixelformat conversions and pixel layout conversions yourself, so we recommend not using it unless you are willing to sacrifice some portability for increased drawing speed. The ggi manpage ggiDBGetBuffer describes the GGI DirectBuffer interface, and the ggi_directbuffer structure should be documentaed in the online HTML documentation. -- Brian
