Jpeg Image anzeigen dauert ewig (D10.1)

[Graf Gustav]

Nachdem die Anzeige eines 1,8 MB Jpeg-Bildes über 7 Sekunden gedauert hat,
habe ich mal ein altes Win7 / D5 zum Vergleich entstaubt.
Vielleicht (hoffentlich) hat jemand von Euch eine Erklärung für die Ergebnisse
(und vor allem, wie ich von den Sekunden runterkomme).

Die Programm-Varianten:
D10P: Das Programm in D10.1/Win 10 erzeugt, Anzeige proprtional
D10Z: wie D10P, nicht proportional (Anzeige verzerrt)
D05Z: Das Programm in D5/Win 7 erzeugt, proportional gabs da noch nicht

Die beiden Systeme:
Win10: Win 10 Pro 64bit 1803 auf einem 8-Core-Ryzen mit 16 GB RAM
Win7: Win 7 Pro 16bit auf einem Athlon 4850 mit 4 GB RAM

Das Testbild ist eine 1,8 MB große jpeg-Datei, die Ladezeit ist vernachlässigbar,
(Dauer im Mittel, unabhängig vom System, lokal 3 ms und remote vom NAS 30 ms).

Das sind die gemessenen Anzeige-Zeiten:

EXE ----- Win10 --- Win7

D10P ----- 7,4 ----- 4,0

D10Z ----- 7,4 ----- 4,0

D05Z ---- 0,0 ---- 0,0

Das mit D5 erzeugte Programm zeigt das Bild auf beiden System verzögerungsfrei (aber verzerrt) an.
Das mit D10 erzeugte ist auf dem lahmen Win7 System fast doppelt so schnell wie auf dem Win10 (!),
egal ob proportional oder nicht. Aber auch die 4 Sekunden sind ja nicht vorzeigbar.

Der Code (identisch auf beiden Systemen):

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
begin
  JPegI := TJpegImage.Create;
  JPegI.LoadFromFile(_FN_JPG);
  Image1.Picture.Assign(JPegI);
end;

In D10 funktioniert ja auch :
- Image1.Picture.Bitmap.Assign(JPegI);
- Image1.Picture.LoadFromFile();
Laufzeitmäßig ist das aber alles gleich.

So, wenn jemand bis hierher gelesen hat: Irgendeine Idee?

Besten Dank
Reinhold

[TiGü]

Grafikkarte und deren Treiber sind gewiss verschieden? Sind letztere aktuell?

[Rolf Frei]

Kannst du auch mal das besagte JPEG hier hochladen?

[dummzeuch]

Wie sieht es denn aus, wenn Du das JPG als Bitmap speicherst und direkt lädst? Gibt es auch dann einen Unterschied?

[Graf Gustav]

