Hi Scott,
Qt4 does implement the
invalidate-subareas-and-then-update-widgets-asynchronously-later technique,
and that does make things faster. However, there is still the problem where
we have several large windows animating and then the user decides to open a
third large window on his other monitor... while the third window is being
created (e.g. while 2000-3000 extra widgets are being set up and arranged)
the first two windows will stop updating for a second or two (since the GUI
thread is tied up creating the new window and cannot attend to the existing
windows).
I've used Shark, and it helped me find some problems, but I think I've reached
point where I can't do much more in that direction without tossing out Qt
(which I don't want to do because it would cost me Linux and Windows
compatibility).
-Jeremy
On Monday 22 October 2007 11:29, Scott Ribe wrote:
> I just doesn't make sense to me that this should be a performance problem.
> I fill a 20" screen with mini-sized controls, and it happens instantly. I
> wonder, could your application be structured such that redraws are
> happening after each update of a control, rather than being batched after
> your code is done making a set of changes? Could that be how Qt works? Or
> how you're using it? I could explain to you how your updates should be
> processed under Carbon or Cocoa, but can't help you with Qt.
>
> I will suggest that you use Shark to figure out where the time is really
> going.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
