<
>
swopdoc logo
Download
a) trade for free
b) buy for 2.38 $
Document category

Specialised paper
Information Technology / Computer S

University, School

Köln, Realschule

Grade, Teacher, Year

3, Prof. lang, 2013

Author / Copyright
Text by Glenn G. ©
Format: PDF
Size: 0.07 Mb
Without copy protection
Rating [details]

Rating 4.5 of 5.0 (2)
User:
Super text und alles gut und ausführ­lich erklärt­. Keine rechtsch­reibfehl­er. Ich bin begeiste­rt und würde mich sehr um eine fortsetz­ung der reihe wünsche­n.

Live Chat
Chat Room
Networking:
0/1|0[-3.0]|1/9













More documents
JSP Inhalt 1 Hypertext Transfer Protocol 3 1.1 HTTP Allgemein. 3 1.2 POST / GET. 4 1.3 Error-Codes. 4 2 Sessions. 4 2.1 Allgemeines zu Sessions. 4 2.2 Sessions in JSP. 5 2.3 Wann wird eine Session beendet?. 5 3 JSP. 5 3.1 Syntax. 5 3.2 Aufbau. 6 3.2.1 Direktiven. 6 3.2.2 Skriptingelemente.­ 7 3.2.3 Action-Elemente.
Preview page 3 of 4 : [1] [2] [3] [4]

optimieren. Deshalb gibt es seit Java Version 1.4 einen neuen Bildtyp, der auf die automatisierte

Verwaltung und Synchronisation verzichtet und das Bild direkt im hardwarebeschleunigten Bereich,

also dem VRAM bei Windows Betriebssystemen, anlegt.

Dadurch entfällt das Kopieren aus dem

Hauptspeicher und das Verändern der Pixel wird durch hardwarebeschleunigte Grafik-Funktionen

direkt im VRAM durchgeführt. So wird nicht nur die CPU entlastet, sondern Grafik-Operationen

können auch parallel, durch die Verwendung der Grafik-Hardware, durchgeführt werden.

Dieser

neue, beschleunigte Bildtyp heißt VolatileImage.

(Quelle: VolatileImage.pdf)

Wie das Wort Volatile (auf Deutsch “flüchtig”) aber schon andeutet, ist das VRAM ein “flüchtiger”

Speicherbereich, in dem Daten jederzeit überschrieben werden können.

Deshalb müssen bei der

Verwendung eines VolatileImages auch spezielle Maßnahmen getroffen werden, um den korrekten

Inhalt des Bildes sicherzustellen bzw. bei Bedarf zu erneuern. Diesen Zusatzaufwand muß man hier

leider betreiben, bekommt aber im Gegenzug einen extrem performanten Bild-Typ.

Da ein

Überschreiben der Bilddaten im VRAM seltener auftritt, als man es zunächst annehmen würde und

zudem auch noch durch das Betriebssystem signalisiert wird, eignet sich das VolatileImage perfekt

als BackBuffer für das DoubleBuffering.

Folgende Situationen führen zu einem Überschreiben von Daten im VRAM:

• Ausführen einer anderen Anwendung im Fullscreen-Modus

• Starten eines Bildschirmschoners

• Unterbrechen eines Tasks über den Taskmanager (unter Windows)

• Verändern der Bildschirmauflösung

VolatileImage als BackBuffer

Wird ein VolatileImage als BackBuffer verwendet, dann muß man vor jedem Zugriff auf den

BackBuffer überprüfen, ob dieser noch gültig ist und bei Bedarf einen neuen BackBuffer erzeugen.

Außerdem muß man nach dem Rendern überprüfen, ob der Inhalt des VolatileImages in der

Zwischenzeit vielleicht überschrieben wurde und ggf. nochmal neu rendern.

Ist dieser Fall jedoch

nicht eingetreten, dann kann man den BackBuffer jetzt auf dem Bildschirm anzeigen.Der veränderte Quellcode könnte in ungefähr so aussehen:

import java.awt.*;

import java.awt.image.*;

import javax.swing.JComponent;

public class MyComponent extends JComponent