danke für den Hinweis wegen des Grafik-Treibers.
Ich hab mir den Update von NVIDIA gerade angetan - hat leider keine Veränderung gebracht :(
Das Bild kann ich wegen des Größenlimits nicht im Forum hochladen.

[DieDolly]

Zitat:

Ich hab mir den Update von NVIDIA gerade angetan

Wieso angetan?

Mit diesem Tool auf GitHub sind Nvidia-Updates ein Kinderspiel. Ein netter Nebeneffekt ist, dass Nvidia Experience nicht mitinstalliert wird.

TinyNvidiaUpdateChecker:
https://github.com/ElPumpo/TinyNvidi...ecker/releases

[EWeiss]

Zitat:

Grafikkarte und deren Treiber sind gewiss verschieden? Sind letztere aktuell?

Man sollte immer die Treiber nehmen mit der die Hardware ausgeliefert wurde.

Egal welchen Treiber ich danach von NVIDIA lade und installiere bei keinem werden bei mir Videos angezeigt.
Es ist wirklich ein Krampf mit Win10.
Ich habe das bei denen schon im Forum gepostet die lapidare Antwort verwenden sie den Treiber der ihnen mit ihre Hardware geliefert wurde.

https://forums.geforce.com/default/t...61395/#5961395
https://forums.geforce.com/default/t...67001/#5967001

Soviel zu Treibern!

Zitat:

your notebooks use vendor certified and configured drivers.
compatibility with reference drivers is not guaranteed.

Starte ich eine Anwendung dann benötige ich als Beispiel 1 Min, starte ich sie das zweite mal nur einen Bruchteil davon (ein paar Sekunden).
Wie sieht das denn aus wenn du die Anwendung danach direkt nochmal startest?

gruss

[bra]

Zitat:

Zitat von EWeiss (Beitrag 1429357)

Man sollte immer die Treiber nehmen mit der die Hardware ausgeliefert wurde.

Das ist doch Quatsch, vielleicht im Fehlerfall aber normalerweise sollte man schauen, dass man aktueller Treiber verwendet.

[EWeiss]

Zitat:

Zitat von bra (Beitrag 1429358)

Zitat:

Zitat von EWeiss (Beitrag 1429357)

Man sollte immer die Treiber nehmen mit der die Hardware ausgeliefert wurde.

Das ist doch Quatsch, vielleicht im Fehlerfall aber normalerweise sollte man schauen, dass man aktueller Treiber verwendet.

Lese doch einfach mal die Links..
Wenn ich dir sage das bei mir kein Video läuft kannst du mir das glauben.. Was soll da quatsch sein?
Und ich bin nicht der einzige!

Nochmal..

Zitat:

compatibility with reference drivers is not guaranteed.

gruss

[Luckie]

Zitat:

Zitat von EWeiss (Beitrag 1429357)

Starte ich eine Anwendung dann benötige ich als Beispiel 1 Min, starte ich sie das zweite mal nur einen Bruchteil davon (ein paar Sekunden).
Wie sieht das denn aus wenn du die Anwendung danach direkt nochmal startest?

Weil sie wahrscheinlich noch im Cache ist.

[hoika]

Hallo,
mit 7Zip komprimiert reicht die Größe hier auch nicht?

Haben deine 3 Beispiele den gleichen Quellcode?
Zeig doch mal eine Minimalversion (=Minimalbeispiel).

[HolgerX]

Hmm..

Zitat:

Zitat von Graf Gustav (Beitrag 1429330)

Die beiden Systeme:
Win10: Win 10 Pro 64bit 1803 auf einem 8-Core-Ryzen mit 16 GB RAM
Win7: Win 7 Pro 16bit auf einem Athlon 4850 mit 4 GB RAM

Auch wenn zwischen den Prozessoren schon ein paar Jahre sind..

Könnte es sein, dass der alte Athlon 4850 eine bessere 'single Core' Geschwindigkeit hat, wie der 8-Core-Ryzen.. (Extra nicht von Frequenz geschrieben.. )

Da für das einlesen / decodieren / umrechnen auf Bitmap und Anzeigen im Image ja nur ein Core verwendet wird, kann schon mal eine 'alte' CPU besser sein, wie eine Multi-Core CPRU.. ;)

(Nur so ne Idee.. ;) )

[TiGü]

Zitat:

Zitat von HolgerX (Beitrag 1429367)

Hmm..

Zitat:

Zitat von Graf Gustav (Beitrag 1429330)

Die beiden Systeme:
Win10: Win 10 Pro 64bit 1803 auf einem 8-Core-Ryzen mit 16 GB RAM
Win7: Win 7 Pro 16bit auf einem Athlon 4850 mit 4 GB RAM

Auch wenn zwischen den Prozessoren schon ein paar Jahre sind..

Könnte es sein, dass der alte Athlon 4850 eine bessere 'single Core' Geschwindigkeit hat, wie der 8-Core-Ryzen.. (Extra nicht von Frequenz geschrieben.. )

Da für das einlesen / decodieren / umrechnen auf Bitmap und Anzeigen im Image ja nur ein Core verwendet wird, kann schon mal eine 'alte' CPU besser sein, wie eine Multi-Core CPRU.. ;)

(Nur so ne Idee.. ;) )

In der Größenordnung 0 vs. 7 Sekunden?
Eher nicht!

[hoika]

Klar,
wenn du noch eine SSD und auf der anderen Seite einen lahmem Virenscanner dazupackst.

