DE202009019145U1

DE202009019145U1 - Hardware-beschleunigte Grafiken für Online-Applikationen mithilfe von nativen Code-Modulen

Info

Publication number: DE202009019145U1
Application number: DE202009019145.1U
Authority: DE
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2008-11-07
Filing date: 2009-11-04
Publication date: 2017-01-25
Anticipated expiration: 2019-11-05
Also published as: US10026211B2; US20170345203A1; US20100118038A1; US9767597B1; CN102246146A; WO2010053953A3; WO2010053953A2; CN102246146B; EP2356565A4; US8294723B2; US8797339B2; EP2356565A2; US20130033508A1

Abstract

System für die Ausführung einer Webanwendung, umfassend: ein für das Laden der Webanwendung konfigurierter Webbrowser; eine sichere Laufzeitumgebung, die so konfiguriert ist, dass sie ein natives, mit der Online-Applikation verbundenes Codemodul ausführt; das native Codemodul, das so konfiguriert ist, dass es eine Serie von Wiedergabebefehlen in einen Befehlspuffer schreibt; und ein zuverlässiges Codemodul, das konfiguriert ist: die Wiedergabebefehle aus dem Befehlspuffer zu lesen; und ein Bild für den Gebrauch der Online-Applikation wiederzugeben, indem die Wiedergabebefehle mithilfe einer Grafikprozessoreinheit (GPU) ausgeführt werden.

Description

HINTERGRUND
Technisches Gebiet
Die gegenwärtigen Ausführungsformen beziehen sich auf Techniken zur Ausführung von Applikationen auf Computersystemen. Im Besonderen beziehen sich die gegenwärtigen Ausführungsformen auf ein System für die Ausführung von Online-Applikationen mithilfe von Hardware-beschleunigten Grafiken und nativen Codemodulen. Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind dabei, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
Verwandtes Gebiet
Computersysteme beinhalten häufig mehrere native Applikationen, die zur Wiedergabe komplexe dreidimensionale (3D) Szenen brauchen, wie z. B. Computerspiele und computergestützte Designsysteme (CAD). Um 3D-Szenen wiederzugeben, können diese nativen Applikationen grafische Anwendungsprogrammschnittstellen (APIs) verwenden, welche die Grafikwiedergabe betreffenden Berechnungen an dedizierte Grafikprozessoreinheiten weitergeben (GPUs). Außerdem können diese nativen Applikationen Maschinencode beinhalten, der direkt auf einem oder auf mehreren Prozessoren läuft. Die von diesen Prozessoren und/oder GPUs besorgte Rechenleistung kann die Qualität und Quantität der Grafiken erheblich verbessern.
Online-Applikationen, die in den letzten paar Jahren immer mehr Akzeptanz fanden, sind normalerweise in Skriptsprachen geschrieben, die nicht imstande sind, systemnahe grafische APIs zu verwenden, die eine Grafikhardware-Beschleunigung bieten. Stattdessen wird die Grafikwiedergabe für Online-Applikationen gewöhnlich von den CPUs statt den GPUs durchgeführt. Die Software-orientierte Art und Weise der webbasierten Grafikwiedergabe kann daher die grafischen Fähigkeiten von Online-Applikationen einschränken. Außerdem kann die interpretierte Art und Weise der Skriptsprachen zu erheblich langsameren Ausführungszeiten für Online-Applikationen als für native Applikationen führen. Im Vergleich zu den nativen Applikationen haben die Online-Applikationen aber mehrere Vorteile. Zum Beispiel sind Online-Applikationen fähig, auf mehrfachen Plattformen zu laufen, erfordern keine Installation und können sicherer sein als native Applikationen.
Der Kompromiss zwischen der Sicherheit der Online-Applikation und der Leistung der nativen Grafiken kann mithilfe eines Browser-Plug-ins gelöst werden, das die Grafiken für Online-Applikationen wiedergibt, indem man es an ein lokales Grafikhardwaregerät anschließt (z. B. eine GPU). Ein solches Plug-in kann ein komplexes Softwaresystem sein, das verschiedene Mechanismen zur Erfassung von Szeneinformationen von den Online-Applikationen umfasst; die Speicherung dieser Szeneinformationen; die Verarbeitung der Szeneinformationen mithilfe von Umwandlungen, Effekten und Schattierungen; und Absendung der Befehle an die Grafikhardware für die Wiedergabe der Szene. Außerdem können die Verarbeitungsanforderungen des Plug-ins erfordern, dass das Plug-in mithilfe eines nativen Codes implementiert wird, der normalerweise nicht sicher ist. Infolgedessen kann das Plug-in selbst mehrere potentielle Schwachstellen bei der Sicherheit haben, die von anderen Applikationen und/oder Bugs ausgenutzt werden können, was wiederum zu Systemabstürzen führen kann.
Was daher gefragt ist, ist ein Mechanismus, um den nativen Code für die webbasierte Wiedergabe von Grafiken sicher auszuführen und gleichzeitig die Kommunikation zwischen dem nativen Code und der Grafikhardware aufrechtzuerhalten.
ZUSAMMENFASSUNG
Einige Ausführungsformen stellen ein System bereit, das die Online-Applikation ausführt. Während des Betriebs lädt das System die Online-Applikation in einen Webbrowser und lädt ein natives, mit der Online-Applikation verbundenes Codemodul in eine sichere Laufzeitumgebung. Als Nächstes schreibt das System mithilfe des nativen Codemoduls eine Serie von Wiedergabebefehlen in einen Befehlspuffer und liest gleichzeitig die Wiedergabebefehle aus dem Befehlspuffer. Schließlich gibt das System ein Bild für den Gebrauch der Online-Applikation wieder, indem es die Wiedergabebefehle mithilfe einer Grafikprozessoreinheit ausführt (GPU).
In einigen Ausführungsformen validiert das System auch das native Codemodul, bevor es das native Codemodul in die sichere Laufzeitumgebung lädt.
In einigen Ausführungsformen zeigt das System das Bild auch innerhalb des Webbrowsers.
In einigen Ausführungsformen schreibt das System die mit den Wiedergabebefehlen verbundenen Pufferdaten mithilfe des nativen Codemoduls auch auf einen gemeinsamen Pufferspeicher und gibt auch das Bild wieder, indem es die Pufferdaten aus dem gemeinsamen Pufferspeicher liest.
In einigen Ausführungsformen werden der gemeinsame Pufferspeicher und der Befehlspuffer mithilfe eines intermodularen Kommunikationspuffers (IMC) implementiert.
In einigen Ausführungsformen werden die Wiedergabebefehle weiterhin mithilfe von zumindest einem zuverlässigen Codemodul und einer Wiedergabemaschine ausgeführt.
In einigen Ausführungsformen ist die Online-Applikation mit zumindest einem Scenegraph-Wiedergabegerät, einer Grafikbibliothek, einer Spielmaschine, einem Spiels, einem Hilfsprogramms zur Erzeugung des digitalen Inhalts (DCC), einer Videoverarbeitungsapplikation und einer Bildverarbeitungsapplikation verbunden.
In einigen Ausführungsformen bedeutet die Ausführung der Wiedergabebefehle:

