kicad-developers team mailing list archive
Mailing list archive
Re: New zoom code musings.
Wayne Stambaugh <stambaughw@...>
Fri, 06 Feb 2009 10:16:33 -0500
Thunderbird 126.96.36.199 (Windows/20081209)
Dick Hollenbeck wrote:
> Jonas Diemer wrote:
>> 2009-02-06, 14:51:56 - Dick Hollenbeck:
>>> 1) I just tried a zoom factor like this and with my complex board the
>>> zone redraws were to slow, making this an unusable zoom factor for
>>> PCBNEW. (In fact the current zoom factor in eeschema head is closer to
>>> 1.2 and I have no objection to that because the redraw speed is fast
>>> enough.) As the redraw speed goes up, then the total time to zoom
>>> significantly is (redraw time x no. steps).
>> The slow zone redrawing during zoom is a problem per se. Even with the old
>> zoom factor, the zone redraw slowed down the zooming (although not to a point
>> where it becomes unusable).
>> Maybe the problem should be attacked from that angle: Reduce the redrawing
>> during zoom, i.e. don't do a complete redraw for every zoom step. There is
>> not really a point in continuing the drawing while the user has already given
>> another zoom command...
>> I haven't checked if/how this could be implemented, but maybe it isn't that
> Wayne will certainly be able to comment on this better than me, but your
> suggestion is a reasonable one. If zoom step requests are going through
> the event queue, then the event handler could process the event by doing
> the zoom math, and posting a time delayed request for redraw. If
> another zoom request comes in, if that time delayed redraw request has
> not been handled, then it could be cancelled and another zoom request is
> handled, etc.
> This design would hinge on the ability to cancel an event already posted
> in the gui event queue before it is handled, and the ability to put time
> delays into the gui event queue. A time delay could simply be a user
> defined event that causes the event handler to sleep. Don't know if
> wxWidgets supports canceling events already in the queue.
I believe this could be done. The real question is should it be done.
I'm guessing that implementing this would be complex, fraught with
unexpected corner cases, and difficult to maintain. I personally am
against all three of those. After I get the drawing code cleaned up, I
will revisit the zoom code. A cleaner solution would be to vary the
zoom rate proportionate to the mouse wheel rate. I've discussed this
solution here before. I would rather not have rewrite the zoom code
three times. Twice is more that enough.
> I'm spending too much time on this, bye.
I think I spent less time writing the code :)
> Yahoo! Groups Links