Ohne Datei und Bsp.-Programm ist das Kaffeesatz-Leserei (und Kaffee um die Zeit? ;) )

[Michael II]

Mit Grafik-Treibern hat das nix zu tun. Mit HD vs SSD auch nicht; das Laden der Daten stellt kein Problem dar und dauert auch von langsamer HD wenige Millisekunden.

Ich habe eine 2.8 MB JPEG, 6600x8050 auf meinem Win10 (Prozessor Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz, 2201 MHz, 4 Kern(e), 8 logische(r) Prozessor(en)) mit D10.3.1 in 3,2 Sekunden geladen. Es läuft also auch hier extrem langsam.

Soweit ich sehe liegt das Problem in der VCL.Imaging.Jpeg, dort bei der while Schleife in der function TJPEGImage.GetBitmap: TBitmap;

Zwei Vorschläge:
Nimm doch die schnelle Variante aus D5 für dein D10 Projekt.

Ich habe rasch einige JPEG Decoder heruntergeladen und getestet - einige sind bei grossen Files noch viel langsamer als die D10 Variante.

Extrem schnell ist Fast JPEG decoder v.1.2
Lade das Ding runter, lade das Beispielprojekt in deinem D10, ersetze das Image durch ein D10 Image, setze die Eigenschaft Image1.Proportional auf true und staune ;-). Es wird wohl auch auf deiner Kiste mit deinem D10 nur noch Millisekunden dauern, bis das Bild angezeigt wird.

Ich hoffe es klappt....

(Was ich nicht gecheckt habe ist, ob seit Fast JPEG decoder v.1.2 das JPEG Format erweitert worden ist und ob allenfalls D10 mehr Varianten lesen kann.)

[Graf Gustav]

Zitat:

Zitat von Luckie (Beitrag 1429363)

Zitat:

Zitat von EWeiss (Beitrag 1429357)

Starte ich eine Anwendung dann benötige ich als Beispiel 1 Min, starte ich sie das zweite mal nur einen Bruchteil davon (ein paar Sekunden).
Wie sieht das denn aus wenn du die Anwendung danach direkt nochmal startest?

Weil sie wahrscheinlich noch im Cache ist.

ja klar. wenn ich 2x hintereinander dasselbe Bild anzeige, geht es ratfatz.

[EWeiss]

Zitat:

Zitat von Graf Gustav (Beitrag 1429379)

Zitat:

Zitat von Luckie (Beitrag 1429363)

Zitat:

Zitat von EWeiss (Beitrag 1429357)

Starte ich eine Anwendung dann benötige ich als Beispiel 1 Min, starte ich sie das zweite mal nur einen Bruchteil davon (ein paar Sekunden).
Wie sieht das denn aus wenn du die Anwendung danach direkt nochmal startest?

Weil sie wahrscheinlich noch im Cache ist.

ja klar. wenn ich 2x hintereinander dasselbe Bild anzeige, geht es ratfatz.

Ich sprechen nicht von 2x Bilder starten sondern von 2x Anwendung starten.

Ja und das ist das Problem mit Win10. ;)
Die Anwendungen werden nicht mehr schnell gestartet also die werden erst in einem Cache abgelegt dann erst starten sie meines Erachtens nach dem zweiten Start normal.
Ist ein Unding.. aber gut

Früher in XP und Win7 wurden die Anwendungen die oft gestartet wurden im Prefetch Ordner abgelegt der Ordner war für Abbilder der Anwendungen zuständig
um sie beim nächsten Windows Start schneller zu laden.

Der Ordner jedoch ist bei mir unter Win10 einfach leer.
Bin raus

gruss

[old7]

Was soll denn Prefetch ggfs. auf einer SSD bringen? Nur bei HDDs sinnvoll.

https://www.thomas-krenn.com/de/wiki...SDs_optimieren

[EWeiss]

Zitat:

Zitat von old7 (Beitrag 1429382)

Was soll denn Prefetch ggfs. auf einer SSD bringen? Nur bei HDDs sinnvoll.

https://www.thomas-krenn.com/de/wiki...SDs_optimieren

