#206 QwtKnob slows down application if it has more than ticks

[Anonymous]

If one create multiturn qwtKnob with total tick count more than 1000 it significantly slows down application during qt layout calculations and first painting.
The problems are in QwtRoundScaleDraw class in functions extent() and draw(). The second one is from QwtAbstarctScaleDraw. Extent() use all more 1000 ticks for estimation, but it realy needs only tick which is related to first turn. The problem with QwtAbstarctScaleDraw is the same, it tries to draw all ticks, but in reality it draws only ticks related to the first turn.

I have made some workaround for this problem. In extent() break was added, if angle for tick is more than 360. Draw() was reloaded in QwtAbstarctScaleDraw and breake was added for same condition. Patch is attached.

[Uwe Rathmann]

The performance issues are related to more or less silly code ( doing expensive value -> string translations before fast range checks - or simply bugs like a "||" instead of a "&&" ) that can be fixed without having to break binary compatibility.

In case of having tick counts in thousands the fixes should be good enough, while when being in millions the better performance of proposed patch might become a small factor as it avoids pointless iterations over the ticks. The reason why I didn't apply the patch is, that it makes assumptions about the order of the ticks, that are valid for the general case, but might break application code, where scale divisions are not build from standard scale engines.

Fixed in all branches >= 6.1