It works so nicely that I'm actually pretty happy with it. The rewrite helped me fix issues with statically positioned elements (which just didn't work on a scrollview/canvas combination I did before). Due to which my blog finally looks and behaves correctly as seen on the screenshot above. That plus scrolling is about 10x faster and you never see gray areas on scrolling as you did before.This week George Staikos has been here in Oslo to work with us on the networking code. George and I have been friends for five or six years and he has this nasty habit that forces me to start an intervention and try to get him off it. What I'm referring to is the fact that George has been Canadian for, well his entire life, and it is my professional opinion (but I'm not a doctor) that he needs to move on. I'm not sure in which culture it is customary to bring Snapple ice-tea to your friends when you come to see them but we need to change him to that because he definitely didn't bring me any this time and that's just rude.
Going back to work, I'm sure Lars will blog about the networking magic they did so I'll keep my mouth shut. Once the code they were working on will be ready (which should happen within next week or two) and we'll start using in WebKit, we'll make the transition and start using WebKit Qt based browser on a daily basis. So we're close which is pretty exciting.
We have also started optimization run for Qt 4.3. My grand plan is to make sure Qt 4.3 is 2x faster in general rendering code than Qt 4.2 was. I have a list of algorithms to shave and rewrite over the next few weeks which will be rather challenging.
By the way of performance some people noticed that Qt OpenGL in recent snapshots with Antialiasing turned on is actually slower than it was in Qt 4.2. It's because of an experiment that we're trying on. We're now using GLSL to antialias primitives. Of course it's a lot slower than the old code but produces very high quality results. I don't really like it though because the performance hit is just too big.
14 comments:
The obvious question:
Is there a place were normal KDE users can get a WebKit-Qt based browser? And is there already something in place to connect it to the KDE-Wallet?
In would love to try the new browser, but if the walletmangeer would be integrated as well I would maybe even switch totally :)
Hi Zack,
Nice recursive screenshot :)
The speedups sound phenomenal - do you have any special insight into whether WebKit Qt will be replacing khtml in KDE4?
Also, I hear that QGraphicsView is an excellent candidate for forming the basis of Plasma, but is currently a little too slow. Is QGraphicsView on the hitlist of the Graphics Ninja? ;)
I realise you dropped GDI+ from the early days of the Qt4 tech preview code.
Not long ago we did some rough performance tests using polyline drawing in Qt4 and GDI+. I reported these back to TT but basically was told that the reason GDI+ was outperforming Qt was because the GDI stuff was probably hardware accelerated. Ok but I disabled the video acceleration and still Qt4 did not perform better than GDI+. To cut a long story short the performance issues seem to be lurking around drawing anti-aliased lines in the raster engine.
Have you revisited the raster engine for 4.3 ?
Well, you're asking me a questions based on benchmarks I never seen, results of which I'm not aware that affect code I'll never see. I really enjoy the "science" part of "computer science" so I can't answer your question. My best guess is that Qt fallbacks due to some code that you have and is in fact rendering polygons which means you're comparing apples and oranges. The only other explanation is that you're rendering very long polylines and the GDI implementation on your system is in fact accelerating antialiased lines. Meaning it's also way slower at rendering shorter lines than Qt is. The pure line rendering in the raster engine is basically optimal and there's nothing that can be done there to seriously affect anything. In 4.3 we'll introduce direct3d engine though for those cases where raster isn't good enough (which are very few and mostly come down to people just abusing Qt's rendering framework :) ).
You, dear sir, are insane. I love it when stuff gets 1. faster 2. cleaner 3. looks better.
But will these fixes go into Apple's "Webkit" / Safari as well? If not, send them some pointers on how to fix it. :)
Anyone else got Webkit compiled?
I got errors about conflicting declarations of pthreads.
>>Well, you're asking me a questions based on benchmarks I never seen, results of which I'm not aware that affect code I'll never see. <<
Listen Zack I respect your work but sometimes you come across as a bit "up yourself". It would seem reasonable to me that when you guys dropped GDI one of those reasons was performance. So again it would seem reasonable that you did your own benchmarks.
All I am saying is that some bold claims have been made about the raster engine. I am not privy to how Flash renders vectors either but it would seem that a full suite of benchmark tests coming out of Trolltech comparing other frameworks would help us all.
I don't have time to do benchmarks on Qt's rendering framework. I trust you guys to do that for me.
Your post does though highlight that rendering long polylines in GDI might be the difference. And when I recall our simple test this probably was the case.
"It would seem reasonable to me that when you guys dropped GDI one of those reasons was performance. So again it would seem reasonable that you did your own benchmarks."
We did and the results were not even close that's why GDI was not really even an option. And with GDI now being completely in software it just proves we were right.
"All I am saying is that some bold claims have been made about the raster engine. I am not privy to how Flash renders vectors either but it would seem that a full suite of benchmark tests coming out of Trolltech comparing other frameworks would help us all."
Which is technically impossible. You can't realistically compare frameworks with completely different feature sets which have difference purposes and goals.
"I don't have time to do benchmarks on Qt's rendering framework. I trust you guys to do that for me."
We do. But ff you come up and say that you have a benchmark that proves us wrong and expect me to give you an educated answer based on something that I'll never see, then you have to realize that that is simply impossible. I can't predict what your code was benchmarking or even doing based on the "it was slower" clue.
Like I said, if you want a well informed answer you need to provide me enough information to actually be able to give you that answer.
"We have also started optimization run for Qt 4.3. My grand plan is to make sure Qt 4.3 is 2x faster in general rendering code than Qt 4.2 was"
Ok this started my initial comment and to tell the truth when I read your grand plan I was excited by the possibility that you had sped up line drawing as I considered that to be part of the general rendering code.
I should have been more direct with my question. So you can see I was a bit confused by your response.
Ah, I see where your confusion came from. What I meant by "general code" is, well, general code =) It doesn't mean that we'll make every primitive 2x faster. That's impossible. But a lot of crucial code paths can be made way more than 2x faster which in general should give us a 2x improvement.
Good :)
On another topic have a look here at this 3D sofware rasteriser. If you are into games then Mike Abrash's name might be familar to you.
I know you enjoy reading/study of rendering techniques. I tested this out last year and it was very cool.
http://www.radgametools.com/pixomain.htm
Really cool thing, just playing around with it... seems like some things like supportsBufferedData need to be implemented to make it usable (I get freezes sometimes and console shows that it looks for this function). Well another thing would be: Is there anything of a plugin-interface available for this? - Having flash would be cool...
Great project. Maybe compilation instructions could
be clearer ... I needed a morning to figure out.
...and math.h or cmath
should be added to platform/ScrollBar.h
because "lroundf" is unknown (at least on my Mac :-)
Hi there, I wanted to try this on my Mac, but I can't becouse default Build System creates a Framework instead of dylib file and i can't link against WebKitQt becouse it created WebKit.framework. Adding "-framework WebKit" caues that it links to system WebKit framework and not my Qt copy... could you please check that?
Post a Comment