Linked by Thom Holwerda on Wed 5th Aug 2009 00:12 UTC, submitted by rexstuff
Permalink for comment 377210
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
More News »
Sponsored Links



Member since:
2006-01-02
I don't need to look into the code and do a thorough reductionist analysis when the behavior is crystal clear: everything but Qt4 is slow on my system. If *everything* was slow, sure, blame the drivers. However, I find it very hard to believe it is just the drivers' fault if only one toolkit ever seems to have a problem. And if it is the drivers' fault, it's because the toolkit is making use of edge cases which the other toolkits can clearly get by without using and Qt4 should do the same. Again, don't need to look at code to know the correct answer here.
It should not take noticeable amounts of time to redraw a section of a double-buffered window during an exposure event. I don't need to look at code to know that that is bad behavior on the part of the toolkit.