{

private VolatileImage backBuffer;

private Image myImage;

// more code to write here .

private void createBackBuffer()

{

// get the actual GraphicsConfiguration and create a compatible

// VolatileImage as BackBuffer

GraphicsConfiguration gc = getGraphicsConfiguration();

backBuffer = gc.createCompatibleVolatileImage(getWidth(),getHeight());

}

public void renderScreen()

{

// if backBuffer doesn't exist, create one

if (backBuffer == null) createBackBuffer();

do

{

// validate the backBuffer

int valCode = backBuffer.validate(getGraphicsConfiguration());

if (valCode == VolatileImage.IMAGE_RESTORED)

{

System.out.println("backBuffer - IMAGE_RESTORED");

// This case is just here for illustration

// purposes.

Since we are

// recreating the contents of the back buffer

// every time through this loop, we actually

// do not need to do anything here to recreate

// the contents. If our VImage was an image that

// we were going to be copying _from_, then we

// would need to restore the contents at this point

}

else if (valCode == VolatileImage.IMAGE_INCOMPATIBLE)

{

// backBuffer Image is incompatible with actual screen

// settings, so we have to create a new compatible one

System.out.println("backBuffer - IMAGE_INCOMPATIBLE");

createBackBuffer();

}

// get Graphics object from backbuffer

Graphics g = backBuffer.getGraphics();

// render on backbuffer

g.drawImage(myImage,0,0,this);

g.drawLine(0,0,10,20);

// .

// rendering is done; now check if contents got lost

// and loop if necessary

} while (backBuffer.contentsLost());

}

// . more code to write here

}Einsatz und Grenzen der VolatileImage API

Die VolatileImage API ist momentan noch stark in Entwicklung und wird mit kommenden Java

Versionen noch weiter verbessert werden.

Derzeit ist nur das Zeichnen von Lienen und das

Kopieren und Füllen von rechteckigen Bereichen hardwarebeschleunigt, sowie einige komplexere

Funktionen, die als Kombination dieser Basisfunktionen auftreten. Beim Rendern von Text können

die einzelnen Buchstaben nach dem Rendern im VRAM zwischengespeichert und von dort bei

weiteren Render-Durchläufen wieder kopiert werden, wodurch man sich ein aufwendiges Neu-

Rendern spart.

Komplexere Funktionen jedoch wie z.B. diagonale Linien, Curved Surfaces, Anti-

Aliasing und Komposition sind nicht hardwarebeschleunigt und werden derzeit über reines

Software-Rendering realisiert. Da aber Software-Rendering im Hauptspeicher stattfindet, führt das

Verwenden dieser Funktionen auf einem VolatileImage zu starken Performance-Einbußen.

Deshalb

muß man je nach Anwendung und Einsatzbereich abwägen, ob sich die Verwendung eines

VolatileImages lohnt oder nicht.

Hinweis: Da Linux und Solaris keinen direkten Zugriff auf das VRAM unterstützen, ist der Inhalt

eines VolatileImage unter diesen Betriebssystemen auch nicht “flüchtig” und somit auch nicht

hardwarebeschleunigt.

Lediglich bei der Verwendung eines X-Terminal Clients kann man mit

einem VolatileImage an Performance gewinnen, da der BackBuffer hier serverseitig in einer pixmap

gespeichert wird.

c) Animation und Timing

Über Aktives Rendern und Double Buffering kann man nun Komponenten mit sich schnell und

regelmäßig ändernder Grafik darstellen und hat so schon die Grundlage für Animation geschaffen.

Diese benötigt nämlich ein kontinuierliches, flüssiges und performantes Neuzeichnen von Bildern.

Das menschliche Auge ist darauf spezialisiert, Bilder in schneller Folge zu verarbeiten und auf

Gemeinsamkeiten bzw.

Unterschiede im Bildaufbau hin zu analysieren. Dabei fallen ihm besonders

die unterschiedlichen Merkmale auf, während ähnliche Merkmale als “normal” hingenommen und

damit mehr oder weniger ignoriert werden. Dieses Wissen wird z.B. im militärischen Bereich bei

Preview page 3 of 4 : [1] [2] [3] [4]
The site owner is not responsible for the content of this text provided by third parties

Legal info - Data privacy - Contact - Terms-Authors - Terms-Customers -
Swap+your+documents