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

Re: bug in clim:draw-ellipse?

    Date: Mon, 21 Dec 1992 10:32 EST
    From: kanderso@BBN.COM

      Date: Fri, 18 Dec 92 16:58:53 PST
      From: Bill York <york%oakland-hills@lucid.com>

      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.  

Actually, CLIM would still need to use something to provide a mapping
from sheet coordinates to device coordinates.  This can either be
provided as an X/Y offset, or as an affine transform.  Bill can attest
to the fact that I was a vocal supporter of dumbing-down in this case;
I strongly wanted X/Y offsets.  However, I changed my mind when I
discovered that the fairly careful implementation of transformations
in CLIM barely shows up at all in performance metering.

The thing that does show up on performance metering is output recording,
and if you disable output recording, the code that eventually calls the
underlying window system is the bottleneck.  People who are very
concerned with performance can sacrifice a measure of portability and
call the underlying window system directly.

As a side note, I implemented the idea of a function that, when called,
generates a "fast drawing function" that can be funcalled later.  It
turns out that the "fast drawing function" was only marginally faster
than calling MEDIUM-DRAW-xxx (maybe 5% on Genera and the Xt-based ports).

      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.

I believe that D plus E constitutes the correct alternative.

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

Frankly, I think that A is a terrible alternative.  I do not subscribe
to the "least common denominator" approach to anything.

	 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.

It was a stupid bug in CLIM 1.1 that clipping (even to rectangles) did
not work.  It appears to work in CLIM 2.0.

0,,
Follow-Ups:
Main Index | Thread Index