<
>
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 2 of 4 : [1] [2] [3] [4]

nicht ohne ein gelegentliches Flackern des gerenderten Bildes.

Das Flackern tritt nämlich dann auf,

wenn ein Bereich des Bildschirms verändert wird, während der Monitor gerade versucht diesen

Bereich auf die Bildröhre zu projezieren. Diesen Effekt kann man jedoch umgehen, indem man das

zu zeichnende Bild zuerst in einem nicht-sichtbaren Speicherbereich erstellt und dann diesen

Bereich anschließend in den sichtbaren Bereich kopiert.

Das Zeichnen selbst nimmt nämlich

deutlich mehr Zeit in Anspruch als das Kopieren das Speicherbereiches!Diese Methode des Renderns nennt man Double Buffering. In Java verwenden wir für das Double

Buffering ein eigens erstelltes BufferedImage, daß die Größe der zu rendernden Oberfläche hat und

im Folgenden als BackBuffer bezeichnet wird.

Der BackBuffer wird über die Methode createImage

(int width, int height) der Komponente erstellt und verhält sich ansonsten wie ein normales Image-

Objekt. Das Kopieren des BackBuffers in einen sichtbaren Bildschirmbereich erfolgt daher über die

drawImage( .) Methode des zugehörigen Graphics-Objektes.

Rendert man nun die Komponente über Double Buffering, dann erfolgt das Rendern in 3 Schritten:

1. Erzeuge einen BackBuffer, falls dieser noch nicht vorhanden ist

2. Verwende das Graphics-Objekt des BackBuffers für alle Renderoperationen

3. Zeichne den BackBuffer auf den Bildschirm über das Graphics-Objekt der Komponente

Der entsprechende Quellcode dazu könnte in ungefähr so aussehen:

import java.awt.*;

import javax.swing.JComponent;

public class MyComponent extends JComponent

{

private Image backBuffer;

private Image myImage;

// more code to write here .

private void createBackBuffer()

{

backBuffer = createImage(getWidth(),getHeight());

}

public void paintComponent(Graphics g)

{

updateScreen();

}

public void renderScreen()

{

// if backBuffer doesn't exist, create one

if (backBuffer == null) createBackBuffer();

// get Graphics object from backBuffer

Graphics g = backBuffer.getGraphics();

// render screen on backBuffer

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

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

// .

}

public void updateScreen()

{

Graphics g = getGraphics();

if (g != null) // component already visible?

{

// is there a backBuffer to draw?

if (backBuffer != null) g.drawImage(backBuffer, 0, 0, null);

else

{

// if not, create one and render on it

createBackBuffer();

renderScreen();

}

}

}

}public class Renderer extends Thread

{

private MyComponent myComponent = new MyComponent();

// more code to write here .

public void run()

{

while(true)

{

myComponent.renderScreen(); // render component

myComponent.updateScreen(); // draw backBuffer to screen



// rest a bit and give time to other Threads

try

{

Thread.sleep(20L);

}

catch (InterruptedException ex) {}

}

}

}

Führt man diesen Code jetzt aus, dann stellt man fest, daß das Flackern nun nicht mehr auftritt.

Interessant ist an dieser Stelle vielleicht noch, daß Java Swing Komponenten schon standardmäßig

einen internes Double Buffering verwenden, um so ein Flackern zu vermeiden.

Dieses sollte man,

wenn man Komponenten nach dem oben beschriebenen Verfahren selbst rendert, über die Funktion

setDoubleBuffered(false) deaktiveren, um so einen Performanceverlust durch ein zusätzliches

(unnötiges) Puffern durch die Swing Komponente zu vermeiden!

b) Bilder und Sprites

Programmiert man in Java, dann macht man sich eigentlich zuerst einmal keine Gedanken darüber

wo und wie ein Objekt gespeichert wird, denn diese Arbeit nimmt uns ja glücklicherweise die JVM

ab! Und da Image-Objekte ebenfalls Objekte sind, trifft das auch für sie zu.

Aber trotzdem ist

Image-Objekt nicht gleich Image-Objekt und Java hat auch nicht zufälligerweise verschiedene

Bildtypen.

BufferedImage

Der einfachste und damit auch komfortabelste Bildtyp ist BufferedImage.

Ein BufferedImage wird

nämlich komplett von Java verwaltet und ist somit perfekt für den Einstieg in die Programmierung

mit Bildern geeignet.

Was macht aber Java im Hintergrund? Und wie sieht so eine “Verwaltung” eigentlich intern aus?

Nun genaugenommen werden Image-Objekte in der Regel zuerst einmal im Hauptspeicher angelegt

und dann dort durch verschiedene Grafik-Funktionen (wie z.B.

Draw, Transform, Filter, etc.)

bearbeitet. Zum Anzeigen des Bildes wird anschließend der Speicherbereich, der die eigentliche

Bild-Information (also die einzelnen Bildpunkte / Pixel) enthält, aus dem Hauptspeicher in den

Videospeicherbereich (VRAM) kopiert und von dort aus dann über die Grafikkarte auf den

Bildschirm projeziert.

Das Anlegen der Kopie im Hauptspeicher, sowie das Kopieren der Pixel

(Blitting) aus dem Hauptspeicher in das VRAM führt Java bei einem BufferedImage automatisch

durch. Um jedoch den Kopiervorgang zwischen Hauptspeicher und VRAM zu beschleunigen, legt

Java bei einem BufferedImage, eine zusätzliche Kopie des Bildes in einem hardwarebeschleunigtenBereich an und synchronisiert diese dann bei Bedarf automatisch mit der Kopie aus dem

Hauptspeicher.

Dies bringt vor allem dann einen Geschwindigkeitsvorteil, wenn es sich bei dem

BufferedImage um ein Bild mit relativ statischem Inhalt handelt.

(Quelle: VolatileImage.pdf)

Sprites

Sprites sind Bilder mit statischem Inhalt, die Charaktere und Objekte eines Spiels darstellen.

Da ihr

Inhalt sich nach dem Laden nicht mehr verändert, sollte für sie ein BufferedImage verwendet

werden. Das BufferedImage erstellt nämlich beim ersten Rendern automatisch eine Kopie im

VRAM und verwendet diese anschließend für weitere Render-Durchläufe.

Da der Inhalt der Bilder

statisch ist, ist eine permanente Synchronisation zwischen Hauptspeicher und VRAM nicht

notwendig, wodurch man hier eine performante und automatisch-verwaltete Version des Bildes

bekommt.

(Quelle: VolatileImage.pdf)VolatileImage

Wird der Inhalt eines Bildes jedoch häufig verändert, dann muß eine evtl. vorhandene Kopie im

hardwarebeschleunigten Speicherbereich ebenfalls häufig aktualisiert werden.

Wie man sich sicher

vorstellen kann, geht in dieser Situation sehr viel Zeit für das Kopieren zwischen Hauptsspeicher

und hardwarebeschleunigtem Speicher verloren und Java kann hier intern auch nicht viel

Preview page 2 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