(i) Speicherung einer mit einer Komponente verbundenen Subserie der Wiedergabebefehle im Bild;
(ii) Aktualisierung einer Serie von Parametern, die mit der gespeicherten Subserie der Wiedergabebefehle verbunden sind; und
(iii) Verwendung der gespeichertes Subserie der Wiedergabebefehle und der aktualisierten Parameter, um die Komponente im Bild wiederzugeben.

KURZE BESCHREIBUNG DER FIGUREN
1 ist eine schematische Darstellung der Ausführungsform eines Systems.
2 zeigt den Einsatz von intermodularen Kommunikationspuffern (IMC), um die Interaktion zwischen einem nativen Codemodul und einem zuverlässigen Codemodul gemäß einer Ausführungsform des Systems zu erleichtern.
3 zeigt ein Flussdiagramm, das den Vorgang der Ausführung einer Online-Applikation veranschaulicht.
4 zeigt ein Flussdiagramm, das den Vorgang der Wiedergabe einer Komponente in einem Bild veranschaulicht.
AUSFÜHRLICHE BESCHREIBUNG
Die folgende Beschreibung wird dargestellt, um es einem Fachmann zu ermöglichen, die Ausführungsformen herzustellen und zu verwenden, und wird im Rahmen einer bestimmten Applikation und deren Anforderungen bereitgestellt. Mehrere Änderungen an den offenbarten Ausführungsformen sind für den Fachmann augenscheinlich, und die hierin definierten allgemeinen Grundsätze können auf andere Ausführungsformen und Applikationen übertragen werden, ohne vom Geist und von der Reichweite der gegenwärtigen Ausführungsformen abzuweichen. Das System ist also nicht auf die aufgeführten Ausführungsformen beschränkt, sondern soll den hierin offenbarten Grundsätzen und Merkmalen entsprechend mit dem größtmöglichen Anwendungsbereich bewilligt werden.
Die in dieser ausführlichen Erklärung beschriebenen Datenstrukturen und der Code werden gewöhnlich auf einem maschinenlesbaren Speichermedium gespeichert, das ein beliebiges Gerät oder Medium sein kann, das den Code und/oder die Daten für den Gebrauch eines Computersystems speichern kann. Das computerlesbare Speichermedium umfasst, ist aber nicht begrenzt auf, flüchtige Speicher, nichtflüchtige Speicher, magnetische und optische Speichervorrichtungen wie Laufwerke, Magnetbänder, CDs, DVDs und andere bereits bekannte oder später entwickelte Medien, die in der Lage sind computerlesbare Medien zu speichern.
Die in dieser ausführlichen Erklärung beschriebenen Verfahren und Vorgänge können als Code und/oder als Daten dargestellt werden, die in einem maschinenlesbaren Speichermedium wie oben beschrieben gespeichert werden können. Wenn ein Computersystem den Code und/oder Daten auf dem computerlesbaren Speichermedium liest und ausführt, führt das Computersystem die Methoden und Prozesse aus, die als Datenstrukturen und Code ihren Ausdruck finden und auf dem computerlesbaren Speichermedium sind.
Außerdem können die weiter unten beschriebenen Verfahren und Vorgänge in die Hardwaremodule einbezogen werden. Hardwaremodule können unter anderem ASIC-Chips (Applikation-Specific Integrated Circuit), FPGAs (Field-Programmable Gate Arrays) und andere programmierbare logische Schaltungen umfassen, die bereits bekannt sind oder noch entwickelt werden. Wenn die Hardwaremodule aktiviert werden, führen die Hardwaremodule die Verfahren und Prozesse aus, die in den Hardwaremodulen enthalten sind.
Die Ausführungsformen bieten ein Verfahren und ein System zur Ausführung einer Online-Applikation. Die Webanwendung kann in einen Webbrowser geladen und in einem Rechensystem ausgeführt werden. Beispiele für Rechensysteme sind Personal Computer (PCs), PDAs, Grafikrechner, tragbare Medienplayer, GPS-Receiver und/oder andere elektronische Rechengeräte. Das Rechensystem kann die Webanwendung von einem Server abrufen – unter Verwendung einer Netzwerkverbindung zu diesem Server. So lässt sich die Webanwendung zum Beispiel über das Internet von einer Website herunterladen.
Insbesondere bieten die Ausführungsformen ein Verfahren und ein System für die Wiedergabe von Grafiken für die Online-Applikation. Ein natives, mit der Online-Applikation verbundenes Codemodul kann innerhalb einer sicheren Laufzeitumgebung innerhalb eines mit dem Webbrowser verbundenen Plug-ins ausgeführt werden. Um Grafiken für die Online-Applikation wiederzugeben, kann das native Codemodul Wiedergabebefehle an ein zuverlässiges Codemodul erteilen, welches das Plug-in mithilfe einer Befehlspufferschnittstelle besorgt.
Um die Befehlspufferschnittstelle zu verwenden, kann das native Codemodul Wiedergabebefehle in einen Befehlspuffer schreiben. Das zuverlässige Codemodul kann dann die Wiedergabebefehle aus dem Befehlspuffer lesen und ein Bild für die Online-Applikation wiedergeben, indem es die Wiedergabebefehle mithilfe einer Grafikprozessoreinheit (GPU) auf dem Computersystem ausführt. Das native Codemodul kann außerdem die mit den Komponenten verbundenen Wiedergabebefehle im Bild für die zukünftige Erteilung der Wiedergabebefehle mit aktualisierten Parametern speichern. Zum Beispiel kann das native Codemodul Wiedergabebefehle erteilen, um ein Modell des Bildes über die Einzelbilder hinweg zu animieren, indem es die gleichen Wiedergabebefehle für das Modell mithilfe von aktualisierten Parametern für jedes Einzelbild der Animation in den Befehlspuffer schreibt. Infolgedessen können Ausführungsformen den Online-Applikationen erlauben, Grafikbibliotheken, Scenegraph-Wiedergabegeräte, Computerspiele und Spielmaschinen, Videobearbeitungs- und Fotobearbeitungsmerkmale und/oder Hilfsprogramme zur Erzeugung des digitalen Inhalts (DCC) sicher zu implementieren.
1 ist eine schematische Darstellung der Ausführungsform eines Systems. Das System umfasst ein Computersystem 102 und wahlweise mehrere Servers (z. B. Server 1 104, Server x 106). Rechensystem 102 beinhaltet eine Webanwendung 116, die in einem Webbrowser 110 mit dem Plug-in 108 ausgeführt wird. Alle genannten Komponenten werden im Folgenden genauer beschrieben.
Das Computersystem 102 kann ein elektronisches Gerät sein, das einem Benutzer eine oder mehrere Dienstleistungen oder Funktionen bietet. So kann Rechensystem 102 zum Beispiel als mobiles Telefon, PC(personal computer), GPS(global positioning system)-Receiver, tragbarer Medienplayer, PDA (personal digital assistant) und/oder Grafikrechner genutzt werden. Zusätzlich kann das Computersystem 102 ein Betriebssystem (nicht gezeigt) umfassen, das die Verwendung von Hardware- und Softwareressourcen auf dem Computersystem 102 sowie einer oder mehreren Anwendungen (, z. B. Webbrowser 110, Web-Anwendung 116) koordiniert, die spezielle Aufgaben für den Benutzer ausführen. Rechensystem 102 kann zum Beispiel Anwendungen wie einen E-Mail-Client, ein Adressbuch, einen Editor für Dokumente, Webbrowser 110 und/oder einen Medienplayer umfassen. Zur Erledigung von Aufgaben für den Benutzer können Anwendungen in Rechensystem 102 mit dem Betriebssystem auf Hardwareressourcen (wie Prozessor, Arbeitsspeicher, I/O-Komponenten, Drahtlossender usw.) zurückgreifen. Außerdem können sie mit dem Benutzer via ein vom Betriebssystem bereitgestelltes Hardware- und/oder Software-Framework interagieren (siehe Beschreibung unten).
Der Fachmann wird es zu schätzen wissen, dass das Computersystem 102 die Funktionalität besitzt, sowohl native Applikationen als auch nicht-native Applikationen auszuführen. In anderen Worten: Rechensystem 102 kann native Anwendungen wie Webbrowser 110 umfassen, die lokal in Rechensystem 102 installiert sind und auf das Betriebssystem und/oder eines bzw. mehrere Hardwaregeräte in Rechensystem 102 angewiesen sind. Solche Anwendungen können in nativem Code (z. B. Maschinencode) kompiliert sein, der direkt auf einem oder mehreren Prozessoren (CPUs) von Rechensystem 102 ausgeführt wird. Die Codeausführung für solche Applikationen kann des Weiteren dadurch optimiert werden, dass man die Applikationen in einer Kombination aus einer universellen Programmiersprache (z. B. C, C++, etc.) und einer Assemblersprache schreibt und Bibliotheken verwendet, die einen Hardwarebeschleunigung (z. B. eine Grafikhardware-Beschleunigung) für die Applikationen bieten. Die Installation von nativen Applikationen kann aber die Sicherheit des Computersystems 102 und der privaten, auf dem Computersystem 102 gespeicherten Daten gefährden.
Das Computersystem 102 kann auch die Funktionalität besitzen, nicht-native, von der Plattform unabhängige Applikationen auszuführen. Insbesondere kann Rechensystem 102 die Webanwendung 116 von einem oder mehreren Servern abrufen (z. B. Server 1 104, Server x 106), unter Verwendung einer Netzwerkverbindung mit dem Server/den Servern, und die Webanwendung 116 in den Webbrowser 110 laden. Webanwendung 116 lässt sich zum Beispiel über das Internet mittels Webbrowser 110 von einem Anwendungsserver herunterladen. Wechselweise kann man nicht-native Applikationen von anderen Quellen wie z. B. einer Disk holen.
Nachdem man sie geladen hat, kann die Online-Applikation 116 Eigenschaften und eine Benutzer-Interaktion bieten, die mit denen der nativen Applikationen auf dem Computersystem 102 vergleichbar sind. Webanwendung 116 zum Beispiel kann als E-Mail-Client, Editor für Dokumente, Medienplayer, CAD-System (Computer-Aided Design) und/oder Computerspiel dienen. Außerdem kann Webanwendung 116 Elemente einer dynamischen Benutzeroberfläche wie Menüs, Schaltflächen, Fenster, Unterfenster, Symbole, Animationen und/oder andere grafische Objekte umfassen, die Elemente einer analogen Benutzeroberfläche in nativen Anwendungen emulieren. In anderen Worten: Webanwendung 116 kann auf eine Rich Internet Application (RIA) reagieren.
Außerdem kann die Online-Applikation 116 auf dem Computersystem 102 unabhängig von der mit Computersystem 102 verbundenen Plattform (z. B. Betriebssystem, Treiberprogramme usw.) laufen. Obwohl plattformunabhängige Anwendungen wie die Webanwendung 116 portabler und sicherer als native Anwendungen sein können, können solchen plattformübergreifenden Anwendungen bestimmte Leistungsfähigkeiten von nativen Anwendungen fehlen.
Insbesondere können nicht-native Applikationen wie z. B. die Online-Applikation 116 mithilfe der Skriptsprachen geschrieben werden, die interpretiert und nicht kompiliert sind, wie z. B. Javascript (JavaScript^TM ist ein geschütztes Warenzeichen von Sun Microsystems, Inc.). Der interpretierte Charakter der Webapplikation 116 und/oder andere nicht native Anwendungen können zu wesentlich geringeren Ausführungszeiten für nicht native Anwendungen führen als die von kompilierten nativen Anwendungen. Außerdem kann es sein, dass nicht native Anwendungen untergeordnete Bibliotheken und/oder APIs nicht nutzen können, die bei nativen Anwendungen zur Verfügung stehen. Daher ist es möglich, dass nicht native Anwendungen bei bestimmten Aufgaben nur eingeschränkte Funktionen unterstützen.
Insbesondere ist die Online-Applikation 116 eventuell nicht imstande, eine Grafikhardware-Beschleunigung (z. B. von der Grafikprozessoreinheit (GPU) 124 bei der Wiedergabe der Grafiken zu verwenden. Zum Beispiel kann die Online-Applikation 116 in einer Sprache geschrieben sein (z. B. Javascript), die keine Schnittstelle mit der GPU 124 hat. Stattdessen kann die Wiedergabe von Grafiken für die Online-Applikation 116 mithilfe von Software durchgeführt werden, die auf einer CPU des Computersystems 102 läuft und nicht auf einer GPU 124. Deshalb können Grafiken in der Online-Applikation 116 im Vergleich mit Grafiken in den nativen Applikationen, die eine Grafikhardware-Beschleunigung benötigen, suboptimal sein.
Beschränkungen in der Grafikwiedergabe für die Online-Applikation 116 kann die Online-Applikation 116 weiter daran hindern, Eigenschaften zu bieten, die beträchtliche Ressourcen zur Grafikverarbeitung aufbrauchen, einschließlich der Grafikhardware-Beschleunigung. Zu diesen Funktionen können gehören:

• Grafikbibliotheken: Direct3D (Direct3D^TM ist ein eingetragenes Warenzeichen von Microsoft Corp.), OpenGL (OpenGL^TM ist ein eingetragenes Warenzeichen von Silicon Graphics, Inc.), usw.
• Spielmaschinen und/oder Computerspiele, die den Spielern 3D-Computergrafiken in Echtzeit bieten
• Scenegraph-Wiedergabesysteme für dreidimensionale (3D) Computergrafiken
• Erzeugung des digitalen Inhalts (DCC) und/oder Hilfsprogramme für den computergestützten Design (CAD)
• Videobearbeitungseigenschaften
• Fotobearbeitungseigenschaften

Mit anderen Worten, die Online-Applikation 116 ist eventuell nicht imstande, leistungsfähige Eigenschaften zu implementieren, die wegen der Unfähigkeit, auf die GPU 124 der Online-Applikation 116 zuzugreifen, eine rechnerisch intensive (z. B. Hardwarebeschleunigung) Wiedergabe von Grafiken erfordern.
Um die Unterstützung und Hardware-Beschleunigung der Grafiken für Online-Applikationen zu ermöglichen, kann man die mit der Grafikverarbeitung verbundenen Operationen an einen Plug-in 108 im Computersystem 102 abgibt. Das Plug-in 108 kann der Online-Applikation 116 die Fähigkeiten einer GPU 124 geben und es der Online-Applikation 116 damit erlauben, Grafikhardware-Beschleuniger einzusetzen, einschließlich der Vertex- und Pixelabschattierung. Die auf ein Plug-in basierende Grafikhardware-Beschleunigung für Online-Applikationen wurde von den Erfindern Robin Green, Evangelos Kokkevis, Matthew Papakipos und Gregg Tavares in einer zusammen bevorstehenden Gebrauchsmusteranmeldung beschrieben und am 16. Juli 2008 unter dem Titel „Web-basiertes Grafikwiedergabesystem” mit der Seriennummer 12/174,586 angemeldet, und ist hier durch Hinweis einbezogen.
Wie in 1 gezeigt wird, umfasst das Plug-in 108 ein natives Codemodul 118 und ein zuverlässiges Codemodul 122. Die Interaktion zwischen dem nativen Codemodul 118 und dem zuverlässigen Codemodul 122 kann es dem Plug-in 108 ermöglichen, der Online-Applikation 116 eine Grafikhardware-Beschleunigung zu verschaffen. Außerdem kann die Validierung des nativen Codemoduls 118 durch einen Validierer 112 im Plug-in 108 und die Ausführung des nativen Codemoduls 118 innerhalb einer sicheren Laufzeitumgebung 114 im Plug-in 108 die sichere Ausführung der Wiedergabebefehle durch die GPU 124 für die Online-Applikation 116 erleichtern, wie ausführlich später noch besprochen wird.
Wie im Fall der Online-Applikation 116 kann mit dem Webbrowser 110 auch das native Codemodul 118 von einem oder mehreren Servern (z. B. Server 1 104, Server x 106) eingeholt werden. Webanwendung 116 kann zum Beispiel einen Hyperlink zum nativen Code-Modul 118 im Internet bereitstellen. Anschließend kann Webbrowser 110 das native Code-Modul 118 über die im Hyperlink enthaltene URL herunterladen. Alternativ kann das native Code-Modul 118 vom Benutzer oder einer externen Quelle (wie einer anderen Webanwendung und/oder nativen Anwendung) festgelegt werden.
In einer oder in mehreren Ausführungsformen umfasst das Plug-in 108 eine Vielzahl von Mechanismen, um die sichere Ausführung des nativen Codemoduls 118 sicherzustellen. Insbesondere kann das native Code-Modul 118 von einem Validierer 112 (bereitgestellt durch Plug-in 108) vor der Ausführung validiert werden. Die Validierung des nativen Codemoduls wurde von den Erfindern J. Bradley Chen, Matthew T. Harren, Matthew Papakipos, David C. Sehr und Bennet S. Vee in einer zusammen bevorstehenden Gebrauchsmusteranmeldung unter dem Titel „Verfahren für die Validierung eines Unzuverlässigen Nativen Codemoduls” mit Seriennummer 12/117,634 beschrieben und am Anmeldetag, dem 8. Mai 2008, eingereicht, und ist hier durch Hinweis einbezogen.
Sobald das native Codemodul 118 validiert ist, kann das native Codemodul 118 in eine sichere, vom Plug-in 108 gebotene Laufzeitumgebung 114 geladen werden. Die native Codeausführung in einer sicheren Laufzeitumgebung wurde von den Erfindern J. Bradley Chen, Matthew T. Harren, Matthew Papakipos, David C. Sehr, Bennet S. Yee und Gregory Dardyk in einer zusammen bevorstehenden Gebrauchsmusteranmeldung unter dem Titel „Verfahren für die Sichere Ausführung eines Unzuverlässigen Nativen Codemoduls auf einem Computergerät” mit Seriennummer 12/117,650 beschrieben und am Anmeldetag, den 8. Mai 2008, eingereicht, und ist hier durch Hinweis einbezogen.
Des Weiteren, weil das native Codemodul 118 einen direkt auf der Hardware laufenden binären Code enthalten kann, kann das native Codemodul 118 von der Plattform in Bezug auf das Betriebssystem des Computersystems 102, des Webbrowsers 110 und/oder der sonstigen Softwarekomponenten auf dem Computersystem 102 unabhängig sein. Wie in den genannten Anmeldungen beschrieben können das Plug-in 108 und/oder das native Code-Modul 118 auch Verfahren für die Ausführung verschiedener Befehlssatzarchitekturen (inkl. „Fat Binaries” und Binärübersetzer) beinhalten.
Insbesondere kann das native Codemodul 118 einem Softwaremodul entsprechen, das nativen Code enthält und direkt auf der vom Computersystem 102 bereitgestellten Hardware läuft, wie z. B. einer CPU. Infolgedessen kann das native Codemodul 118 verwendet werden, um Aufgaben auszuführen, die in erheblichem Maße Zugang zu den CPU-Ressourcen des Computersystems 102, einschließlich hochrangiger Grafikwiedergabefähigkeiten für die Online-Applikation 116 erfordern. Zum Beispiel kann das native Codemodul 118 ein Scenegraph-Wiedergabegerät für die Online-Applikation 116 implementieren. Wechselweise kann das native Codemodul 118 ein systemnäheres Wiedergabegerät wie eine OpenGL oder eine Direct3D-Bibliothek innerhalb einer sicheren Laufzeitumgebung 114 auf sichere Weise implementieren.
Außerdem kann ein Teil oder die Gesamtheit der Online-Applikation 116 innerhalb des nativen Codemoduls 118 laufen. Zum Beispiel kann die Online-Applikation 116 einem 3D-Computerspiel entsprechen, das innerhalb des Webbrowsers 110 läuft. Daher kann die Applikation 116 ein oder mehrere nativen Codemodule enthalten, welche die physische Umgebung im Computerspiel und/oder ein oder mehrere nativen Codemodule simulieren, die 3D-Grafiken im Computerspiel in Echtzeit wiedergeben.
Wie vorher erwähnt wurde, kann das native Codemodul 118 mit dem zuverlässigen Codemodul 122 interagieren, um der Online-Applikation 116 eine Grafikhardware-Beschleunigung zu verschaffen. Insbesondere kann das native Codemodul 118 von der Online-Applikation 116 Anfragen für eine Grafikwiedergabe über eine Grafikschnittstelle (z. B. einen Scenegraph) mit der Online-Applikation 116 erhalten. Die Grafikschnittstelle kann es dem nativen Codemodul 118 ermöglichen, ein für die Online-Applikation 116 wiederzugebendes Grafikmodell einzuholen und/oder zu speichern. Das Grafikmodell kann zum Beispiel eine Serie von aus Dreiecken oder Polygonen zusammengestellten Formen, eine oder mehrere Lichtquellen, eine Kamera und/oder eine oder mehrere Wiedergabeeffekte enthalten (z. B. Schattierungen, Auswahl, Mischung, usw.). Wie in den oben angeführten Anmeldungen beschrieben, kann das Grafikmodell auch in einer oder in mehreren Datenstrukturen wie z. B. in Scenegraphs, Puffer und/oder Effekten gespeichert werden.
Die Ausführung des nativen Codemoduls 118 innerhalb der sicheren Laufzeitumgebung 114 kann aber das native Codemodul 118 daran hindern, auf die Hardwaregeräte auf dem Computersystem 102 wie z. B. der GPU 124, zuzugreifen. Stattdessen kann das native Codemodul 118 eine Serie von Wiedergabefehlen an das zuverlässige Codemodul 122 mithilfe einer Befehlspufferschnittstelle 120 mit dem zuverlässigen Codemodul 122 übermitteln. Insbesondere kann das native Codemodul 118 als Software-Client funktionieren, der Wiedergabebefehle an den von der Befehlspufferschnittstelle 120 bereitgestellten Befehlspuffer schreibt, die dem Grafikmodell entsprechen. Das native Codemodul 118 kann auch Pufferdaten in einen gemeinsamen, von der Befehlspufferschnittstelle 120 bereitgestellten Speicherpuffer schreiben.
Das zuverlässige Codemodul 122 kann als Softwaredienstleistung laufen, welche die Wiedergabefehle vom Befehlspuffer und die Pufferdaten vom gemeinsamen Speicherpuffer liest. Weil das zuverlässige Codemodul 122 außerhalb der sicheren Laufzeitumgebung 114 läuft, kann das zuverlässige Codemodul 122 die Fähigkeit haben, mit der GPU 124 zu kommunizieren. Infolgedessen kann das zuverlässige Codemodul 122 ein Bild für den Gebrauch der Online-Applikation 116 wiedergeben, indem es die Wiedergabebefehle vom Befehlspuffer mithilfe einer direkten Schnittstelle mit der GPU 124 und/oder einer Schnittstelle mit einem Wiedergabegerät wie z. B. der OpenGL oder Direct3D ausführt. Das wiedergegebene Bild kann dann innerhalb des Browsers 110 als Output der Online-Applikation 116 dargestellt werden. Die sichere webbasierte Grafikwiedergabe mit Software-Clients, Software-Dienstleistungen und Befehlspufferschnittstellen wurde vom Erfinder Antoine Labour in einer zusammen bevorstehenden Gebrauchsmusteranmeldung beschrieben und wurde am gleichen Tag wie die sofortige Anmeldung unter dem Titel „Befehlspuffer für eine Web-basierte Grafikwiedergabe” mit der Seriennummer NOCH OFFEN und dem Anmeldetag NOCH OFFEN angemeldet, und ist hier durch Hinweis einbezogen.
In einer oder in mehreren Ausführungsformen sind der Befehl und die gemeinsamen Speicherpuffer mithilfe eines intermodularen Kommunikationspuffers (IMC) implementiert. Die Übermittlung der Wiedergabebefehle und/oder der Pufferdaten zwischen dem nativen Codemodul 118 und dem zuverlässigen Codemodul 122 mithilfe des IMC-Puffers wird unten in Bezug auf FIG. besprochen. 2.
In einer oder in mehreren Ausführungsformen umfasst das native Codemodul 118 eine Funktionalität, um die mit einer oder mehreren Komponenten verbundenen Wiedergabebefehle im Grafikmodell und/oder im Bild zu speichern. Das native Codemodul kann dann die gespeicherten Wiedergabebefehle einem zuverlässigen Codemodul 122 liefern, indem es die Wiedergabebefehle in den Befehlspuffer schreibt, ohne die Werte der Wiedergabebefehle nachzurechnen. Die Wiedergabebefehle können auch eine Serie von mit der Komponente verbundenen Parameter festsetzen, wie z. B. die Vertexpufferdaten, Indexpufferdaten, Effektdaten und/oder Beschaffenheitsdaten. Infolgedessen können mehrfache Wiedergaben der Komponente durchgeführt werden, indem man die gespeicherten Wiedergabebefehle in den Befehlspuffer schreibt und die Werte für die Parameter der Komponenten mithilfe des Befehlspuffers und/oder des gemeinsamen Speicherpuffers aktualisiert. Die Speicherung von Wiedergabebefehlen kann also die Leistung verbessern, indem sie den Verarbeitungsaufwand reduziert, den das native Codemodul 118 braucht, um Wiedergabefehle an den Befehlspuffer zu erteilen.
Zum Beispiel kann ein Charakter in einem Computerspiel mit zwei Komponenten (z. B. Objekten) verbunden sein. Um den Charakter zu zeichnen, kann das native Codemodul 118 eine Serie von Wiedergabebefehlen in der folgenden Reihenfolge an den Befehlspuffer erteilen:
Effekt einstellen
Umwandlungsmatrizen für das erste Objekt einstellen
Vertexpuffer für das erste Objekt einstellen Erstes Objekt zeichnen
Umwandlungsmatrizen für das zweite Objekt einstellen
Vertexpuffer für das zweite Objekt einstellen
Zweites Objekt zeichnen
Um den Charakter zu animieren (z. B. während jedes Einzelbilds), kann das native Codemodul 118 die gleichen Wiedergabebefehle in den Befehlspuffer schreiben und nur die bei der Animation verwendeten Parameter (z. B. die Umwandlungsmatrizen) andern. Die aktualisierten Parameter können in den Befehlspuffer, im gemeinsamen Speicherpuffer und/oder in einer anderen Serie von Puffer (z. B. Vertexpuffer) geschrieben oder gespeichert werden. Mit anderen Worten, weil die inhärente Struktur der Wiedergabebefehle die gleiche ist, kann das native Codemodul 118 die Wiedergabebefehle für den Charakter speichern und die aktualisierten Parameter in die gespeicherte Befehlspufferstruktur einfügen, statt die Wiedergabebefehle für jedes Einzelbild der Animation nachzurechnen.
2 zeigt die Benutzung von intermodularen Kommunikationspuffern (IMC), um die Interaktion zwischen dem nativen Codemodul 118 und dem zuverlässigen Codemodul 122 gemäß einer Ausführungsform des Systems zu erleichtern. Wie in 2 gezeigt,, ein IMC-Puffer 206 ist konfiguriert, um einen Befehlspuffer 208 und einen gemeinsamen Speicherpuffer 210 für den Gebrauch des nativen Codemoduls 118 und des zuverlässigen Codemoduls 122 zu speichern. Der IMC-Puffer 206 kann vom nativen Codemodul 118 und/oder vom zuverlässigen Codemodul 122 während der Initialisierung erzeugt und zwischen dem nativen Codemodul 118 und dem zuverlässigen Codemodul 122 geteilt werden. Deshalb können sowohl das native Codemodul 118 als auch das zuverlässige Codemodul 122 den IMC-Puffer 206 ihren jeweiligen Adressenräumen zuordnen. Außerdem können sowohl das native Codemodul 118 als auch das zuverlässige Codemodul 122 auf den IMC-Puffer 206 über eine IMC-Schnittstelle und/oder IMC-Laufzeit zugreifen. Zum Beispiel können das native Codemodul 118 und/oder das zuverlässige Codemodul 122 die IMC-Schnittstelle und/oder die IMC-Laufzeit benutzen, um den Befehlspuffer 208 und/oder den gemeinsamen Speicherpuffer 210 innerhalb des IMC-Puffers 206 zu erzeugen.
Darüber hinaus kann das native Codemodul 118 dem verlässlichen Codemodul 122 Wiedergabebefehle und/oder Pufferdaten übermitteln, indem es zuerst auf den IMC-Puffer 206 über die IMC-Schnittstelle zugreift und dann die Wiedergabebefehle in den Befehlspuffer 208 und die Pufferdaten in den gemeinsamen Speicherpuffer 210 mithilfe die Befehlspufferschnittstelle schreibt. Auf ähnliche Weise kann das zuverlässige Codemodul 122 die Wiedergabebefehle und/oder die Pufferdaten erhalten, indem es zuerst auf den IMC-Puffer 206 über die IMC-Schnittstelle zugreift und dann die Wiedergabebefehle vom Befehlspuffer 208 und die Pufferdaten vom gemeinsamen Speicherpuffer 210 mithilfe die Befehlspufferschnittstelle schreibt.
3 zeigt ein Flussdiagramm, das den Vorgang der Ausführung einer Online-Applikation veranschaulicht. In einer oder mehreren Ausführungsformen können ein oder mehrere Schritte ausgelassen, wiederholt und/oder in einer anderen Reihenfolge vorgenommen werden. Dementsprechend darf die spezifische Anordnung der Schritte in 3 sollte nicht als den Umfang der Technik einschränkend ausgelegt werden.
Zuerst wird eine Online-Applikation in einen Webbrowser (Operation 302) geladen. Die Webanwendung lässt sich via Webbrowser von einem Server abrufen. Die Online-Applikation kann bei der Erledigung von Aufgaben für einen Benutzer auch eine Grafikhardware-Beschleunigung verwenden. Zum Beispiel kann die Online-Applikation mit einem Scenegraph-Wiedergabegerät, einer Grafikbibliothek, einer Spielmaschine, einem Spiel, einem DCC- oder CAD-Hilfsprogramm, einer Videoverarbeitungsapplikation und/oder einer Bildverarbeitungsapplikation verbunden sein.
Um der Online-Applikation eine Grafikhardware-Beschleunigung zu verschaffen, kann ein natives, mit der Online-Applikation verbundenes Codemodul eingeholt werden (Operation 304). Das native Code-Modul lässt sich beispielsweise von einer von der Webanwendung festgelegten Quelle herunterladen. Das native Codemodul kann auch vor Ausführung des nativen Codemoduls validiert werden (Operation 306). Wenn das native Codemodul nicht validiert wird, wird das native Codemodul weggeworfen, ohne ausgeführt worden zu sein.
Wenn das native Codemodul validiert wird, wird das native Codemodul in eine sichere Laufzeitumgebung geladen (Operation 308). Die sichere Laufzeitumgebung kann von einem mit dem Webbrowser verknüpften Plug-in bereitgestellt werden. Innerhalb der sicheren Laufzeitumgebung erzeugt und schreibt das native Codemodul mithilfe einer Befehlspufferschnittstelle Wiedergabebefehle in einen Befehlspuffer (Operation 310). (Es sei erwähnt, dass der Vorgang der Erzeugung dieser Wiedergabebefehle von der Darstellung eines Bildes wie z. B. eines Szenendiagramms dem Fachmann sehr wohl bekannt ist und dass alle beliebigen gegenwärtigen oder zukünftigen Techniken für die Erzeugung solcher Wiedergabebefehle verwendet werden können. Gleichzeitig werden die Wiedergabebefehle von einer unabhängig ausführenden Softwaredienstleistung wie z. B. einem zuverlässigen Codemodul aus dem Befehlspuffer gelesen (Operation 312). Das native Codemodul kann mithilfe der Befehlspufferschnittstelle auch wahlweise die mit den Wiedergabebefehlen verbundenen Pufferdaten in einen gemeinsamen Speicherpuffer schreiben (Operation 314). Die Softwaredienstleistung (z. B. das zuverlässige Codemodul) kann dann die Pufferdaten aus dem gemeinsamen Speicherpuffer lesen (Operation 316).
Als Nächstes kann die Softwaredienstleistung ein Bild zum Gebrauch durch die Online-Applikation wiedergeben, indem sie die Wiedergabebefehle mithilfe einer GPU ausführt (Operation 318). Insbesondere kann die Softwaredienstleistung direkt mit der GPU verbunden sein oder auf die GPU über eine Wiedergabemaschine wie das Wiedergabegerät OpenGL oder Direct3D zugreifen. Das wiedergegebene Bild wird dann im Webbrowser (Operation 320) als Output für die Online-Applikation gezeigt. Zum Beispiel kann das wiedergegebene Bild einer aktualisierten Ansicht eines CAD-Modells oder einem neuen Einzelbild eines Computerspiels entsprechen.
4 zeigt ein Flussdiagramm, das den Vorgang der Wiedergabe einer Komponente in einem Bild veranschaulicht. In einer oder mehreren Ausführungsformen können ein oder mehrere Schritte ausgelassen, wiederholt und/oder in einer anderen Reihenfolge vorgenommen werden. Dementsprechend darf die spezifische Anordnung der Schritte in 4 nicht so ausgelegt werden, dass sich der Anwendungsbereich des Verfahrens reduziert.
Zuerst werden die Wiedergabebefehle für die Komponente eingeholt (Operation 402). Die Wiedergabebefehle können von einem zuverlässigen Codemodul aus einem Befehlspuffer zur Ausführung der Wiedergabebefehle geholt werden. Die Wiedergabebefehle werden auch gespeichert (Operation 404). Zum Beispiel können die Wiedergabebefehle in der Speichereinheit außerhalb des Befehlspuffers zum späteren Abruf und zur Verwendung gespeichert werden, nachdem die Wiedergabebefehle im Befehlspuffer mit neuen Wiedergabebefehlen überschrieben worden sind.
Eine Serie von mit der Komponente verbundenen Parametern wird auch eingeholt (Operation 406). Zum Beispiel kann die Komponente einer Form in einem Scenegraph oder Wiedergabegerät mit Parametern entsprechen, die Vertex, Index, Beschaffenheit, Effekt und/oder sonstige Daten umfassen. Die Parameter können vom Befehlspuffer und/oder einem gemeinsamen Speicherpuffer eingeholt werden. Die Wiedergabebefehle werden dann mithilfe der Parameter (Operation 408) ausgeführt, um die Komponente im Bild wiederzugeben.
Die Parameter können auch zur späteren Wiedergabe der Komponente aktualisiert werden (Operation 410). Zum Beispiel können die Parameter aktualisiert werden, um die Komponente in den aufeinander folgenden Einzelbildern des Bildes zu animieren. Wenn die Parameter aktualisiert werden, werden die aktualisierten Parameter (Operation 406) eingeholt und die gespeicherten Wiedergabebefehle werden mithilfe der aktualisierten Parameter ausgeführt (Operation 408). Mit anderen Worten, anstatt die Wiedergabebefehle mit den aktualisierten Parametern aus dem Befehlspuffer nachzurechnen, können die aktualisierten Parameter in die gespeicherte, mit den Wiedergabebefehlen verbundene Befehlspufferstruktur eingefügt werden.
Die Parameter können weiterhin aktualisiert (Operation 410) und eingeholt werden (Operation 406), und die gespeicherten Wiedergabebefehle können mithilfe der aktualisierten Parameter ausgeführt werden (Operation 408), bis die Komponente nicht mehr im Bild wiedergegeben ist. Zum Beispiel können die gespeicherten Wiedergabebefehle und Parameter verwendet werden, um einen Charakter in einem Computerspiel wiederzugeben und/oder zu animieren, bis der Charakter nicht mehr in Sicht ist oder nicht mehr im Computerspiel existiert.
Die obigen Beschreibungen von Ausführungsformen sind nur zum Zweck der Veranschaulichung und zur Beschreibung dargestellt worden. Es ist nicht die Absicht, sie in ihrer Gesamtheit zu nennen oder die Ausführungsformen auf die offenbarten Formen zu begrenzen. Dementsprechend sind viele Modifikationen und Variationen für Fachleute offensichtlich. Zusätzlich ist die obige Bekanntgabe nicht dazu gedacht, die vorliegenden Ausführungsformen zu beschränken. Die Reichweite der Ausführungsformen wird durch die angefügten Ansprüche definiert.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 12/174586 U [0035]
DE 12/117634 U [0038]
DE 12/117560 U [0039]

Claims

System für die Ausführung einer Webanwendung, umfassend: ein für das Laden der Webanwendung konfigurierter Webbrowser; eine sichere Laufzeitumgebung, die so konfiguriert ist, dass sie ein natives, mit der Online-Applikation verbundenes Codemodul ausführt; das native Codemodul, das so konfiguriert ist, dass es eine Serie von Wiedergabebefehlen in einen Befehlspuffer schreibt; und ein zuverlässiges Codemodul, das konfiguriert ist: die Wiedergabebefehle aus dem Befehlspuffer zu lesen; und ein Bild für den Gebrauch der Online-Applikation wiederzugeben, indem die Wiedergabebefehle mithilfe einer Grafikprozessoreinheit (GPU) ausgeführt werden.
System nach Anspruch 1, des Weiteren umfassend: einen Validierer zur Validierung des nativen Code-Moduls vor dessen Ausführung.
System nach Anspruch 1, worin das Bild innerhalb des Webbrowsers gezeigt wird.
System nach Anspruch 1, worin das native Codemodul auch konfiguriert ist, die mit den Pufferdaten verbundenen Wiedergabebefehle in einen gemeinsamen Speicherpuffer zu schreiben, und worin das zuverlässige Codemodul auch konfiguriert ist, das Bild wiederzugeben, indem es die Pufferdaten aus dem gemeinsamen Speicherpuffer liest.
System nach Anspruch 4, worin der gemeinsame Speicherpuffer und der Befehlspuffer mithilfe eines intermodularen Kommunikationspuffers (IMC) implementiert werden.
System nach Anspruch 1, worin das zuverlässige Codemodul mit einer Wiedergabemaschine verbunden ist, die mit der GPU kommuniziert.
System nach Anspruch 1, worin die Online-Applikation mit mindestens einem Scenegraph-Wiedergabegerät, einer Grafikbibliothek, einer Spielmaschine, einem Spiel, einem Hilfsprogramm zur Erzeugung des digitalen Inhalts (DCC), einer Videoverarbeitungsapplikation und einer Bildverarbeitungsapplikation verbunden ist.
System nach Anspruch 1, worin die Ausführung der Wiedergabebefehle Folgendes einbezieht: Speicherung einer mit einer Komponente verbundenen Subserie der Wiedergabebefehle im Bild; Aktualisierung einer Serie von Parametern, die mit der gespeicherten Subserie der Wiedergabebefehle verbunden sind; und Verwendung der gespeicherten Subserie der Wiedergabebefehle und der aktualisierten Parameter, um die Komponente im Bild wiederzugeben.
Maschinenlesbares Speichermedium, auf dem Befehle gespeichert sind, die bei Ausführung durch einen Computer dafür sorgen, dass der Computer ein Verfahren für die Ausführung einer Webanwendung durchsetzt, wobei das Verfahren Folgendes umfasst: Laden der Webanwendung in einen Webbrowser; Laden eines mit der Webanwendung verbundenen nativen Code-Moduls in eine sichere Laufzeitumgebung; durch Schreiben einer Serie von Wiedergabebefehlen mithilfe des nativen Codemoduls in einen Befehlspuffer; durch Auslesen der Wiedergabebefehle aus dem Befehlspuffer; und durch Wiedergeben eines Bildes für den Gebrauch der Online-Applikation, indem die Wiedergabebefehle mithilfe einer Grafikprozessoreinheit (GPU) ausgeführt werden.
Maschinenlesbares Speichermedium nach Anspruch 9, das Verfahren weiterhin umfassend: Validieren des nativen Code-Moduls, bevor das native Code-Modul in die sichere Laufzeitumgebung geladen wird.
Maschinenlesbares Speichermedium nach Anspruch 9, das Verfahren weiterhin umfassend: das Darstellen des Bildes innerhalb des Webbrowsers.
Maschinenlesbares Speichermedium nach Anspruch 9, das Verfahren weiterhin umfassend: das Schreiben der mit den Wiedergabebefehlen verbundenen Pufferdaten in einen gemeinsamen Speicherpuffer mithilfe des nativen Codemoduls; und das weitere Wiedergeben des Bildes, indem die Pufferdaten aus dem gemeinsamen Speicherpuffer ausgelesen werden.
Maschinenlesbares Speichermedium nach Anspruch 12, worin der gemeinsame Speicherpuffer und der Befehlspuffer mithilfe eines intermodularen Kommunikationspuffers (IMC) implementiert werden.
Maschinenlesbares Speichermedium nach Anspruch 9, worin die Wiedergabebefehle auch mithilfe mindestens eines zuverlässigen Codemoduls und der Wiedergabemaschine ausgeführt werden.
Maschinenlesbares Speichermedium nach Anspruch 9, worin die Online-Applikation mit mindestens einem Scenegraph-Wiedergabegerät, einer Grafikbibliothek, einer Spielmaschine, einem Spiels, einem Hilfsprogramm zur Erzeugung des digitalen Inhalts (DCC), einer Videoverarbeitungsapplikation und einer Bildverarbeitungsapplikation verbunden ist.
Maschinenlesbares Speichermedium nach Anspruch 9, worin das Ausführen der Wiedergabebefehle Folgendes einbezieht: Speicherung einer mit einer Komponente verbundenen Subserie der Wiedergabebefehle im Bild; Aktualisierung einer Serie von Parametern, die mit der gespeicherten Subserie der Wiedergabebefehle verbunden sind; und Verwendung der gespeicherten Subserie der Wiedergabebefehle und der aktualisierten Parameter, um die Komponente im Bild wiederzugeben.