nicht angemeldet
SVG-Performance / SVG und Hardware
Hallo,
ich hatte schonmal einige Frage bezügl. SVG gestellt und leider keine Antwort erhalten, siehe hier:
http://forum.de.selfhtml.org/archiv/2008/2/t167099/
Ich versuche mein Glück jetzt nochmal, da ich mir einen neuen PC kaufen werde:
Ich erzeuge sehr komplexe SVG-Grafiken, aus hunderten und tausenden von einzelnen Kreisen, Drei-, Vier-, Sechsecken und ähnlich einfachen Figuren. Die sollen auch animiert werden. Bei meinem jetzigen System (PIII, 800 MHz, 256 MB RAM) dauert der Aufbau der Grafik sehr lange und die Animationen sind abgehackt und unansehnlich.
Die Frage ist jetzt nochmal dieselbe wie "SVG und Hardware" im Thread oben: Inwiefern spielt die Hardware überhaupt eine Rolle? Ist SVG an sich zur Darstellung derart komplexer Grafiken in der Lage?
Und wenn ich einen neuen PC kaufe: Was braucht der, um mit den SVGs möglichst gut fertig zu werden? Viel RAM, schnellen Prozessor, etwa eine gute Grafikkarte?
Ich hoffe auf Antwort, und sei es "nur" in Form von Links oder Anregungen, wo ich fragen/forschen könnte.
-
Hallo,
Hast du mal eine Beispiel zur Hand, dann koennte man ja mal testen. In welcher Applikation dauert der Aufbau so lange? Es gibt Anwendungen, die bestimmte Vektorberechnungen extra unterstützen durch entsprechende Hardware. Hast du mal als referenz inkscape verwendet? Ich muss aber leider passen, was genauere Angaben anbelangt. Bei deinen Daten vermisse ich die für die Grafikkarte, hier dürfte oft das Nadelöhr sein.
Allgemein dürfte bei solchen Berechnungen viel Arbeitsspeicher zur Verfügung stehen, unter 2GB würde ich heute nicht mehr im Arbeitsbereich einsteigen. Bei den Graka bin ich schon lange nicht mehr auf dem laufenden. Zudem dürfte dann auch das betriebssystem eine Rolle spielen, ob du einen schlanke GUI untzer Linux verwendest oder dir das doch etwas lahmende Vista zulegst mit dem neuen Rechner oder aber ein "altes" aber flottes Windows XP aufspielst.
Gruß
Hallo,
ich hatte schonmal einige Frage bezügl. SVG gestellt und leider keine Antwort erhalten, siehe hier:
http://forum.de.selfhtml.org/archiv/2008/2/t167099/
Ich versuche mein Glück jetzt nochmal, da ich mir einen neuen PC kaufen werde:
Ich erzeuge sehr komplexe SVG-Grafiken, aus hunderten und tausenden von einzelnen Kreisen, Drei-, Vier-, Sechsecken und ähnlich einfachen Figuren. Die sollen auch animiert werden. Bei meinem jetzigen System (PIII, 800 MHz, 256 MB RAM) dauert der Aufbau der Grafik sehr lange und die Animationen sind abgehackt und unansehnlich.
Die Frage ist jetzt nochmal dieselbe wie "SVG und Hardware" im Thread oben: Inwiefern spielt die Hardware überhaupt eine Rolle? Ist SVG an sich zur Darstellung derart komplexer Grafiken in der Lage?
Und wenn ich einen neuen PC kaufe: Was braucht der, um mit den SVGs möglichst gut fertig zu werden? Viel RAM, schnellen Prozessor, etwa eine gute Grafikkarte?
Ich hoffe auf Antwort, und sei es "nur" in Form von Links oder Anregungen, wo ich fragen/forschen könnte.
-
Hallo Holger,
Hast du mal eine Beispiel zur Hand, dann koennte man ja mal testen.
schwierig, aus diversen Gründen.. Ich könnte evtl. mal was zur Demonstration anfertigen, aber das müsste ich dann per Mail schicken, weil das sicher nicht in ein Posting passt.
In welcher Applikation dauert der Aufbau so lange?
Mit dem Adobe SVG-Viewer, also als in ein HTML-Dokument eingebundene .svg-Datei, betrachtet im Browser (hier: IE).
Es gibt Anwendungen, die bestimmte Vektorberechnungen extra unterstützen durch entsprechende Hardware. Hast du mal als referenz inkscape verwendet?
Ich hab mir das Programm nur mal oberflächlich angesehen.. Kann man dort eine .svg-Datei öffnen? Anfangen kann ich mit der Software nichts, ich berechne diese Figurenkonstellationen mit PHP, wo dann gleich die SVG-Datei geschrieben und gespeichert wird.
Ich muss aber leider passen, was genauere Angaben anbelangt.
Genau muss es nicht sein, mich würde erstmal interessieren, ob es lediglich von der Hardware abhängt, wie schnell der Bildaufbau erfolgt, respektive wie flüssig Animationen sind. Es könnte ja auch an SVG selbst liegen, dass es einfach nicht mit bspw. tausend Vierecken fertig wird, bzw. eine Animation von wenigstens 100 Vierecken generell nicht flüssig hinbekommt.
Bei deinen Daten vermisse ich die für die Grafikkarte, hier dürfte oft das Nadelöhr sein.
Das ist keine Karte, sondern ein integrierter Grafik-Chip mit Name "Intel(R) 82815 Graphics Controller" (lt. Geräte Manager).
Allgemein dürfte bei solchen Berechnungen viel Arbeitsspeicher zur Verfügung stehen, unter 2GB würde ich heute nicht mehr im Arbeitsbereich einsteigen. Bei den Graka bin ich schon lange nicht mehr auf dem laufenden. Zudem dürfte dann auch das betriebssystem eine Rolle spielen, ob du einen schlanke GUI untzer Linux verwendest oder dir das doch etwas lahmende Vista zulegst mit dem neuen Rechner oder aber ein "altes" aber flottes Windows XP aufspielst.
Ich hab einen PC mit folgenden Spezifikationen im Auge:
Prozessor: AMD Athlon 64 X2 3600+
Sockel AM2 Mainboard
RAM: 2048 MB DDR II 667MHz
Grafikkarte: 256 MB GeForce 6100 (nVidia GeForce 6100 Chipsatz)Die Grafikkarte könnte wohl besser sein, aber wie gesagt, ich hab null Ahnung, inwiefern die für SVG überhaupt groß benötigt wird.
-
Hast du mal eine Beispiel zur Hand, dann koennte man ja mal testen.
Ich könnte evtl. mal was zur Demonstration anfertigen, aber das müsste ich dann per Mail schicken, weil das sicher nicht in ein Posting passt.
Es passt mit Sicherheit in einen Link.
Adobe SVG-Viewer
Ist bereits mehr als zwei Jahre alt und wird meines Wissens auch nicht mehr weiterentwickelt. Wie schlagen sich Opera und Safari im Umgang mit deinen SVGs?
Die Grafikkarte könnte wohl besser sein, aber wie gesagt, ich hab null Ahnung, inwiefern die für SVG überhaupt groß benötigt wird.
Vermutlich eher wenig.
-
Hallo Rotor,
In welcher Applikation dauert der Aufbau so lange?
Mit dem Adobe SVG-Viewer, also als in ein HTML-Dokument eingebundene .svg-Datei, betrachtet im Browser (hier: IE).
Der ASV ist gerade bei größeren SVG-Dokumenten als nicht besonders performant bekannt. Ich erinnere mich an minutenlange Wartezeiten bei Grafiken mit ~100.000 Zeilen Code auf durchaus gut ausgestatteten PCs.
Versuche die Grafiken zu optimieren und Redundanzen zu vermeiden, also z. B. Rahmenstärken eines Elementtyps wie path im CSS zu vereinbaren als x-fach in Attributen anzugeben usw.
Probiere neben den genannten SVG-nativen Browsern das Renesis-Plugin aus und erstelle mal zum Performancetest ein XAML-Testdokument und lade dieses mittels Silverlight. Nach meinem Eindruck werden Vektorgrafiken dort wesentlich schneller gerendert als im ASV (allein das Plugin ist sofort zur Stelle), wobei ich hier noch keine Aussagen zu sehr großen Dokumenten machen kann und auch nicht alle SVG-Techniken zur Verfügung stehen.
Grüße,
Thomas-
Hi Thomas.
In welcher Applikation dauert der Aufbau so lange?
Mit dem Adobe SVG-Viewer, also als in ein HTML-Dokument eingebundene .svg-Datei, betrachtet im Browser (hier: IE).
Der ASV ist gerade bei größeren SVG-Dokumenten als nicht besonders performant bekannt. Ich erinnere mich an minutenlange Wartezeiten bei Grafiken mit ~100.000 Zeilen Code auf durchaus gut ausgestatteten PCs.
100.000 Zeilen klingen gut, so viele hatte ich bislang noch nicht. Was hast Du denn da gemacht, wenn ich mal fragen darf? Und das läuft bei Dir inzwischen problemlos und schnell? Mit den Programmen/PlugIns, die Du unten nennst?
Versuche die Grafiken zu optimieren und Redundanzen zu vermeiden, also z. B. Rahmenstärken eines Elementtyps wie path im CSS zu vereinbaren als x-fach in Attributen anzugeben usw.
Ich verwende nur Pfade und Kreise, keine Füllungen oder sonstige Effekte und (zumeist) auch alles in der gleichen Formatierung, die ich dann mit dem <g>-Tag anwende. Ist das ok?
Probiere neben den genannten SVG-nativen Browsern das Renesis-Plugin aus und erstelle mal zum Performancetest ein XAML-Testdokument und lade dieses mittels Silverlight. Nach meinem Eindruck werden Vektorgrafiken dort wesentlich schneller gerendert als im ASV (allein das Plugin ist sofort zur Stelle), wobei ich hier noch keine Aussagen zu sehr großen Dokumenten machen kann und auch nicht alle SVG-Techniken zur Verfügung stehen.
Danke für die Tipps. Ich hab mir jetzt den neuen PC mal bestellt und werde mir dann auch die von Dir empfohlene Software ansehen, auf meiner alten Gurke hab ich noch Windows 2000, da ist das alles nicht verwendbar.
Du scheinst Dich mit SVG auszukennen, kannst Du mir auch was zu meinen "alten" Fragen sagen? Die stehen hier:
http://forum.de.selfhtml.org/archiv/2008/2/t167099/
Besonders das mit den überlagernden Linien, die dann anders aussehen, ist sehr störend, kann man da was gegen machen..?
Bezügl. Animation werde ich erstmal sehen, was der neue PC leistet, hätte aber noch eine andere Frage dazu: Kann man irgendwie die Animationen als .avi-Datei speichern und auf DVD brennen..? Ich verwende das SVG für "eine Art Kunst" und würde das gerne vom PC loslösen können.
Auf jeden Fall schonmal danke für die Antwort, die erleichtert mich vor allem hinsichtlich der Datenmenge, wenn Du von 100.000 Zeilen sprichst, dann wird SVG wohl mit < 10.000 Pfaden/Kreisen prinzipiell fertig. Und ich kann nochmal eine Potenz größer denken. :)
-
Hallo Rotor,
100.000 Zeilen klingen gut, so viele hatte ich bislang noch nicht. Was hast Du denn da gemacht, wenn ich mal fragen darf? Und das läuft bei Dir inzwischen problemlos und schnell? Mit den Programmen/PlugIns, die Du unten nennst?
Es handelte sich um die Umsetzung elektronischer Ersatzteilkataloge. Die Vektordaten kamen aus speziellen CAD-Werkzeugen über Ex-/Importe in weitere Programme wie IsoDraw, Illustrator und Visio zustande. Die unterschiedliche Handhabung von SVG brachte erhebliche Redundanzen mit sich. Ich habe mal testweise eine XSLT-Transformation gebaut, die ca. 20% ohne Verluste entfernen konnte (z. B. 5 MB --> 4 MB).
Wenn zehntausende Pfade so aufgebaut sind und nur das d-Attribut die variablen Pfaddaten enthält:
<path d="..." fill="..." stroke="..." stroke-width="..." stroke-linecap="..." stroke-linejoin="..." stroke-dasharray="..."/>werden die Redundanzen offensichtlich und bei sinnvoller Nutzung von CSS
path { fill: ...; stroke: ...; stroke-width: ...; stroke-linecap: ...; stroke-linejoin: ...; stroke-dasharray: ...; }kann sehr viel an Code entfallen.
Letzlich wurde in diesem Projekt noch weiter optimiert und spezielle Konvertersoftware entwickelt. Ich hatte allerdings nur betreuende/beratende Funktion, aber die weiteren Optimierungen sind letzlich zufriedenstellend verlaufen.
Getestet wurde nur mit dem ASV, da dieser von der Spezialsoftware CatalogCreator eingebunden wird. Sehr große SVG-Dokumente sind natürlich weiterhin ein Problem.
Ich verwende nur Pfade und Kreise, keine Füllungen oder sonstige Effekte und (zumeist) auch alles in der gleichen Formatierung, die ich dann mit dem <g>-Tag anwende. Ist das ok?
Vermutlich, aber ohne Code schwer zu beurteilen.
Besonders das mit den überlagernden Linien, die dann anders aussehen, ist sehr störend, kann man da was gegen machen..?
Bitte mal etwas testfähigen Code posten, der das Problem beschreibt.
Grüße,
Thomas-
Hi Thomas.
Letzlich wurde in diesem Projekt noch weiter optimiert und spezielle Konvertersoftware entwickelt. Ich hatte allerdings nur betreuende/beratende Funktion, aber die weiteren Optimierungen sind letzlich zufriedenstellend verlaufen.
Getestet wurde nur mit dem ASV, da dieser von der Spezialsoftware CatalogCreator eingebunden wird. Sehr große SVG-Dokumente sind natürlich weiterhin ein Problem.
Es geht da also um das automatische Konvertieren bestehender Vektorgrafiken ins SVG-Format. An ähnliches hab ich auch schon gedacht, allerdings von SVG in eine schnellere Vektor-Software. Aber jetzt werde ich erstmal abwarten, was der neue PC leistet..
Ich verwende nur Pfade und Kreise, keine Füllungen oder sonstige Effekte und (zumeist) auch alles in der gleichen Formatierung, die ich dann mit dem <g>-Tag anwende. Ist das ok?
Vermutlich, aber ohne Code schwer zu beurteilen.
Besonders das mit den überlagernden Linien, die dann anders aussehen, ist sehr störend, kann man da was gegen machen..?
Bitte mal etwas testfähigen Code posten, der das Problem beschreibt.
Ok, hier ist mal ein ganz einfaches Beispiel:
<?xml version='1.0' standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd"> <svg width="1000" height="1000"> <g style="fill-opacity:0; fill:#ffffff; stroke:#000000; stroke-width:1;"> <path d="M400,300 600,500 400,700 200,500 400,300"/> <path d="M500,200 700,400 500,600 300,400 500,200"/> </g> </svg>Zwei gleichgroße Vierecke. Das Ergebnis sieht so aus:
Unverändertes Bildschirmfoto der Darstellung per SVG-Viewer im IE und hier ein Zoom innerhalb eines Bildbearbeitungsprogrammes, um den Unterschied zu zeigen.
Der Effekt der unterschiedlichen Linienstärke bei deckenden Linien bleibt auch beim Zoomen erhalten.
-
Hallo Rotor,
Der Effekt der unterschiedlichen Linienstärke bei deckenden Linien bleibt auch beim Zoomen erhalten.
Dazu habe ich leider keinen Tipp auf Lager (außer vielleicht irgendwie umständlich via Script mit den SVG-DOM-Methoden checkIntersection() bzw. checkEnclosure() nach Überlappungen zu suchen und dann die Strickstärken anzupassen, sofern diese Methoden überhaupt irgendwo implementiert sind).
Allerdings wird das sowohl von IE+ASV als auch von Firefox und Opera in dieser Weise umgesetzt.
Grüße,
Thomas-
Hi Thomas.
Der Effekt der unterschiedlichen Linienstärke bei deckenden Linien bleibt auch beim Zoomen erhalten.
Dazu habe ich leider keinen Tipp auf Lager (außer vielleicht irgendwie umständlich via Script mit den SVG-DOM-Methoden checkIntersection() bzw. checkEnclosure() nach Überlappungen zu suchen und dann die Strickstärken anzupassen, sofern diese Methoden überhaupt irgendwo implementiert sind).
Allerdings wird das sowohl von IE+ASV als auch von Firefox und Opera in dieser Weise umgesetzt.
Schade, aber auf jeden Fall danke für Deine Hilfen - ich geh davon aus, dass angesichts fehlender Kritik meine Verwendung von <g> so ok ist. Ich hatte mal dran gedacht, das Problem der doppelten (teilweise auch noch mehrfach überlagerten) Linien mit Vektorrechnung zu lösen, also in dem Wust alle Linien zu bestimmen, die Teilmengen anderer Linien sind und dann die Figuren entsprechend zu zerstückeln, aber das scheint mir ein extrem großer Aufwand, der je nach Komplexität dann seinerseits PHP überfordern könnte. Und lernen müsste ich das auch erstmal. Ich hab nochmal einen Thread zum Thema Vektorsoftware und -animation eröffnet, wenn Du was weißt, wäre ich schon wieder sehr dankbar. :)
Ich hab übrigens jetzt den neuen PC, da geht alles tatsächlich deutlich schneller, auch die Animationen sind etwas flüssiger (auf niedrigstem Komplexitätsniveau läuft es sogar ganz geschmiert), aber weder weiß ich, woran das nun liegt, noch bin ich mit den Animationen zufrieden..
-
-
-
-
-
-
-
-
Yerf!
Die Frage ist jetzt nochmal dieselbe wie "SVG und Hardware" im Thread oben: Inwiefern spielt die Hardware überhaupt eine Rolle?
Das hängt wohl von der Software ab, die SVG verwendet. Aber: SVG ist eine 2D-Darstellung, da wird bei den Grafikkarten schon lange nicht mehr optimiert...
Von daher dürfte eher der Prozessor interessant sein. Nebenschauplatz ist der RAM, damit alles dort Platz hat und nicht auf Festplatte ausgelagert werden muss. Die Grafikkarte ist da eher Nebensache, nur keine "Shared Memory", die bremst das ganze System aus.
Gruß,
Harlequin
--
<!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->-
Hallo Harlequin,
Das hängt wohl von der Software ab, die SVG verwendet. Aber: SVG ist eine 2D-Darstellung, da wird bei den Grafikkarten schon lange nicht mehr optimiert...
Auch für 2D-Grafik kann man Hardwareunterstützung verwenden. Viele 2D-Bibliotheken können auch OpenGL o.ä. zum Rendern verwenden (z.B. Cairo, Java2D, ...).
Grüße
Daniel
-
Yerf!
Das hängt wohl von der Software ab, die SVG verwendet. Aber: SVG ist eine 2D-Darstellung, da wird bei den Grafikkarten schon lange nicht mehr optimiert...
Auch für 2D-Grafik kann man Hardwareunterstützung verwenden. Viele 2D-Bibliotheken können auch OpenGL o.ä. zum Rendern verwenden (z.B. Cairo, Java2D, ...).Das sollte eigentlich im ersten Satz bezüglich der Software mit drinn stecken... da hab ich wohl mehr gedacht als ich schlussendlich geschrieben hab...
Gruß,
Harlequin
--
<!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->
-
-
Hi Harlequin.
Die Frage ist jetzt nochmal dieselbe wie "SVG und Hardware" im Thread oben: Inwiefern spielt die Hardware überhaupt eine Rolle?
Das hängt wohl von der Software ab, die SVG verwendet. Aber: SVG ist eine 2D-Darstellung, da wird bei den Grafikkarten schon lange nicht mehr optimiert...
Von daher dürfte eher der Prozessor interessant sein. Nebenschauplatz ist der RAM, damit alles dort Platz hat und nicht auf Festplatte ausgelagert werden muss. Die Grafikkarte ist da eher Nebensache, nur keine "Shared Memory", die bremst das ganze System aus.
Danke auch Dir erstmal, ich werd im Laufe der Woche sehen, wie es mit dem AMD Athlon 64 X2 3600+ und 2 GB RAM aussieht.
-
