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

Re: bug in clim:draw-ellipse?

  Date: Mon, 21 Dec 1992 11:30-0500
  From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>
  Subject: Re: bug in clim:draw-ellipse? 
  To: kanderso@BBN.COM, York@lucid.com
  cc: clim@BBN.COM
  
      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.

This is truly great news, and i hope its true accross platforms.  I just
found that in Lucid, in ancient CLIM 0.9, in an application that draws
polygon's to make a map, the operation you describe, namely going from
sheet to device coordinates consed 20 mega bytes and took 10 seconds, about
20% of the entire time.

I can get the consing to go away by passing in fixnums rather than floats,
but the transformation still does more than it needs to, like scaling by 1
and rounding again.  I'd love to know how you did better transformations,
i've always thought they were important to be fast.
  
  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).
  
Good!  The current problem i have is outlining a filled polygon without
transforming all the points twice:

(let ((points (... 5000 points)))
 (draw-polygon* stream points :filled t :ink +green+)
 (draw-polygon* stream points :filled nil :ink +red+))


0,,
References:
Main Index | Thread Index