Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Ich mußte eben feststellen das ein png-Bild mit den Maßen 448*580px,
gespeichert als BufferedImage, 35ms braucht um auf den Bildschirm gebracht zu werden. :shock:
Selbst wenn das Bild nichts weiter ist als eine schwarze Fläche.
Das selbe Bild (ob nun einfach schwarz oder ein aufwendiges Foto) als jpg gespeichert braucht grade mal 0,5ms :meld:
Weiterhin interessant:
Wie zum Teufel willst du das messen und welches OS hat eine 0,5ms Genauigkeit bei der Zeitgebung? :shock:
Windoof liegt da eher bei 6-20 und Linux knapp darunter...
Edit 1:
@ Beim PNG ist ein Alpha dabei. Mal gucken wie es ohne aus sieht. Gestern habe ich die Bilder mit ImageIO.write
als PNG gespeichert. Eins war mikrige 939Byte groß, eben einfach nur Schwarz. Aber das Ergebnis war das Selbe. Aber mal gucken wie es ohne Alpha in dem KSKB hier aussieht...
Was lernen wir daraus?
Es ist absolut egal welches Bild zum einlesen verwendet wird, einzig die Image-Capabilities spielen eine Rolle was ja auch intuitiv einleuchtend sein sollte.
Nun, welch eine Überraschung. Das wenn man ein png quasi in ein JPG konvertiert, man auch gleiche Werte rausbekommt ist wohl nicht sehr verwunderlich.
Dennoch ist der Aspekt mit dem konvertieren ganz interessant. Mal sehen was los ist wenn ich ein BufferedImage mit PNG, was scheinbar vom Typ Custom ist zu einem vom Typ ARGB mache. Denn es gibt wohl nur einen Grund PNG überhaupt zu benutzen, und zwar die Transparenz.
Fraglich finde ich allerdings was du mit "völlig illusorisch" meinst.
Du kannst eben schlecht ein viel aufwendigeres ColorModel mit einem wesentlich weniger komplexen Vergleichen und dich wundern wenn das eine langsamer als das andere ist.
Es ist deine Aufgabe als Programmierer deine Bilder (sofern du auf Performance wert legst) auf ein ColorModel zu beschränken das du wirklich brauchst, denn ImageIO wird dir immer das mit zurückgeben das alle Möglichkeiten des Dateiformats unterstützt.
Fraglich finde ich allerdings was du mit "völlig illusorisch" meinst.
Vor allem 2 Dinge:
Du hast keine 700 FPS. Welcher Bildschirm sollte das denn schaffen?
Wenn ich von deinem Dateiformat auf dein OS schließe verwendest du Windows.
Die Windows API für Systemzeit ist allerdings bekanntermaßen verbuggt und ist nicht in der Lage Zeiten genauer als ca. 10ms aufzulösen.
Deine Messwerte suggerieren allerdings eine deutlich höhere Genauigkeit. Wer sich darauf verlässt ist verlassen...
Alleine schon das Vorhandensein mehrere Threads lässt diese ganzen Messungen wesentlich komplizierter werden als es auf den ersten Blick scheint. Letztlich fehlen dir schlicht die Möglichkeiten zu erkennen was AWT, das OS und zuletzt die Hardware tatsächlich aus deinen Anweisungen macht.
Es steht nicht zur Debate das ein Custom-Type langsamer als 3-byte-bgr ist, aus diesen Zahlen jedoch echte Geschwindigkeitsfaktoren ablesen zu wollen ist nicht drin.
Achso, das meinst du mit illusorisch. Das mein Schirm grade mal 60 Frames bringt ist schon klar.
Es ging mir ja auch nur darum aufzuzeigen das dort ein imenser Unterschied ist.
Egal wie ungenau die Zahlen sein mögen, die Differenz sagt auf jeden Fall was aus. Bei dem gleichen Weg der Messung und über eine Quersumme kann ich auf jedenfall sagen das das eine XFach solange braucht wie das andere.
Mein Fazit zu der Geschichte ist somit:
Ein PNG ist in Natura nicht zu gebrauchen. Wenn ich die schöne Transparenz eines solchen Bildes brauche, wandle ich das Image in Eins vom Typ ARGB um.
Das ist zwar immernoch ca. 4 mal langsammer wie Eins vom Typ 3B-BGR , dafür aber Transparent.
Wenn ich keine transparenz benötige nehme ich also nurnoch jpg, denn da brauch ich keinen Konvertierungskrams zu veranstallten.
Vielen Dank für die interessante Diskussion Mr. Wildcard.
hier werden doch keine einzelnen Zeichenvorgänge gemessen,
sondern nur alle 1 Sekunde eine Statistik erstellt,
was stören da 10 ms Abweichung?
die Auswertung scheint mir sehr genau, so wie gewünscht,
was diese abstrakten Zahlen wie 700 FPS nun bedeuten, kann man nicht herauslesen, aber zumindest scheinen sie doch konstant und nicht zufällig und bei anderen Bildern auch weit höher oder niedriger liegen zu können,
insofern eine sinnvolle Arbeitsmessung (welcher Arbeit auch immer) abhängig vom Bildtyp
hier werden doch keine einzelnen Zeichenvorgänge gemessen,
sondern nur alle 1 Sekunde eine Statistik erstellt,
was stören da 10 ms Abweichung?
die Auswertung scheint mir sehr genau, so wie gewünscht,
Ich denke wir sind uns einig darüber das es hauptsächlich darum geht wie lange es dauert ein bestimmtes Image zu zeichnen.
Sehen wir uns dazu die API-Doc von Graphics#drawImage an:
* This method returns immediately in all cases, even if the
* complete image has not yet been loaded, and it has not been dithered
* and converted for the current output device.
Was wird hier also gemessen?
Aus eben diesen Gründen behaupte ich das man hier gerade keine Faktoren ablesen kann.
Das messen von echter Performance im Zeichen-Bereich ist nicht trivial.
Um das nochmal für alle die über diesen Thread stolpern klar zu stellen:
Unbehandelte pngs sind tatsächlich sogar deutlich langsamer als andere Images (vor allem bei VolatileImages).
Der Grund dafür ist das nur bitmasken Transparenz (wie bei gif) Hardware-Beschleunigt laufen kann und ein png daher nicht von VolatileImage profitiert.
Einzig und alleine der resultierende Faktor ist ein strittiger Punkt...