| Thread Previous • Date Previous • Date Next • Thread Next |
Jonas Diemer wrote:
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.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
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'm spending too much time on this, bye. Dick
| Thread Previous • Date Previous • Date Next • Thread Next |
