CLIM mail archive
[Prev][Next][Index][Thread]

Re: bug in clim:draw-ellipse?

  Date: Fri, 18 Dec 92 16:58:53 PST
  From: Bill York <york%oakland-hills@lucid.com>
  To: kanderso@BBN.COM
  Cc: clim@BBN.COM
  Subject: bug in clim:draw-ellipse? 
  Reply-To: York@lucid.com
  
     Date: Thu, 17 Dec 92 22:42:46 -0500
     From: kanderso@BBN.COM
  
       Date: Thu, 17 Dec 92 15:58:03 PST
       From: Bill York <york%oakland-hills@lucid.com>
  
  	Date: Thu, 17 Dec 1992 12:02:01 +0100
  	From: dp%cast.uni-linz.ac.at@lucid.com (Dietmar Pree)
  
   ...  
  Well, I am not in a position to set CLIM policy, but let me turn this
  around and ask for your input.
  
  ...
  
Bill, thanks for your careful reply.

  I take it that these three are all simply different "attitudinal"
  takes on the same basic policy, namely that CLIM implementations don't
  all necessarily implement the entire graphics model.  So, what do you
  think CLIM should do given that the graphics model (supporting affine
  transforms) allows you to specify shapes that can't be drawn in X?
  Some possibilities:
  
  A) Dumb-down the graphics model until it only allows you to specify
  things that can be drawn on all platforms.  I am not being flippant
  here.  If nothing else, we pay a performance penalty in supporting the
  coordinate transformations during drawing.  Should we have just
  punted?
  
Yes, this alternative is extreme perhaps, but not flippant.  For example,
when i'm drawing a map, CLIM's afine transformations just get in the way
since they're only linear, and they slow me down.  When i draw data on a
graph i do the transformation my self because i don't want the little
circles representing the data to scale up if the user zooms in ...
So, even if CLIM's graphics model worked, there are good reasons for not
completely using it.  

  B) Fall-back.  This is sort of what CLIM does now.  When a back-end
  encounters a graphic specification that it can't fulfill, it draws a
  shape that is as close to the shape you wanted as it can.  
  
  C) Punt.  That is, if you can't draw something right, don't draw
  anything at all.
  
  D) Allow programmer intervention.  I had once proposed that back-ends
  should signal a condition when they encountered an unrenderable case.
  Application programmers could then establish handlers that could draw
  alternative graphics, or punt, or whatever.  If there is no handler,
  the back-end can just do B) or C) above.  This never got implemented,
  but do you think it is a good idea?  How fine-grained should the
  condition space be?  UNIMPLEMENTABLE-GRAPHIC or a separate condition
  for each known rendering/ink failure?
  
A simple version of this might be good, so we know its happening.

  E) Documentation.  Vendors supplying CLIM back-ends should just be
  better about documenting which shapes can't be drawn.  This puts the
  burden on the application programmer to study up on all the platforms
  the application may be delivered into.
  
The problem i was having was being able to predict what part of CLIM's
graphics model i could count on.  Postscript (see the ghostview postcript
viewer for X) has a fairly complete model, and delivers it.  X has trimmed
down their graphics model for various reasons, and delivers it.  You can't
be sure about CLIM, until you actually try it.  Documentation surly helps.
My rule of thumb is, "If some part of the CLIM graphics model sounds hard
to do in X, don't expect it to work."  This is not particuarly bad, but
if this heuristic is going to remain valid for some time, then maybe we
should trim down the CLIM graphics model appropritely, so A) may not be a
bad alternative.

     4.  To be safe, do your own ellipse drawing.
  
  We really, really wanted to avoid implementing a graphics rendering
  engine as part of CLIM.  I guess that we therefore left it as an
  exercise for the user.
     
This sounds like another vote for A) (Dumbing down).  In addition to
drawing ellipses, and rotating text, another thing i've found i've had to
do myself is clip lines.  This is not a CLIM problem, alone.  I first ran
into this problem on LispM, before and after Genera.  At least in early
CLIM, line clipping did not work.  Now i'm faced with drawing filled
polygons and would like them clipped to a rectangle.  So, i have another
prediction problem, will it work?  I'd much rather have relatively simple
clipping to a rectangle that worked, than hairy clipping that doesn't.

k

0,,
References:
Main Index | Thread Index