gp:draw-lines

I've been optimizing some code recently by passing long sequences to
gp:draw-lines on large arrays instead of calling gp:draw-line for each
line. This works very well, but my sequences are sometimes so long
(up to 20000 elements) that I get a stack overflow.

So consider this an informal enhancement request to the Lispworks guys
to change the implementation of gp:draw-lines to a non-recursive one!

Regarding the recent optimization discussion: I think I can avoid
having to implement cluttering caching mechanisms by instead looking
harder into what my code is actually spending its time doing. For
instance, I discovered that I had been too sloppy setting the size of
one large and complicated drawn-pinboard-object. The consequence was
that there was a slight overlap with a frequently updated pinboard
object - which triggered a full redraw of the drawn-pinboard-object
instead of just a tiny redraw of one end of it. When I'm done
implementing the fix, I'm expecting reducing cpu usage (in certain
situations) to less than 10%.
-- 
  (espen)

Re: gp:draw-lines


On Dec 22, 2009, at 4:45 AM, Espen Vestre wrote:

> 
> I've been optimizing some code recently by passing long sequences to
> gp:draw-lines on large arrays instead of calling gp:draw-line for each
> line. This works very well, but my sequences are sometimes so long
> (up to 20000 elements) that I get a stack overflow.
> 
> So consider this an informal enhancement request to the Lispworks guys
> to change the implementation of gp:draw-lines to a non-recursive one!

I'll second that. I've had overflows with a couple of hundred lines or so.

LW

RE: gp:draw-lines

Hi Espen,

Apologies if this observation is not relevant to your case but if you are drawing 20000 elements (is that lines or coordinate tetrads?) how much of that is finally visible? I have a massive amount of data to process and draw (audio waveforms), but most of the time (unless I'm zooming in) I'm drawing from a summary of my data - essentially I down-sample it, leaving me with a general overview. This, by far, is what has given me the biggest speed up. I'm also using gp:draw-lines, passing a vector of values. I only use buffering to avoid flicker on XP, and to manage scrolling and damaged regions.

Chris

> From: ev@netfonds..no
> To: lisp-hug@lispworks.com
> Subject: gp:draw-lines
> Date: Tue, 22 Dec 2009 12:45:47 +0100
>
>
> I've been optimizing some code recently by passing long sequences to
> gp:draw-lines on large arrays instead of calling gp:draw-line for each
> line. This works very well, but my sequences are sometimes so long
> (up to 20000 elements) that I get a stack overflow.
>
> So consider this an informal enhancement request to the Lispworks guys
> to change the implementation of gp:draw-lines to a non-recursive one!
>
> Regarding the recent optimization discussion: I think I can avoid
> having to implement cluttering caching mechanisms by instead looking
> harder into what my code is actually spending its time doing. For
> instance, I discovered that I had been too sloppy setting the size of
> one large and complicated drawn-pinboard-object. The consequence was
> that there was a slight overlap with a frequently updated pinboard
> object - which triggered a full redraw of the drawn-pinboard-object
> instead of just a tiny redraw of one end of it. When I'm done
> implementing the fix, I'm expecting reducing cpu usage (in certain
> situations) to less than 10%.
> --
> (espen)
>

New! Receive and respond to mail from other email accounts from within Hotmail Find out how.