Beiträge getagged mit ExternalInterface
LuGo – Performance Vergleich
Verfasst von admin unter Development am 9. Januar 2010
Ich denke es ist an der Zeit, meine Vector Graphik API, die sich jetzt LuGo nennt
in Verhältnis zu den anderen API’s zu stellen. Also bitte… Eines vorweg, die Resultate sind großartig.
LuGo ist nicht die einzige verfügbare API die auf eine Abstraktion hinsichtlich nativen Vektorgrafik-Technologien anbietet. Daher sollte man an dieser Stelle, API’s mit ähnlicher Funktionalität anführen:
Im folgenden sollen nun die beiden API’s bezüglich Skriptgröße & Rendering-Zeit mit Lugo verglichen werden.
Versionen
- Dojo 1.4.0
- RaphaelJS 0.8.6
- LuGo alpha 0.3.1
Skriptgröße
| Raphael | 126 kB |
| Dojo GFX | 313,7 kB |
| LuGo | 103 kB |
Renderingzeit
In diesem Abschnitt soll nun überprüft werden, wie lange die jeweiligen API’s zum Rendern einer bestimmten Grafik brauchen. Dabei wurde darauf geachtet, dass das Testsetup bei allen API’s gleich ist. So wurden bspw. im Vorhinein benötigte Objekte und deren Erzeugung von der Zeitmessung ausgeschlossen, sodass nur das eigentliche Erstellen der unten gezeigten Grafik berücksichtigt wurde.
Algorithmen
Folgende Grafik soll von den API’s erzeugt werden:

Mit Hilfe folgender Algorithmen wurden jeweils 360 Kreise mit selben Radius erzeugt. Eine Zeitmessung wurde jeweils vor und nach der Operationsausführung durchgeführt und daraufhin die Differenz, also die benötigte Ausführungszeit ermittelt. Im Folgenden sind nun die detailierten Funktionen der jeweiligen API angeführt, um eine Testreproduktion zu ermöglichen:
RaphaelJS
function createCircles( quantity ) {
canvas.clear();
var radius = 15;
for (var i=0; i < quantity; i++){
var shape = canvas.circle(
centerX + (Math.sin( i ) * radius ),
centerY + (Math.cos( i ) * radius ),
4
);
shape.attr("fill", "blue");
radius += 0.5;
}//end for
}
Dojo GFX
function createCircles( quantity ) {
canvas.clear();
var radius = 15;
for (var i=0; i < quantity; i++){
var shape = canvas.createCircle(
{
cx: centerX + (Math.sin( i ) * radius ),
cy: centerY + (Math.cos( i ) * radius ),
r: 4
}
);
shape.setFill("blue");
radius += 0.5;
}//end for
}
LuGo
public void createCircles( int quantity ) {
canvas.clear();
int radius = 15;
for (int i=0; i < quantity; i++){
canvas.add (
new Ellipse(
centerX + (Math.sin( i ) * radius ),
centerY + (Math.cos( i ) * radius ),
4,
new SolidFill( Color.BLUE )
)
);
radius += 0.5;
}//end for
}
Ergebnisse
![]() |
![]() |
![]() |
![]() |
Fazit
Fairerweise muss man hier anmerken, dass der Vergleich bzgl. IE nicht ganz stimmt. Denn aufgrund der mangeldnen Performance des Internet Explorers, wird hierbei nicht VML wie bei Raphael und Dojo, sondern Flash zur Darstellung der Objekte benutzt. Diese Erweiterung kommuniziert mit dem ExternalInterface von Flash und erzeugt dynamisch zur Laufzeit die notwendigen Objekte im leeren Flash-Film. Dies passiert auf einem sehr generischen Weg, sodass sämtliche Möglichkeiten die Lugo bietet (EventHandling – EventBus, Transformationen, Zoom&Pan Support, geometrische Objekte wie komplexe Pfade, etc.) auch zur Programmierung für IE zur Verfügung stehten.
Dabei sieht der Entwickler aufgrund der angestrebten Transparenz nicht, welche genaue Implementierung (SVG, VML, Flash) nun zur Anwendung kommen. Die API entscheidet abhängig vom Browser des Benutzers und der Komplexität der Anwendung, welche Implementierung am passenden ist.
Zu den Resultaten: Wie man bei den Diagrammen erkennen kann, ist ein sehr deutlicher Unterschied zwischen Raphael und Lugo/Dojo. So ist die Performance im IE zwar sehr ähnlich, bei allen anderen ergibt sich jedoch ein sehr großer Unterschied (Chrome: ~400 ms, Safari: ~270 ms, Firefox: ~400ms).
Des Weiteren kann man erkennen, das LuGo immer eine Spur schneller rendert als Dojo, mit Ausnahme von Firefox, wo Dojo deutlich führt. So könnte man sagen, dass Dojo und Lugo in etwa gleich schnell rendern, sich jedoch bei der Größe der Skriptdateien unterscheiden. Hierbei benötigt Dojo knapp über 300 kB während Lugo mit knapp 110 kB auskommt. (Und dabei ist zu berücksichtigen, dass sämtlicher Code, der für dieses Demo benötigt wird, inkludiert ist.)
Abschliessend muss man anmerken, dass in LuGo noch keinerlei Performanceoptimierungen erfolgten, da sich die API noch im der Pre-Alpha-Phase befindet.




