Re: [Caml-list] Some suggested improvements to the Graphics and Bigarray modules

[Xavier Leroy <xavier.leroy@inria.fr>]

> I'm doing some ``real-time'' video processing experiments with Ocaml
> (such as simple motion detection). I'm using the module Graphics for
> displaying grayscale images captured from a video camera. 

As others mentioned, it might be more reasonable to build on a
lower-level, more efficient library for manipulating bitmaps and pixmaps.
The original purpose of the Graphics library was for teaching: provide
simple line and text drawing primitives that would be portable across
X Windows, Windows, and the Macintosh.  It's not intended for maximum
performance, nor for generality.  (Although some users do wonderful
things with it, e.g. http://pauillac.inria.fr/activedvi/ .)

> The program
> spends a significant amount of time in Graphics.make_image, which, for
> every RGB value, looks up its pixel in a color cache.
> 
> First the color cache in otherlibs/graph/color.c is too small (512
> entries). So if I overlay my image with, say, red and blue zones,
> totaling more than 512 colors, make_image gets terribly slow (I spent
> an entire evening tracking out this mysterious slowdown). As a fix I
> set it to 4096 entries which corrected the slowdown (until I buy a
> color camera, that is).

Yes, this color cache machinery should be reworked.  We did a patch to
bypass it entirely in case of "true color" displays, but in general
the cache should grow dynamically.

> Second, it would be really nice to have an efficient interface between
> Bigarray and Graphics : a procedure for (quickly) converting either
> a m x n x 3 RGB byte array or a m x n byte array with a given palette
> into an image.

Yes, now that we have "true" integer matrices in Bigarray, it would
make sense to use them for Graphics' images.  One issue with Graphics
is that there are 3 different implementations (X Windows, Windows and
MacOS) that need to be changed simultaneously.  Needless to say, that
doesn't encourage us to extend the Graphics API :-)

> Third, I find that the coordinate convention (increasing y coordinates
> get you higher in the screen) is counter to current practice (CRTs
> scan from top to bottom ; matrices are also written from top to
> bottom).

We chose this convention to be consistent with mathematical practice.
This is a big plus for teaching...

> Fifth, and most important point (since I can't hack it myself) : I'd
> really like to see access to Bigarrays optimized. Currently, they are
> not (library call for each access).

Not quite.  With the native-code compiler ocamlopt, accesses to 1-, 2-
and 3-dimensional big arrays are expanded in line, *provided the
complete type of the big array is known*.  I.e.

    let f a x y = 1 + a.{x,y}

has a polymorphic type (int, 'a, 'b) Bigarray.Array2.t -> int -> int -> int
and compiles down to a library function call.  However,

    open Bigarray
    let f (a : (int, int_elt, c_layout) Array2.t) x y = 1 + a.{x,y}

is monomorphic and will be compiled much more efficiently by ocamlopt.

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr