Mal wieder unnötige Ressourcenverschwendung bei Mozilla...

[Lala Satalin Deviluke]

...10-20% kleinere JPEGs bringen uns nicht viel. Wichtiger wäre es doch, den Decoder noch schneller zu machen, sodass JPEG-Lastige Seiten schneller gerendert werden können. Das Übertragen der Daten ist heute nicht mehr so das Problem.

Grüße vom Planeten Deviluke!

[MaX]

Hast du Zahlen für deine Behauptung? Wie lange dauert es ein Bild herunter zu laden, und wie lange es zu öffnen?

[Spaghetticode]

Lala Satalin Deviluke schrieb:
--------------------------------------------------------------------------------
> Das Übertragen der Daten ist heute nicht mehr so das Problem.

Bei Drosselkom & Co. bin ich da mir nicht ganz so sicher. Ich denke, es ist schon ein Unterschied, ob bei einer gedrosselten Internetverbindung das Herunterladen des Bildes 40 statt 50 Sekunden dauert. Außerdem kommt bei weniger Datenmenge die Drossel später.



1 mal bearbeitet, zuletzt am 06.03.14 09:07 durch Spaghetticode.

[Lala Satalin Deviluke]

Denk mal drüber nach, wie zäh es abläuft, wenn du eine Google-Bildsuche startest. Die Daten sind bei mir schon lange da, jedoch rendert sich Firefox noch nen Wolf für ne knappe Sekunde. Und das auf nem i7 Quad mit 8 GByte DDR3-RAM und 1GByte/s SSD.

Leitung: 100 MBit/s down, 5 MBit/s up.

Grüße vom Planeten Deviluke!



1 mal bearbeitet, zuletzt am 06.03.14 09:09 durch Lala Satalin Deviluke.

[EWCH]

das stimmt nicht. Auf meiner 3GHz CPU dekomprimiere ich ein JPEG mit 40MByte/Sek.
Da kommt kein DSL mit (die 40MB ergeben dann ca. das zehnfache an Rohdaten).

[Lala Satalin Deviluke]

Sag das mal den Browsern, die Probleme haben mehrere JPEGs auf einer Seite gleichzeitig zu dekodieren. Besonders der Firefox hat hier massive Probleme.

Grüße vom Planeten Deviluke!

[*ubuntuuser]

Lala Satalin Deviluke schrieb:
--------------------------------------------------------------------------------
> Denk mal drüber nach, wie zäh es abläuft, wenn du eine Google-Bildsuche
> startest. Die Daten sind bei mir schon lange da, jedoch rendert sich
> Firefox noch nen Wolf für ne knappe Sekunde.

Kann ich hier nicht bestätigen.

[vlad_tepesch]

vor allem: was bringt es?
es gibt tausende Quellen, die JPEGs erzeugen, die dazu wahrscheinlich die unterschiedlichsten Libs verwenden. jetzt kommt die 1000+1. Lib dazu

[Lala Satalin Deviluke]

Am genialsten finde ich den JPEG-Encoder von Paint Tool SAI. Damit kann man die Quantisierung CrCb-Kanäle unabhänig vom Y-Kanal steuern. DAS bringt auch noch kleinere Dateien und ist denkbar simpel.

Grüße vom Planeten Deviluke!

[debattierer]

Wenn sich das weltweit verbreitet und zum Standard wird, dann ist es doch zu begrüßen.
Die Infrastruktur wird zwar ständig ausgebaut, aber einsparungen sind immer gut. Ich würde schätzen, dass Bilder für etwa 20% des Traffics verantwortlich sind. Der Rest sind Videos. Da bringt jedes Prozentchen was =)

[Sammie]

vlad_tepesch schrieb:
--------------------------------------------------------------------------------
> vor allem: was bringt es?
> es gibt tausende Quellen, die JPEGs erzeugen, die dazu wahrscheinlich die
> unterschiedlichsten Libs verwenden. jetzt kommt die 1000+1. Lib dazu

Vorallem dauert die Erstellung.. denn JPGCrush macht ja nichts weiter als verschiedene Kompressionsverfahren durchzutesten und danach das mit der kleinsten Dateigröße herauszupicken. So dauert die Speicherung eines Bildes je nach eingestellter Menge der Testdurchläufe auch problemlos mal das 50fache der Zeit, bis das optimalste (kleinste) Bild gefunden wurde. Mach das mal für ne größere Image-Gallerie im Web... soviel Zeit will doch kein Mensch investieren.

Da ist es den meisten wohl völlig wurscht, ob das Bild nun 10% größer ist. Bei einem Einzelbildaufruf merkt man den Unterschied eh nicht und bei einer Thumb-Gallerie gehts bestenfalls um wenige Bytes pro Thumbnail.

