Smoothie is a C++ implementation of a physical simulation engine for GUI animations. It calculates the current (per frame) position of a UI element by it’s final position.
What is Smoothie good for (features) ?
Animations are smooth, velocity does not change abruptly, feels natural & easy for the eye to track.
Animations are parametric yet simple, only a final position is needed to start an animation.
Final position may be changed during an ongoing animation.
Animation time can be limited, a distant final position doesn’t mean a long animation.
Animations can be started by a drag & release action, resulting animation may be constrained.
Low CPU usage, works on mobile devices.
OS independent.
Open source (MIT license)
Usage
Setup
The following code will be used in all the examples.
#include "Smoothie.h"
// this function simulates 25 fps
unsigned int simulator25fps(void)
{
static unsigned int ticks = 0;
ticks += 40;
return ticks;
}
// assign an implementation
Smoothie::getTimeMsecFuncPtr Smoothie::getTimeMsec = simulator25fps;
// print x space marks followed by an asterisk
void show(int x)
{
while(x--)
printf(" ");
printf("*\n");
}
In the following examples I will use a smoothie as defined below:
// create a smoothie positioned at 0, that traverses a distance of 180 win 2000ms (=2 seconds)
Smoothie smoothie(0, 180, 2000);
Requesting an animation of a distance less than 180, will take less that 2000ms.
Requesting an animation of a distance greater than 180, will cause the smoothie to skip the section with the highest speed, so that the total time of the animation will be 2000ms.
Example 1: Going from 0 to 120
// start animation
smoothie.setFinalPosition(120);
unsigned int timeTillIdle;
do
{
// calculate current position
int x = smoothie.calcCurrentPosition(&timeTillIdle);
show(x); // show on the screen the value of x
} while(timeTillIdle); // stop when smoothie is idle: timeTillIdle==0
Example 2: Going from 0 to 120, aborting at 60
// start animation
smoothie.setFinalPosition(120);
unsigned int timeTillIdle;
do
{
// calculate current position
int x = smoothie.calcCurrentPosition(&timeTillIdle);
// request to go back to 0 if we reached 60
if(x >= 60 && smoothie.getFinalPosition() == 120)
smoothie.setFinalPosition(0);
show(x); // show on the screen the value of x
} while(timeTillIdle); // stop when smoothie is idle: timeTillIdle==0
Example 3: “glide” animation after a drag-release action
// drag was released at position=0 with velocity=500.
// final position is in the range of [50..120], bounce size is 20
smoothie.setCurrentConstraint(0, 500, 50, 120, 20);
unsigned int timeTillIdle;
do
{
// calculate current position
int x = smoothie.calcCurrentPosition(&timeTillIdle);
show(x); // show on the screen the value of x
} while(timeTillIdle); // stop when smoothie is idle: timeTillIdle==0
This post is about GTW – A new User interface toolkit that is being developed by the Graphtech Labs team.
What is GTW?
One of the more exciting (for us in Graphtech, at least) features of the upcoming HTML5 standard is its hardware accelerated 3D graphics capabilities exposed via the WebGL API. GTW uses this API to deliver a user interface library that enables web developers to build web applications with modern and compelling user interface widgets.
In this post, we will go through an early-bird GTW demonstration that implements a cover-flow style interface to Google Images Search. If you have a WebGL enabled browser – check it out here.
Using GTW
Hopefully we got your attention to see what’s going on under the hood, so here it is. We will demonstrate the usage of GTW using the Google Images Cover Flow above.
This page includes several components:
A Text Input Area
A Search button
An Image View area
Now for the actual steps:
The first step in your HTML file is to define your canvases and setup your initialization function:
demo.js – Classes that are specific for the demo application
Next, we need to initialize GTW. This initialization includes binding the canvas to GTW’s stage and load a SceneFile (SF). This is the code that does the trick:
<SCRIPT type="text/javascript">
function webGLStart()
{
var canvas = document.getElementById("ilist-canvas");
var stage = gtwStage.prototype.getStage();
stage.init(canvas);
stage.loadSceneFile("demo_imageList.json");
}
</SCRIPT>
The files of this demonstration will be published publicly soon. However, if you would like to have the source code right now, please drop us a line.
Finally, we get to the ‘creative’ part – define your Scene-File. The GTW scene file is a JSON syntax file that defines the UI elements hierarchy. Each element in the hierarchy has a minimum ”type” property which identifies the element, plus a set of type specific elements and their properties. No worries – examples are forthcoming.
The root of our Scene is a ‘gtwGroup’ node. It looks like this:
{
"type" : "gtwGroup",
"children" : [ .... ]
}
Then, we get to the group’s children. The first child that we are going to add is the search button. it’s definition looks like this:
The button is of type ‘gtwButton’ (you are picking the naming convention, right?) and it takes a set of properties that defines it’s look. The same goes for the left and right pan buttons. We will not put them here but you are welcome to check the json file for details. Now, here is where things are getting interesting and WGL goes into action. The next element is a ‘gtwMirror’. The gtwMirror is a group that both renders it’s children (just like gtwGroup) and in addition renders a mirror image of them. In our coverflow, it creates the reflection on the floor. Here is it’s definition:
Note the children property of gtwMirror, which are the children that we want to be reflected in the mirror. In our case, the children include the scene background, the stylish, wavy background decoration and the image viewer itself. All are defined as:
The complete Scene Graph (SF) file is available here
What’s Next
Well, obviously the work in GTW is in it’s early stages and there is tons of work to do. Over the next weeks (and months) we will be working on:
Adding controls such as menus, dialog boxes, scroll lists etc
Cool visual effects and animations
WYSIWYG (what you see is what you get) style design tool
If you have ideas for new features and use cases, don’t be shy post a comment !
Credits
At times I find it hard to explain – As 3D graphics engineers, we know how to make crayons, but we don’t know how to paint. The guys that put the magic behind it all are these magnificent artists from ShugaPusher Studio
Ori Succary
Erez Bar
That said, Crayons are still required. The engineers that made this happen are:
What to expect at MWC Barcelona Feb 15th to 18th – ComPhones or PhonPuters?
Convergence has been the magic word in the mobile space for the last few years. Until recently, convergence related to networks infrastructure and bearers and was only relevant to value added services and voice calls. It was all about the relationship between circuit switched mobile/fix network and IP based networks.
The more sophisticated implementations of convergence dealt with seamless hand-off and service continuity between the two domains.
Today convergence has another new meaning – the convergence of devices!
A couple of years ago we were puzzled by the fact that voice calls are being made not only over switched networks with a device called a phone, but over IP using a computer…
Today we are once again puzzled by the compute capabilities and use-cases introduced by what is still called a phone.
This does not stop with your mobile surfing the net or with multimedia apps “in your hand”, the interesting idea to follow on the show floor this year is how it all scrolls up to compute intensive capabilities like augmented reality.
Combining compute power, SW development environments, sensors, UI elements ,broadband and business models which actually talk money is all you need to light a fire in the developer community. So be sure to expect new applications and use-cases leveraging these new devices (shall we call them ComPhones or Phonputers).
For us at GraphTech ,and for any SW engineering experts, it’s definitely good news. The more features and performance you want out of a device , the smarter your implementation needs to be. This means more engineering to optimize these device’s SW/HW infrastructure, including graphics APIs and drivers, middleware and UI . It’s the kind of work that lights our fire.
The obvious rise in the importance and effort invested in User Interface in the last two years has created a new domain in advanced graphics around optimization of UI implementations.
Here at GraphTech we noticed that significant portion of our high end graphics engineering expertise are hired for UI optimization related projects.
Until not long ago UI was never perceived to be a demanding or risky SW engineering task, we learned its important, we agreed it has to be done with great care to detail and user experience, but never saw it as challenging engineering wise .
Well , to our surprise, a relatively large group of our best engineers are working for over a year on implementing and optimizing the UI design of our customer on his target device , The UI design is so demanding , that we find ourselves bound by the limits of the graphic HW and graphic libraries!
High end Graphics was always reserved for the application, UI is entering this domain very quickly.
We have done many extensions and optimizations, and would appreciate the opportunity to discuss and share with others that have notice the same phenomena.
