caml-list - the Caml user's mailing list
 help / Atom feed
From: "Jun P.FURUSE" <>
Subject: [Caml-list] Re: Problem with Graph module
Date: Tue, 18 Jun 2002 11:48:31 +0200 (CEST)
Message-ID: <> (raw)
In-Reply-To: <>


I thank people who sent their xdpyinfo result.

> Le Mon, 17 Jun 2002 15:23:09 +0200 (CEST) "Jun P.FURUSE"
> <> a écrit :
> > Hello,
> > 
> > > if (point_color ma_fourmi.x ma_fourmi.y) = white
> > > is allways false under Ocaml.
> > 
> > If the following code says "BUG" in your environment, I am afraid that
> > there is a bug inside the graphics library. In such case, could you
> > send me the result of the command xdpyinfo in your environment ? 
> > 
> > (* ocamlc -o testgraphics graphics.cma *)
> > open Graphics
> > let _ = 
> >     open_graph "";
> >     if point_color 0 0 = white then 
> >       prerr_endline "OK"
> >     else prerr_endline "BUG"
> > ;;

I verified that this code prints out "BUG" when X display has less
than 24bits color depth. In such environment, the colour mapping from
Graphics to X is not one-to-one. This means that point_color may not
always return the exact colour which you drew on the screen. 
For example, in an X display of 15bpp, the Graphics colour 0xffffff
and 0xf8f8f8 are translated to the same X white colour. 
This is also true for the default white background color of Graphics. 
point_color returns 0xf8f8f8, not 0xffffff, this is why the above
code prints out "BUG".

In Camllight, the translation between Caml colour and X colour
performs communication between programs and the X server. Since it is
highly expensive operation, the colour translation of O'Caml Graphics
is rewritten, so that it would never ask the X server about
colours. It improves the speed of colour query impressively. 
Unfortunately, the both colour translation code do not return always
the same result. The different behavior of the Nicolas' O'Caml and
Camllight programs can be explained by this difference of colour

I think this does not mean the new colour translation of O'Caml is
buggy. Even in Camllight, the same things can happen, unless the colour
translation is one-to-one. (It happens less, but not never.)

The important things (which should be noted in graphics.mli) are that

  * you may get different colour index from one you draw, 

  * the colour indices predefined in Graphics for the basic colours 
    such as white, blue, red, etc can be just canonical candidate
    indices for them.

You should not compare these colour indices against the colours
got from the screen. For example, in Nicolas' program, instead of
comparing Graphics.white, we should use the colour index obtained
from the screen  at the begining of the program:

      let screen_white = point_color 0 0 
      (* this can be different from Graphics.white *)

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list:

  reply index

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-17  1:04 [Caml-list] " Nicolas FRANCOIS (AKA El Bofo)
2002-06-17 13:23 ` Jun P.FURUSE
2002-06-17 17:38   ` [Caml-list] Nicolas FRANCOIS (AKA El Bofo)
2002-06-18  9:48     ` Jun P.FURUSE [this message]
2002-06-18 16:53       ` [Caml-list] Re: Problem with Graph module Nicolas FRANCOIS (AKA El Bofo)
2002-06-18 23:13         ` Nicolas FRANCOIS (AKA El Bofo)

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

caml-list - the Caml user's mailing list

Archives are clonable: git clone --mirror

AGPL code for this site: git clone public-inbox