From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA20680; Fri, 12 Oct 2001 17:02:02 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA21191 for ; Fri, 12 Oct 2001 17:02:01 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f9CF21j01350; Fri, 12 Oct 2001 17:02:01 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA21170; Fri, 12 Oct 2001 17:02:00 +0200 (MET DST) Date: Fri, 12 Oct 2001 17:02:00 +0200 From: Xavier Leroy To: Berke Durak Cc: caml-list@inria.fr Subject: Re: [Caml-list] Some suggested improvements to the Graphics and Bigarray modules Message-ID: <20011012170200.G18676@pauillac.inria.fr> References: <20011009233142.A10140@gogol.zorgol> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20011009233142.A10140@gogol.zorgol>; from berke@altern.org on Tue, Oct 09, 2001 at 11:31:42PM +0200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 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