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

bug in clim:draw-ellipse?

   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)

	I am not sure whether clim:draw-ellipse* and all related functions work
	properly if you try to draw an ellipse with its axes NOT (!) aligned with
	the coordinate axes.

     The X Window system doesn't support drawing rotated ellipses, so even
     though you can specify one in CLIM we can't necessarily draw it.

   I think the questions was if CLIM supported it, or not, not if X did.
   Could the CLIM policy on this be clarified?  Here are some possibilities:

Well, I am not in a position to set CLIM policy, but let me turn this
around and ask for your input.

   1.  You can specify things in CLIM that may not work in the port your
   clients care about.

   2.  If you specify something in CLIM that the underlying window system
   doesn't support, don't expect it to work.

   3.  CLIM should do this, but it's much harder because the underlying window
   system doesn't support it easily, so i'ts a bug, and you'll have to wait.

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?

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?

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.

   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.

   5.  If your CLIM application doesn't work in one window system, try
   another.

   I realize there are hard technical reason why certain things don't work,
   like rotating and scaling fonts.  But it would help if there was some way
   we could predict what wasn't going to work.

0,,
Follow-Ups:
Main Index | Thread Index