caml-list - the Caml user's mailing list
 help / Atom feed
From: Nicolas FRANCOIS (AKA El Bofo) <>
To: "Jun P.FURUSE" <>
Cc: Caml List <>
Subject: [Caml-list] Re: Problem with Graph module
Date: Tue, 18 Jun 2002 19:01:39 +0200
Message-ID: <> (raw)
In-Reply-To: <>

Le Tue, 18 Jun 2002 11:48:31 +0200 (CEST) "Jun P.FURUSE"
<> a écrit :

> 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".

OK. Now I have this simple problem : I can use Direct Rendering from X
with my Voodoo card in 15 bits, and correct color translation in 24 bits.
is that right ?
> 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
> translation.

Who said computer science is not an exact one ?
> 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 *)

Great. Thanks for the tip. Euh, and what if I have to test several colors
? Oh, yes, here it is :

let screen_from_color c =
  set_color x;
  plot 0 0;
  point_color 0 0;;
Right ? I'll try it now.

\bye, and thanks again.


                   Nicolas FRANCOIS
 A TRUE Klingon programmer does NOT comment his code
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     ` [Caml-list] Re: Problem with Graph module Jun P.FURUSE
2002-06-18 16:53       ` Nicolas FRANCOIS (AKA El Bofo) [this message]
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