Ich bin mir nicht sicher das Prefetch das gleiche wie der Ordner Prefetch ist.
Denn dort wurden Cache Abbilder der Anwendungen gespeichert um sie beim erneuten System Start zu beschleunigen.

gruss

[hstreicher]

nur mal so aus Neugier, wie ist denn der Farbraum des JPEGs ?
evtl dauert die die Farbraumanpassung unter den modernen Delphis

mfg Hannes

[Redeemer]

Zitat:

Zitat von hstreicher (Beitrag 1429422)

nur mal so aus Neugier, wie ist denn der Farbraum des JPEGs ?

JPEG kennt ein einziges Modell, das heißt YCbCr.

[p80286]

Aus Interesse gefragt
ist #15 keine Möglichkeit das Problem zu lösen?
(ich hab it JPEG/Bitmaps etc. ganz wenig am Hut!)

Gruß
K-H

[hstreicher]

Zitat:

Zitat von Redeemer (Beitrag 1429457)

Zitat:

Zitat von hstreicher (Beitrag 1429422)

nur mal so aus Neugier, wie ist denn der Farbraum des JPEGs ?

JPEG kennt ein einziges Modell, das heißt YCbCr.

Gut dann nennen wir es eben Farbprofile oder in Photoshop Express in den Speichern Einstellungen auch nur einfach Farbe
da finde ich JPEGs mit sRGB , eciRGBv2 AdobeRGB und weitere auf meinem PC

[Graf Gustav]

So, vielen Dank an alle Beiträge - hat in der Summe geholfen.
Ich kenne zwar nicht die Ursache, aber ich habe eine Lösung:
dank der Recherche von Michael II ist es der Synopse Fast Jpeg Decoder :}}

Gelernt habe ich folgendes zusätzlich:
- Archive zum Upload dürfen hier ziemlich groß sein
- Auch zu Zeiten von D10 brauchen wir noch Torry's Pages etc.

Der gesamte Source Code steht eigentlich in meinem ersten Post,
aber ich habe etwas nachgearbeitet und eine kleine Anwendung daraus gemacht,
die die wesentlichen Daten für ein jpeg anzeigt.
In der Anlage sind 3 Varianten (D10 - langsam, D10 - schnell dank Synopse, D5 - schnell)
und die Sourcen und auch das ursprüngliche Bild.
Die Vermutungen zur HW werden eigentlich dadurch widerlegt, dass die D5-Variante
auf beiden System schnell ist.

Vielen Dank nochmal Euch allen

[KarstenK]

Hallo,

In deiner Zeitmessung für Delphi 5 = 0ms ist aber noch nicht die Anzeige des Bildes drin, bei den anderen wohl schon.

Bei Delphi 2009 bis Anzeige (application.processmessage vor der Zeitnahme 2) ist der Faktor 4 zwischen orginal (600ms vs 160ms) Delphi und jpegdec.

[Graf Gustav]

Zitat:

Zitat von KarstenK (Beitrag 1429514)

Hallo,

In deiner Zeitmessung für Delphi 5 = 0ms ist aber noch nicht die Anzeige des Bildes drin, bei den anderen wohl schon.

Tja, was soll ich sagen - mir kommen 0ms auch eher wenig vor,
aber schau Dir meinen Sourcecode an, er ist für D5 und D10 identisch....

[Michael II]

Nebenschauplatz: Der gemessene Nuller kommt eventuell zustande weil die Zeit mit GetTickCount gemessen wird.
GetTickCount Remarks
The resolution of the GetTickCount function is limited to the resolution of the system timer, which is typically in the range of 10 milliseconds to 16 milliseconds.

Und zum Thema: Es wäre schön, wenn Frau und Mann sich darauf verlassen könnten, dass Standardfunktionen wie "jpg laden" nicht von D zu D langsamer werden. Sowas sollte bei der Qualitätskontrolle hängen bleiben.

[Graf Gustav]

Zitat:

Zitat von Michael II (Beitrag 1429554)

Nebenschauplatz: Der gemessene Nuller kommt eventuell zustande weil die Zeit mit GetTickCount gemessen wird.
GetTickCount Remarks
The resolution of the GetTickCount function is limited to the resolution of the system timer, which is typically in the range of 10 milliseconds to 16 milliseconds.

