Last updated at 12:38 pm UTC on 16 January 2006
[From a message by Dan Ingalls, on 12 Feb 2000]
Balloon and Balloon 3D have catapulted us into a world that is even more exciting that we had hoped. We have seen the beauty of anti-aliasing, we are getting performance that is second to none for a cross-platform engine with no acceleration and, let's face it, 3D is cool. For those who have not seen a recent demo, imagine strolling through a gallery in 3D, where the pictures on the walls are active Squeak projects, with drag-and-drop and the works. [We hope to get this out in a few months as just another thumbnail image on the web that you can enter by clicking on it].
That's the vision unfolding. Now about the challenges and our plans...
First of all while, as always, we're committed to total cross-platform operation, we want to be able to tap the benefits of platform-specific acceleration facilities. This turns out to be a big problem. On the one hand you want Squeak to be completely uniform ("bit-identical images" is the phrase we use) from one platform to another, and on the other hand some platforms have one byte ordering in their hardware, and others have another, and – oh – did we mention about color component ordering within RGB pixels ...er... it IS RGB, isn't it?
Those of you who have been around for a while will remember Tim Rowledge urging us to incorporate his little-endian BitBlt so that Squeak graphics could run faster on the Acorn. This grew into an intense discussion for a while, and finally blossomed into a plan to "do it all right". Andreas says the first rule of graphics programming is "first make it fast, then make it right". But with umpteen different accelerator boards, you have to do it right to make it fast. So that's what Andreas has been up to for the last two months, in his rare moments between much other responsible behavior at work.
What's the status? Interesting that you should ask. Today is the very day when Andreas has completed an entirely new BitBlt running beside the old one, and is plotting how to build it into the VM, and yet retain the old BitBlt as a plugin for backward compatibility. I'm sure Andreas will be delighted to describe the design and capability of this new BitBlt in a separate message.
With the new BitBlt in place, it should soon be possible to tap the power of a number of platform-specific 3D (and 2D) accelerators. Fasten your seat belts.
For a full description of the new BitBlt, see New Graphics.
Once the new BitBlt is in place and we understand the full path from Squeak images to platform-dependent bits on the screen, we paln to revamp Morphic substantially. What do I mean by substantially? Well for starters, morphs themselves will probably become much lighter-weight, more as generalized graphical actors, separate from their particular appearance. Also, each morph will probably have its own coordinate transformation that applies to all its submorphs. Stepping will also probably be replaced by a more generalized form of event/response architecture.
I can see people rolling their eyes, "Good lord nothing will be preserved." However, on the contrary, we are still committed to the kind of environment that Morhpic is – a highly concrete drag-and-drop world of active objects. We will probably build the new Morphic from the ground up, next to the old one, and we won't stop until most of the components that you know and work with (shapes, lines, bitmaps, text, transformations, scrolling, clipping, windows, browsers and the like) are operational in the new environment. While some code will have to be rewritten, I don't envision major compatibility problems, except that you will have to get used to uniform ability to scale and rotate everything, with translucency and anti-aliasing, as well as the emerging ability to project 2D morphic displays into 3D environments.
The time scale on this one is harder to predict. I think Andreas will be done with the bottom layer in the next month or so, as will be the case with a couple of our current intense projects. So it's likely to start in April and take about six months. (But who knows? We might get passionately interested in something else and it would get delayed, or Alan might say he needs it for a demo to Michael in May, and then it would be done in May ;-).
Since this also got asked, and since I need to write about it for the wiki update, here's what I see as the current Squeak Central position on widgets. Right now we have our hands full (as we have ever since we met Alan), and the directions we need to go are not limited by our stock of widgets. So this is a GREAT area for external cooperation and contribution. It's true that none of what you build will work in the new Morphic, but you can count on our support in porting anything that has stood the test of time. This is a perfect time to evolve a set of widgets and some parameterization into various "styles".
Incidentally, one of my projects in the ease-of-access area is to revive Fabrik both as it was originally, and in another wireless form that still preserves the GUI-builder strenths of that system. While it would be a mistake to count on this for widgets in the near future, I still hope to assemble a Fabrik-like environment within Squeak which would make it easy not only to assemble widgets, but to build an entire widget library up concretely from very simple morphs and very basic behaviors. I hope to be back in this area sometime around the middle of next month, but the widgets-from-scratch project will probably remain on the back burner at least until summer. I'll let people know about any progress on this so that anyone who is interested can play with prototypes and criticize or contribute.
Back to Squeak Central project list