[Drawkit] Much faster hit-testing (was: Re: Scaling issues)

[Graham Cox]

That's great news - nice to know that there is scope for this degree  
of improvement. I hope we can find a few others!

One thing to flag up is that this hit-testing method is currently not  
working with text and image objects. I'll fix this of course but be  
aware of it. These objects are still selectable once the selection  
rect fully encloses them, but the case of touching pixels is unreliable.

Also, to clarify something - when the selection rect is changing, only  
the changed areas are flagged for update, not the whole rect. When  
redrawn, the update is clipped to this difference, so even large and  
complex objects should update without too much delay. Of course, if  
you are dragging faster, the differential update area gets bigger, so  
speed will be somewhat dependent on the user's behaviour as well as  
the complexity of the shapes and their styles.

cheers, Graham


On 27 May 2008, at 4:31 am, Brad Larson wrote:

> I tried it out on the really large drawing I had going before.   
> Before, I would peg a CPU at 100% and cause it to beachball (all  
> work is done on the main thread, so no opportunity for second core  
> to take some of the load off) after selecting two large items.  With  
> the qUseScaledContext define (the default), the max CPU usage was  
> around 35%, with almost all of that being from the drawRect: method  
> (due to the refresh for the changing selection box).  The  
> qUseCachedBitmap define provided a boost in performance from what  
> was done before, but it still beachballed after selecting about 5  
> large items.
>
> Therefore, unless crazy selection artifacts pop up somewhere from  
> it, I'd say that the new default qUseScaledContext algorithm is by  
> far the way to go.  It makes a huge difference.
>