kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Dick Hollenbeck wrote:
> Jonas Diemer wrote:
>> Hi,
>>
>> 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 
>> hard...
>>
>> -J
>> 
> 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 :)

Wayne

> 
> Dick
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 
>