Und das Rad neu erfunden haben sie damit ja auch nicht, schließlich existieren die Tools ja schon seit Ewigkeiten. Im Enduser-Einsatz kann ich mir sowas nicht vorstellen, dafür ist der Aufwand zu hoch. Denkbar ist es bestenfalls als automatisierter Prozess zB bei Mobileprovidern, die die Bilder in ihren Proxys cachen und wo es wirklich auf kleine Datenraten ankommt. Ob sie daran allerdings Interesse haben ist fraglich - schließlich verdienen die daran, dass die Kundschaft möglichst schnell ihr freies Traffickontigent verbraucht. ^^

[violator]

Und solange kein übliches Programm das Mozilla-JPG unterstützt und standardmäßig nutzt, wird man davon im Web eh nicht viel mitbekommen.

[MaX]

Die erzeugten JPEGs werden standardkonform sein und sich mit jedem Programm das JPEGs öffnen kann auch öffnen lassen.

[MaX]

So Webseiten wie Wikipedia freuen sich über jedes Byte das sie sparen, denn dass summiert sich.

[YoungManKlaus]

nicht aus betreiber-sicht. da encode ich meine bilder einmal (ergo ist es mir so ziemlich egal wie lang das dauert), und freue mich über geringeren bandbreitenverbrauch (kostet ja alles was).

[das_ist_unglaublich]

YoungManKlaus schrieb:
--------------------------------------------------------------------------------
> nicht aus betreiber-sicht. da encode ich meine bilder einmal (ergo ist es
> mir so ziemlich egal wie lang das dauert), und freue mich über geringeren
> bandbreitenverbrauch (kostet ja alles was)

Versteht er nicht, er ist in einem Tunnelblick wo er nur seinen Browser und den auch nur auf Windows sieht statt mal hochzurechnen was 20% bei sagen wir mal 100 GB Traffic auf einem Server ausmacht - Bräuchte man auch gar nicht gross rechnen, über den Daumen 20% mehr Zugriffe ohne schnellere Leitungen einzukaufen oder eben für alle deutlich langsamer auszuliefern was ihn dann mehr betreffen würde weil der Browser bis dahin noch gar nicht mit Rendern der Seite angefangen hat

[Lala Satalin Deviluke]

Wenn man ne Seite hat, wo nicht viele Bilder hochgeladen werden - ok.

Aber für Facebook ist das wiederum ein größeres Problem. Da posten Leute Bilder direkt von der 20 Megapixel-Kamera vom Smartphone (ich hoffe die Apps skalieren runter, weiß nicht ob die Apps das tun!) im Sekundentakt. Runterskalieren + Komprimieren. Das braucht bei der Menge an Anfragen Zeit.

Grüße vom Planeten Deviluke!

[das_ist_unglaublich]

Lala Satalin Deviluke schrieb:
--------------------------------------------------------------------------------
> Wenn man ne Seite hat, wo nicht viele Bilder hochgeladen werden - ok.
>
> Aber für Facebook ist das wiederum ein größeres Problem. Da posten Leute
> Bilder direkt von der 20 Megapixel-Kamera vom Smartphone (ich hoffe die
> Apps skalieren runter, weiß nicht ob die Apps das tun!) im Sekundentakt.
> Runterskalieren + Komprimieren. Das braucht bei der Menge an Anfragen Zeit

Facebook hat andere Sorgen als die Rechenleistung fürs codieren
http://allfacebook.de/zahlen_fakten/big-data-diese-datenmengen-verarbeitet-facebook-taglich

Jeden Tag werden über 500 Millionen Terabyte Daten verarbeitet
Na dann rechne mal 20% weniger Storage und geh raus in die weite Welt damit du siehst was Enterprise-Storage redundant kostet inkl. Backups etc - Die CPU für einmaliges codieren ist da wohl das kleinste Problem

UND GERADE bei Facebook macht es einen gewaltigen Unterschied ob du 20% Traffic einsparen kannst - Ein grosser Teil der ausgelieferten Daten sind nun mal Bilder

[Fanti4ever]

das_ist_unglaublich schrieb:
--------------------------------------------------------------------------------

> Facebook hat andere Sorgen als die Rechenleistung fürs codieren
> http://allfacebook.de/zahlen_fakten/big-data-diese-datenmengen-verarbeitet-facebook-taglich
>

Meinst Du jetzt hat ers verstanden? ;-)

[das_ist_unglaublich]

Fanti4ever schrieb:
--------------------------------------------------------------------------------
> Meinst Du jetzt hat ers verstanden? ;-)

Nicht wirklich, aber man kann mir nicht vorwerfen ich hätte es nicht wenigstens versucht und das sogar ohne ihn mit Bezeichnungen zu versehen die mir auf der Zunge gelegen sind