This was just brought to my attention, and I’m pretty stoked! I haven’t actually looked at the source or done much in the way of investigation, but if it’s legit, then this is really, really exciting. 🙂
Maybe not as exciting as porting Unreal 3 to the web, but, well, I’m old-school. 😀
UPDATED: Thanks everybody for alerting me to the broken link. Fixed it now.
I wrote a while back about how Matt, Avi Halachmi and I have been ironing out performance problems with the Australis curvy tabs.
Well, it looks like that work is finally paying off.
Our SVG usage seemed to be the big slow-poke, and switching to PNGs gave us the boost that we needed.
But enough squawking, let’s see some charts.
Let’s compare – here’s a chart showing the difference between pre-curves and post-curves, before our optimizations:
Here’s the before shot
Note: it’s been a while since I’ve done data visualization work. I think the last time I did this was in grad school. So there might be way better ways of visualizing this data, but I just chose the easiest chart I could manage with Google Docs. Just go with it.
Let me describe what you’re seeing here – we take samples every time a tab opens, and every time a tab closes*. What we’re measuring is the interval time (how long it takes before we start drawing the next frame), and the paint time (how long it takes to actually draw a frame).
The blue bars represent the performance measurements we took on a build using the default theme. The red bars represent the performance measurements we took using the Australis curvy tabs.
This is where my graph could probably be clearer – in each group of four bars, the left two represent interval times, and the right two represent paint times.
So, hand-wavey interpretation – we regressed in terms of performance in both painting, and frame intervals, for tab opening and closing.
So that’s what we started with. And then we did our optimizations. So where did we get to?
Here’s the after shot!
The red bars shrunk, meaning that we got faster for both interval and paint times. In fact, for tab close, we beat the old theme! And we’re really super-close for tab open.
Pretty good!
Last night, Matt landed our optimization patches, as well as preliminary curvy tab work for OSX* and Linux GTK on our UX branch. So, if you’re on the UX branch (and why aren’t you?), you should be receiving a build soon with some curvy tabs. They’re not perfect, not by a long shot, but we’re getting into the polish stage now, which is good.
* Some notes on our measuring methodology. All tests were performed on a low-powered Acer Aspire One netbook. Intel Atom n450 processor (1.66Ghz), 1GB of RAM, running Windows 7. The device has no graphics acceleration support. We also switched to the classic theme to avoid glass. Avi wrote a patch that opened and closed a tab 15 times, and averaging the frame intervals and paint times for each frame. Those were averaged over the 15 openings and closings. We then ran that test 4 times, giving the machine time to “relax” in between, and averaged our results.
* We don’t have hi-dpi support yet, so if you’re on a Mac with a Retina display, your curves might be fuzzy. We’re working on it.
Hey all.
I’ve been pretty bad about talking about the address book. Sorry about that. I’ve been pretty busy helping to get Instant Messaging shipped for TB 15.
But with IM polished off, I’ve (once again) started refocusing my attention to the address book.
So where am I?
In short, I’m writing an add-on to experiment with approaches to a new address book. I’m calling it “Thunderbird Ensemble”, because every project needs a cool code name.
The add-on is in its very very early stages. Nothing is usable. Nothing is stable or guaranteed. There’s no UI yet, but there are some tests.
You can track my progress here.
Here are some highlights, implementation details and unstructured thoughts about the add-on, and where I’m going with it:
I’ve chosen to use SQLite (via mozStorage) for the contact database. I was originally toying with using indexedDB, but it’s lack of support for substring searches (which is necessary for things like auto-complete) wasn’t very appealing. I briefly toyed with throwing my own indexing layer on TOP of indexedDB, and then I realized that I was probably reinventing the wheel.
So SQLite it is!
Contact records are a representation of the fields and meta data about a contact. My add-on will be able to calculate diffs between records, and those diffs can be applied on top of records to make changes.
So, for example, suppose I decide to make some changes to a contact – I add some email addresses, remove a phone number, and change a birthday. I’m effectively creating a diff.
Now we apply the diff on top of the original contact, and send the resulting contact record to the datastore for storage.
If the storage happens to be on the network, and the original record we applied the diff on to was out of date, we should get a fresh copy of the contact record, apply the diff, and try again.
With diffs comes conflicts resolution – but conflict resolution is never a pleasant experience, and I’d like the user to not have to deal with that if possible.
My solution is to just be optimistic – if a diff is asking to remove something that isn’t there, great! Mission accomplished! If the diff is adding something that already exists, no problem! We skip!
And for things that get changed, like birthdays, we simply say that the last writer wins.
Maybe that’s naive, but that’s the approach that I’m taking.
I can create contact records, diff them, apply diffs, and “merge” two records together. And I have tests for all of that work.
I’ve got the start of the SQLite backend working (basically, we can set up the database…but that’s it.)
I’m currently working on importing old Thunderbird contacts into Ensemble’s notion of contact records.
After that, I’ll work on getting them written to the database.
Comments? Questions? Complaints? Ask them here. It’s still really early on in the process, but if you find bugs in my code, please file issues on GitHub.
Once again, I’ve let my blog gather dust. And the comments have been piling up. And the emails have been rolling in. And I’ve been silent.
Sorry about that!
I’ve been pretty heads-down lately – here’s what’s going on:
About the address book – I’ve received a bunch of email making suggestions and asking for things. That’s great! I’ll comment on that shortly – I just need a little more time to clear Account Provisioner and Tabs on Top off my plate.
More soon.
So my dream of redesigning / rebuilding the Thunderbird address book is moving forward. Here’s the draft feature page.
I also got the Contacts add-on from Labs working (limping, rather) in Thunderbird. Some very interesting ideas in that add-on.
I’ve also started reading some related work. Here’s what I’ve been gazing at for the past few days:
So, basically, I’m exposing myself to as much current work in this problem space as possible. Is there anything else I should be reading?