On Mon, 2009-01-19 at 10:27 +0100, Gunnar Sletta wrote: 
> Matthias Kleine wrote:
> > I'm not sure were to go from here. Earlier on you suggested using 
> > built-in graphic items, only. This isn't really an option for me, as it 
> > would mean adding another layer of indirection (objects which manage 
> > state of graphics items + actual graphics items) and would make the code 
> > hardly more readable.
> 
> That was primarily to verify that the bottleneck is the java 
> boundingRect() function. Are you new'ing QRectF's or are you caching 
> them from call to call?

I cache the bounding rects on the Java side. The boundingRect method is
basically a getter method for the field cachedBoundingRect.

> I'm out of ideas, sorry... As I said, it is a degenerate use-case ;(
> 
Actually I'm quite surprised that I am the first to notice this problem.
Moving several small items on top of a background doesn't sound that
unusual / degenerate to me.

I'm quite sure that it's the boundingRect calls that consume so much
time. At least that's what the profiler says. Unfortunately, I do not
have much time to experiment now, but I'll see later on whether using
built-in graphics items / caching things on the C++ side does help.

Regards,
Matthias

_______________________________________________
Qt-jambi-interest mailing list
[email protected]
http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest

Reply via email to