Friday 22 April 2005
Glimpse Of The Future
One of the big initiatives in 1.9 will be an overhaul of our graphics infrastructure. We're planning to rip out a lot of our existing graphics code and base everything on cairo. This will give us modern 2D graphics capabilities (such as filling, stroking and clipping to paths, general affine transforms, and ubiquitious support for alpha transparency) and also, via Glitz, acceleration using 3D graphics hardware. It will also mean we can use a single rendering pipeline for HTML/CSS, canvas and SVG, so that SVG effects can be applied to HTML content.
Building on work by Vladimir Vukićević and Stuart Parmenter, I've managed to get basic functionality working on cairo, to the point where the browser is semi-usable:
Building on work by Vladimir Vukićević and Stuart Parmenter, I've managed to get basic functionality working on cairo, to the point where the browser is semi-usable:
Obviously there are still some glitches, and right now the speed is best described as somewhere between "glacial" and "proton decay", but at least things are working well enough that we can start identifying particular bugs and fixing them.
Comments
This is really "cool," but is it rational? Cairo is very much a work in progress. Will it itself be in a robust form by the time that mozilla 1.9 comes around? Or are you implying that 1.9 is a long way away? :-)
Although using 3D hardware to accelerate SVG will help the speed a lot, the current browser presumbly uses uses the 2D parts of the graphics chip to do a lot of the rendering using the current boring rendering pipeline. That particular path is considerably less complicated that whatever SVG needs to do, and it has existed in its current form for years and is well understood and has been tuned extensively.
My take on things is that Cairo is still in the demonstration state, and getting functionality right is a higher priority than performance. It will take quite a while to get a grip on exactly what it takes to get the performance tradeoffs worked out.
Now I have no idea of how gecko operates. Perhaps it does all of its drawing in software to an in-memory bitmap and just uses the hardware to blast the final bitmap to the display memory. If so, a hardware accelerated SVG could very well be faster. At the same time, one could argue that the existing 2D functionality, with a smaller investment of effort, could have been restructured to take better advantage of using hardware to composite to a video ram offscreen surface to achieve performance gains.
This is purely uninformed chit chat. All the best in your efforts -- like I started out, it would be really cool if it all works well.
So, once this is in and working fine, the code for printing web pages will be much simpler. And it would be trivial to add commands like "Save this page as a PNG snapshot" or "Save this page as a PDF".
However, I'm not a Mozilla hacker, or Cairo for that matter, so I could be dead wrong with this.
Are there also plans to use Cairo to render XUL and other such things?
Cairo is rendering XUL. In the screenshot, everything is rendered by Cairo (except for the window manager's window borders), including the browser UI.
Great looking development in any even. Thanks for your time.
brian: I'm not using the new units code. It should land in 1.9 I hope.
timo: we'll need that MacOSX Cairo port, yes. Hopefully it can use Quartz and/or AGL to get hardware acceleration. Rendering Cocoa widgets in this setup is going to be tricky but hopefully we can solve it.
In some cases "modern" refers to a 64MB Graphics Card MInimum.... or in some cases it just means an old ATI Rage PRO 128 (16 MB) will be good.
One thing that would be cool is to harness that png output functionality. At least in an API so that extension developers can make plugins to utalize that feature.
I'd love the new reporter tool to have an option to take and send a screenshot of the rendering bug. Then we could see what the user sees.
The work you're doing there is really ahead of the game, compared to other F/OSS projects.
Keep up with the good work. You are the future :)
"Cairo also has a pretty good number of backends for spitting out it's output. Like PDF, or PNG, or print output. (pppp)"
Will mozilla/firefox be able to open PDF files as a native format ?
What are the pros and cons? I can't really make up my mind on this since I'm no mozilla hacker.
Thank you again for your hard work :)
If so, that will be really cool! :D
Am I mistaken?
Or are they currently just a nice side-effect and will only get important in the future, when Gecko might be used for more graphics-intense applications?
I thought the vast majority of the time needed to bring a web page on the screen is the time Gecko needs to parse the HTML and to find out what rectangles, text etc. it has to draw (as opposed to actually drawing the rectangles etc. on the screen)...
Foxtrot: it will increase the size of the download. We don't know by how much.
aku: there are already many Web pages, especially pages with animation, where graphics rendering is actually the bottleneck. But our plans go beyond just rendering today's Web pages the way they look today as fast as possible; that's a recipe for stagnation. We want to render today's Web better than it looks today (e.g., by using smarter image scaling algorithms), and we want to render a new generation of graphically rich Web pages at high speed too.
And I want to know how exactly you expect this to work in Windows. Will the Cairo backend render an image to a surface and then just blit it with GDI or will you actually do something more exotic like require GDI+ or load Direct3D? And are bitmaped fonts going to be supported still?
asdf: That's part of the antialiasing that we need to turn off.
On Windows, we will try to use OpenGL, but if that doesn't work well we could implement a Cairo backend using D3D. The non-accelerated Cairo renderer will be based on GDI. Owen Taylor and others are already working on that.
Using those apis certainly works well for fullscreen games (and carefully programmed single window games for the most part) but it is very terrible for something like mozilla IMHO.
We already restrict rendering to the main thread.
We certainly will have to have some kind of whitelist of drivers we trust (possibly with a list of features that we trust those drivers to implement correctly).
It certainly won't be trivial but it's the only path into the hardware and we're not doing it alone.
Finally, the only way to get drivers fixed for this sort of application is to release a popular app that can use them.
(I hope because what I saw in the IE7b1's CSS... it was not encouraging for the CSS Designers...)