Und zum Thema: Es wäre schön, wenn Frau und Mann sich darauf verlassen könnten, dass Standardfunktionen wie "jpg laden" nicht von D zu D langsamer werden. Sowas sollte bei der Qualitätskontrolle hängen bleiben.

ah, das erklärt, warum ich nie einen Wert < 16 gesehen habe, danke.
Aber 15ms für D5 ist doch auch noch gut ;}
Und dem Statement zur QS kann ich mich nur vollinhaltlich (und kopfschüttelnd) anschließen...

[Michael II]

Und es gibt wahrscheinlich noch einen weiteren Grund für die massiven Unterschiede zwischen D5 und D10.

Das Laden und Anzeigen des Bildes läuft bei D5 und D10 unterschiedlich ab. (Ich nehme meine Qualitätsbemerkung zurück.)

Wenn du deinen Code

Delphi-Quellcode:

// Starte die Uhr
  JPegI := TJpegImage.Create;
  JPegI.LoadFromFile( filename );
  Image1.Picture.Assign(JPegI);
// Stoppe die Uhr

- mit D5 kompilierst und laufen lässt, dann passiert dies:
Der Inhalt der Datei filename wird in einen Stream geladen, du stoppst die Zeit und nun erst wird das Bild aufgebaut.

- mit D10 kompilierst und laufen lässt, dann passiert dies:
Der Inhalt der Datei filename wird in einen Stream geladen, das Bild wird aufgebaut, du stoppst die Zeit.

Da das Laden in den Stream nur sehr wenig Zeit benötigt, misst du im D5 Fall sehr kleine Zeiten.

Ich weiss, man sollte Application.ProcessMessages; nicht nutzen und ich tu's auch nicht in Programmen, aber hier dürfen wir vielleicht mal eine Ausnahme machen ;-).

Ergänze den Code wie folgt

Delphi-Quellcode:

// Starte die Uhr
  JPegI := TJpegImage.Create;
  JPegI.LoadFromFile( filename );
  Image1.Picture.Assign(JPegI);
  Application.ProcessMessages;
// Stoppe die Uhr

und miss die Zeit mit D5 und D10. Bei D5 wirst du nun weit mehr messen als vorher, bei D10 bleibt der Wert ungefähr gleich. Grund: Auch im mit D5 kompilierten Programm misst du nun das Laden in den Stream und den Aufbau des Bildes.

[Natürlich könntest du noch genauer messen...]

Wenn ich deine Beispielprogramme starte ist gefühlt Synopses Lösung am schnellsten, dann D5 dann D10.

Und falls dein mit D5 kompilierter Code doch schneller laden sollte als Synopses Code, dann könntest du eventuell mit D5 eine DLL erstellen (da der Quellcode der jpeg unit wahrscheinlich fehlt) und in D10 nutzen (?).

[Rollo62]

Vielleicht hift der QueryPerformanceCounter weiter ?

[Graf Gustav]

Zitat:

Zitat von Michael II (Beitrag 1429557)

Ich weiss, man sollte Application.ProcessMessages; nicht nutzen und ich tu's auch nicht in Programmen, aber hier dürfen wir vielleicht mal eine Ausnahme machen ;-).

wieso nicht und wo wenn nicht in Programmen? ;}
Ich nutze das (auch in diesem Testprogramm) meistens, um Anzeigen zeitnah gezeichnet zu bekommen.

Aber zum eigentlichen Thema:
Ich hab das jetzt mal umgestellt wie Du empfohlen hast, und das macht die Werte auch plausibler:
D10: 7.400 ms
Synopse: 150 ms
D5: 300 ms
jeweils gemessen auf dem Win10/D10-System.

Der Unterschied zwischen D5 und Synopse wäre mir egal, es geht ja darum, was der Bediener wahrnimmt.
Und das ist beides schnell genug.
Aber bei einem Faktor 50 zu D10 genuine würde ich die Zweifel an der QS nicht zurücknehmen.

Aber für mich Happy End: Synopse.