To view parent comment, click here.
To read all comments associated with this story, please click here.
KHTML uses the same drivers and X11 interface. So XRender does not explain the at least factor 10 difference. XRender would explain it if performance with Qt's software raster was consistantly faster than using Qt's X11 raster. When the difference only happens for the Webkit engine and not KHTML, it is my assumption they are doing ineffienct things, probably rendering to server-side pixmaps, and then processing those pixmaps client-side. That would explain why the very same painting routine is much faster when done entirely client side.
It not at all that clear. There are sufficiently many equally valid, different ways of rendering the same thing, that just because you found firefox slower than konqueror on a particular demo doesn't have to mean it does stupid things: it can also just be that it uses different functions, hits different bugs and performance issues in the graphics system.
Of course it _can_ also be that it's doing something stupid with XRender, but keep in mind that on other demos, with the right XRender driver (e.g. NVIDIA proprietary driver works well here) it's doing great, for example on this benchmark:
http://ie.microsoft.com/testdrive/Performance/PsychedelicBrowsing/
(I get 1400-1500 score!) So not all of what we do can be that stupid.
Of course XRender is not a long-term solution anyway. The only satisfactory solution is to implement a free equivalent of Direct2D, i.e. hardware-accelerated content drawing, using of course OpenGL. This is a really hard job: it will require lots of 2d graphics work, and lots of GL performance knowledge.
There are some efforts in that direction already but none is satisfactory as of yet. The Cairo/OpenGL backend is far from ready last I heard. The Qt/OpenGL backend has poor performance (what I meant above when I said it would require lots of thinking GL-performance-wise). I heard that Qt is moving to a higher-level scene-graph approach, which will be great for lots of applications, but there's little hope that it will be enough to use for a web engine, where one needs to implement a very wide variety of primitives and where 1 pixel errors can't be tolerated.





Member since:
2006-01-02
Apparently you did these measurements on linux.
we know about that problem. I guess we should blacklist certain drivers for XRender. You can file a bug with enough system info (X, graphics driver, etc), it'd be a starting point in that direction.
it's just that so far, coding a xrender-crappy-driver-blacklist-on-*nix hasn't been the biggest priority. That can change if the ever evolving web makes it a showstopper for many *nix users.
So the most probable thing that happened is that you are using XRender for content acceleration (the only option currently on linux, since Direct2D is windows-specific) and no accelerated composition (since GL is disabled by default, set layers.accelerate-all to true in about:config to enable it).
So what you're measuring here is that your XRender drivers are crappy. Big news
Next time, please just avoid jumping to the conclusion that we're retarded