Friday, March 28, 2008 2:06:32 PM
Now we've released a build with only the core engine of Opera to show that we pass ACID3
perfectly. You can read more and comment at the desktop page
Wingogi/Lingogi is our internal testing framework which is very lightweight and allows us to play around with thing without consideration for usability or looks. In the build we published
most of the testing stuff is removed though. That was one reason it took two days to get the build up, we wanted to clean up the UI enough to not be embarrassed, as well as fix some unstability caused by the fast development.
Did we "win"? I don't know. It looked like WebKit was first, but apparently there is a problem with one of the tests that when fixed might expose a rendering bug in WebKit, and neither of us are as fast as the author wants us to be at test 26. So, we're like two horses on the homerun, side by side, passing finish line after finish line, just not certain which finish line is the final one. :-)
Thursday, March 27, 2008 12:36:22 PM
Now when the cat is out of the bag and we've published the 100/100 screenshot
, I think I should comment some on it.
First, as is noted in the post it's not a full pass. The test contains several parts of which the 100 scripting tests is the biggest but it's not all. There are still some layout problems (a floating "a" which loses its trailing space I think it was) and it's only running in our internal testing framework. Kestrel will use a much more stable version of our core so don't expect to see this there.
But disregarding that, it's been a fun race against WebKit. They've published a blog post for every test they pass, while we've only had the builds internally so we've been the only one seeing how close it's been. They were ahead at some points and we were ahead at some points and whoever will "win", it's been fun.
I've read some comments on slashdot
that questions the use of passing Acid3, and they're right, it's a couple of hundred quite arbitrary tests which find bugs that would normally not be prioritized very high since nobody would never really care, but it does give us something. A common platform that all browsers (eventually) pass. There are very few cross-platform testsuites that all browsers pass fully so it will be a nice addition.
There are also some major features in acid3 that may be liked by web developers. These include:
SVG - textual vector graphics language (something Opera is really good at)
Webfonts - the possibility to include font files with pages. We have not supported this earlier and there are still some security concerns.
Alpha - drawing text, borders or backgrounds with a semi-transparent colour. This is also something we have not supported for HTML before. Has always been supported in SVG though.
Thursday, December 6, 2007 8:50:22 PM
I just posted that last post about XSLT and XPath and then went to login to that other page, and got reminded on another new feature we have produced. Or more like a little tweak, but one that isn't that trivial under the hood. Wand, that saves your logins for you, is a great feature (proved by most if the other browsers now having it too), but I was always reluctant to save the password because I wan't sure I had actually entered the correct one. Now the login will proceed in the background while you decide so you can directly see if it was the correct password or not.
This was something I changed this summer so it's in all of desktop's snapshot builds and the 9.5 Beta, but it's not in 9.2x so it's "new" in a relative sense.
Thursday, December 6, 2007 8:41:01 PM
It seems to be very hard to find time to post something here, but let's see what has happened since last time. The main part for us in the group is that we released a completely new XSLT
engine that allowed us to add that last missing feature, the document()
function, and it looks very good. It seems to be better than the last in general in almost every aspect and while performance wasn't the main goal with it it seems to fast both in absolute numbers, and in perceived performance since it allows incremental rendering of the result.
It has already been released in public snapshot builds
(yes I know that was a month ago) and been well received
. It's always very encouraging when people publically (or in private messages for that part) actually tell us what they like. It's a well known fact that people are noisy when they are unhappy, but it's kind of hard to interpret silence as satisfation even when it's the case.
I hope there will be an article about it on http://dev.opera.com/
from the person who did it all eventually, but it's always hard to find time to write articles when you want to just fix just one more bug, implement one more feature, or make something just a little bit faster.
Sunday, October 28, 2007 2:29:10 PM
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;
Lots of text, images, iframes and plugins...
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.
Sunday, October 28, 2007 1:38:55 PM
Our blogging policy was even public on this server. So much better. So now you know, I am following http://my.opera.com/community/blogs/corp-policy/
, which really only tells us to use common sense, and to not reveal any secrets.
Saturday, October 27, 2007 1:16:09 PM
I'm a core developer at Opera. To most of you this doesn't say much so let me start by presenting the core department. In the Opera browser there are much code that is the same regardless if it's used on the Nintendo Wii
or in the desktop browser or in a phone, or in a set top box. This part is what we call the Core
. There you find the HTML layout engine, the XML parser, the EcmaScript compiler, the DOM environment, the SSL encryption, the SVG layout engine and many other small and big things. In general most of the things you expect from a browser except the user interface. Platform teams then make this into a finished browser (or browser SDK). One example of such a team is the desktop team
The core department, while being only a small part of Opera, is one of the larger departments and we're actually located at two different geographic locations, Oslo in Norway, and in Linköping in Sweden. I'm in Linköping
along with roughly half the core, and I'm mainly working with scripting and document loading and parsing in a small group working with, hmm, scripting and document loading and parsing.
I've long been thinking of starting a blog about work, where I can vent our successes, frustrations and share generic technical information that never really makes it to the changelogs. I don't know how often I will write, and I will have to read our blog policy so that I don't do anything wrong. The blog policy is very free but Opera is after all a public company so there are certain rules. Like, even if I know that we're delivering the browser to the space shuttle and I'm very proud of all the work done to make Opera space compatible, I couldn't say so until the official press release or I would make the stock rate rocket in a way not allowed.