bitmaps, portability and the Universe

[Martin Wierich]

Hoi Jerzy,

Jerzy Karczmarczuk wrote:

> Please, I don't want you to change your priorities. There is plenty
> of things I *can* do myself, and I am willing to do that (one day...)

and later:

> Once more. I do not demand that you implement this or that. I *ask*
> whether an ambitious user could do something.

Yes! Of course you can do so. And even more you could offer your implementations to the rest of
the world. On the Clean web pages there are already libraries present written by non Clean team
people. And everybody can use them. But I guess you need some backgound information to get
started, right ? So here it is: Take a look at the osbitmap module. The module's name begins
with "os" because it is platform dependent. Under Windows you have the following type (version
1.2):

  :: OSBitmap
   = { originalSize   :: !(!Int,!Int)  // The size of the bitmap
     , reSize         :: !(!Int,!Int)  // to store values passed to resizeBitmap
     , bitmapContents :: !{#Char}      // The (device independent) bitmap information (for
printing)
     , bitmapHandle   :: !Int          // The handle to the screen bitmap (for screen)
     }

The most important fields are "bitmapContents" and "bitmapHandle". Windows can store the image
of a bitmap in a device independent format (stored in bitmapContents) and it can transform this
representation into a device dependent format (stored as a handle in bitmapHandle).


> Only ... I stil don't have my answer! Why cannot I treat a bitmap
> as a strict, unboxed array, and have the access to all the pixels?

The bitmapContents field gives you access to all the pixels.

Extending the I/O facilities of the Object I/O library involves some work with it's low level
modules, but in principle "everything can be done". I recommend the book "Programming Windows
95" from Charles Petzold.

> I asked simply whether such low-level (pixel-wise) operations are
> portable (i.e. written in Clean) or not.

You see that some operations are _not_ portable, although they are written in Clean. The
OSBitmap type and all involved functions are totally different under MacOS. As soon as an
operationg system C function is called portability is lost. But of course on a higher level
platform independentness is regained.

If you seriously consider to extend the I/O system then mail us before (not via the
clean-list), we might have some information for you. And we really prefer implementations that
are available on several platforms, although Clean is loosing this property more and more
(Windows seems to be the winner again).

greetings
  Martin Wierich
  University of Nijmegen