I will let this first real post be about conflicts, and more specifically about the conflict between new features and performance. Somehow Opera has had a history of combining those two really well, so that we've been both very innovative with numberless features later adapted by other browsers, and fast, where we've only very recently been really challenged by the Safari 3.0-beta (which is good, real competition spurs development and I've no doubt we can stay ahead).
Our goal is to be the fastest browser on earth, and at the same time the most standards compliant and with good features the other browser makers haven't been able to realize yet, but that is not always easy.
Let me take one example. Fixed backgrounds.
With CSS you can set a fixed background, that is, a background that does not scroll with the text. Example:
[html:div style="width: 200px; height: 200px;
background-attachment: fixed;
background-image: url('bg.png');
overflow: auto"]
Lots of text, images, iframes and plugins...
</div>
When you scroll that scrollable div, the image bg.png will all the time be stuck to the upper left corner of the div area. This can be used to create useful effects (and unfortunately to create the opposite as well). The problem comes with the performance when you scroll. Normal scrolling is something that can be very fast in most operating systems and in most hardware since it at most involves moving a piece of memory and then drawing the small part that appeared at the edge of the scrollable area. Not so with fixed backgrounds. Even a 1 pixel scroll will change the composition of the area completely and it will have to be fully rendered.
If you for instance have a 200x200 pixel screen and scroll 1 pixel 25 times per second, that normally requires rendering 25*1*200 = 5000 pixels and moving 25*199*200 = 995000 pixels per second. Trivial on most hardware. But if you now change to a fixed background, the whole area will have to be rendered for each 1 pixel scroll and you have to be able to render 25*200*200 = 1000000 pixels per second which for some hardware is not at all easy to handle.
So what to do. In this case I've seen two different approaches. Either try to make the rendering as fast as possible to enable very high pixel output or to disable fixed backgrounds. We've done the former. Safari on the iphone does the latter. Since it's only the background and fixed backgrounds are not that common, not too many pages break.
Knowing this, the first question I ask myself whenever I hear of a fast competitor is "what rules and specifications have they broken?". There normally is one or two related to performance. For instance the early
onload in Safari (once again) 3.0 beta.
This also comes into play whenever someone (being it a customer, a user or an organisation like the
W3C) request us to implement a new feature. If that feature isn't designed properly and implemented well, it might hurt the performance everywhere. I think that is the main reason Mozilla has implemented so few new features the last five years. Granted, it's almost that long since I stopped being a Mozilla developer and I've followed the inner proceedings very loosely the last couple of years, but I can't really think of any major new features implemented in that time. They're falling behind in both new HTML5 features and SVG.
What we try to do is to act early, we have many people that works with development of specifications, and they talk to developers (in those cases where they aren't developers themselves) and makes sure that features are possible to implement in an efficient manner. Often people sitting with state-of-the-art desktop machines doesn't realize that there are millions of computers out there where you count hundreds of MHz and tens of MB. The Nintendo DS for instance has a 66 MHz ARM processor (and a 33 MHz DSP) and only a handful of MB of RAM and it runs Opera though I would say that it is generally way too weak hardware even for us.
This post is getting way too long now, but let me just add a last example. CSS selectors. The CSS3 specification adds a number of new selectors which makes CSS much more powerful, but they don't come without a price. Suddenly changing a single property at one element can affect the style far away in dramatic ways. Taking that into consideration when properties change was not easy to do while still having the code fast. Still we support them all except ::selection I think. We were quite proud when we could publish a build where we passed all the tests on the official test suite. That doesn't mean we don't have bugs, but I think it means that we're still ahead.
My Opera
