[Java] Scrollbares Riesen-Widget

[Rolf (Gast)]

Ich möchte eine Binärdatei, welche durchaus auch mal ein GByte groß sein 
kann, als "Spannungs/Bitamplituden"-Graphen darstellen.

Das Problem der Datenquelle ist gelöst (NIO, Speicherabbild mit 
wanderndem Fenster).

Bestehen bleibt das Problem der Darstellung. Bis jetzt habe ich eine 
eine von JFrame abgeleitete Darstellungsklasse, welche die 
"Scrollable"-Schnittstelle implementiert und innerhalb eines 
JScrollViews dargestellt wird.

In dieser Darstellungsklasse habe ich die Methode 
"paintComponent(Graphics g)" überschrieben, um den Graphen zu zeichen.

Frage: ist dies so optimal oder sollte man von einer "primitiveren" 
Klasse ableiten und/oder eine noch mehr auf den unteren Ebenen 
angesiedelte Methode (paint()...) überschreiben?

[Läubi .. (laeubi)]

paintComponent(Graphics g) ist genau richtig, die Ableitung von JFrame 
aber irgenwie "merkwürdig"... leite einfach von JComponent ab.

Optimieren kannst du das ganze noch indem du ggf. die Region welche neu 
gezeichnet werden soll berücksichtigts, aber solange das nicht millarden 
Datenpunte sind macht das kaum einen Unterschied.

[Rolf (Gast)]

JFrame war eine Gewohnheitstat....
Ja, der Update-Bereich wird schon erfaßt (eben weil es ja um Millionen 
von Bits geht ;-))

g.getClipBounds(clippingRectange);
long firstBit=(clippingRectange.x-xspace)/bitWidth;
[....]

Danke!

[Rolf (Gast)]

Ein Problem gibt es noch: die Zeichenoperationen werden ja weiterhin in 
View-Koordinaten abgewickelt.

Da kommt es leider bei großen Dateien zum Zahlenüberlauf des int-Typs. 
Wie kann ich es erreichen, daß ich nicht den View der Scrollpane, 
sondern den Window zeichne?

[Läubi .. (laeubi)]

An welcher Stelle kommt es zum Überlauf? Java biete seit ewig Zeiten das 
Graphics2D Objekt an welches in Double Koordinaten arbeitet, "Standard" 
Graphics Objekte kann man in Swing bedenkenlos auf Graphics2D casten.

> JFrame war eine Gewohnheitstat
Ganz schlechte Gewohnheit, GUI Klassen (insbesondere JFrame) sollte man 
nicht "einfach so" überschreiben, das ist einmal schlechter Stil und 
macht refactorings etc. extrem schwierig, ebenso wie die Kompatibilität 
bei neuen Versionen.

[Rolf (Gast)]

JFrame: mea culpa.

Beim Clipping-Rechteck. Auch wenn ich mit getMinX() die double-Werte 
abfrage, ab einer bestimmten Größe des Views kommen die internen 
Berechnungen anscheinend durcheinander (sind allerdings auch 2^20 Bits=1 
MBit)


Wenn ich den View ganz nach links scrolle bekomme ich statt 0 einen Wert 
von 7230.

super.paintComponent(g);
Graphics2D g2d = (Graphics2D) g;
g2d.getClipBounds(clippingRectange);
long firstBit=(long) 
java.lang.Math.floor((clippingRectange.getMinX()-offset)*scale);

scale ist dabei 1.0/Bitbreite_in_Pixeln, offset die horizontale 
Einrückung.

Ich habe jetzt angefangen, das Window-Viewport-Konzept selbst 
umzusetzen.

Stichwortartig:
 - Übergeordnetes Scroll-Element mit null-Layout, in doLayout werden 
interner
   Viewport und horizontaler Scrollbalken positioniert.
 - Viewport-Implementierung, welche einen bestimmten Ausschnitt des 
Bitstroms
   als Graphen darstellt.