WebRender - Zukunft des Renderings oder Mozillas Alleingang? [Archiv]

Lurtz

2017-11-27, 22:06:36

Mozilla möchte die Renderengine von Firefox zukünftig mehr einer Game Engine annähern, im Grunde schickt die CPU Drawcalls an die GPU, die daraufhin das Bild berechnet. Dargestellt wird der Vorgang hier: https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/

Zum einen möchte man die Tatsache, dass mittlerweile beinahe jedes Gerät eine Menge ungenutzter Rechenleitung in Form von GPUs verbaut hat, nutzen, zum anderen konstante 60 fps und für Anwendungen wie VR auch höhere fps-Raten und Auflösungen unterstützen.

Sehen wir da die Zukunft des Renderings auch für Anwendungen oder ist das eher als Alleingang Mozillas zu sehen? Ist der Aufwand für die meisten Anwendungen schlichtweg zu groß das umzusetzen? Oder machen steigende Auflösungen und Bildwiederholraten den Schritt unumgänglich?

gravitationsfeld

2017-11-27, 22:22:30

Das sind doch reine Interna des Browsers, da aendert sich fuer die Webseiten absolut nichts.

RLZ

2017-11-27, 22:35:22

3D im Web wird seit 10 Jahren von manchenLeuten gehypt und es interessiert immer noch keinen. WebVR ist ziemlich das absurdeste, was man machen kann...

gravitationsfeld

2017-11-27, 22:43:01

Hat nichts mit "3D im Web" zu tun. Sie wollen das Compositing/Rendering von der CPU auf die GPU legen. Gute Idee, macht Windows schon so seit Vista.

Machen auch schon etliche UI-Toolkits so.

iuno

2017-11-27, 23:33:02

Wieso soll der Aufwand zu gross sein? Danach sieht es fuer mich aus, ausserdem gibt es ja auch keine deadline oder sowas.
Davon mal abgesehen, dass es ein logischer Schritt ist, bin ich mal gespannt, wie es sich letztlich in Sachen Effizienz/Akkulaufzeit auswirkt.
Aber mal schauen, ob man dadurch auch wieder (noch) einfacher trackbar wird. Selbst wenn man Canvas und WebGL Kram usw. alles rausschmeisst sind halt die GPU und insbesondere die Treiber dann besonders mit im Spiel.

Finde uebrigens den Beitrag von Mozilla auch recht nett gemacht

WebGL oder jetzt auch WebVR ist keinesfalls absurd. Es gibt genug Leute, die das unbedingt haben wollen, z.B. in Architektur/Bau. Wenn man da nicht gerade arbeitet, bekommt man halt nicht allzuoft im Leben was davon mit, aber bekanntlich ist da Kohle da.
Hat aber mit dem Thema auch nicht wirklich zu tun.

RLZ

2017-11-28, 00:26:25

Es gibt genug Leute, die das unbedingt haben wollen, z.B. in Architektur/Bau. Wenn man da nicht gerade arbeitet, bekommt man halt nicht allzuoft im Leben was davon mit, aber bekanntlich ist da Kohle da.
Hat aber mit dem Thema auch nicht wirklich zu tun.
Ich hatte ein paar Projekte in dem Bereich und wenn ich eins gelernt habe, dann dass die Leute dort nicht wissen was sie wollen.
Und WebVR ist absurd. Es integriert sich nicht vernünftig in einen User Workflow und man vernichtet einen nicht kleinen Teil der eh schon viel zu knappen Rechenleistung.

Ganon

2017-11-28, 08:21:43

Sie wollen das Compositing/Rendering von der CPU auf die GPU legen. Gute Idee, macht Windows schon so seit Vista.

Prinzipiell ja, aber wir haben jetzt schon teilweise das Problem, dass eine im Hintergrund laufende Webseite einen in daneben/darüber laufende Spiele reingrätscht. Und wie man bisher gesehen hat, gehen Webseiten mit ihren Ressourcen absolut gar nicht gut um.

Damals hat man alles auf die GPU umgestellt, um die CPU zu entlasten, aber langsam habe ich das Gefühl, dass wir anfangen die GPU zu überlasten. Nicht unbedingt in ihrer netto Rechenleistung sondern mehr mit Overhead.

Muss sich natürlich erst noch zeigen und soll jetzt auch nicht heißen, dass ich die Entwicklung schlecht finde. Aber wenn man wieder Anfangen muss Hintergrund/Nebenanwendungen zu deaktivieren, weil sonst das Spiel ruckelt... nunja.

Lurtz

2017-11-28, 10:58:24

Das sind doch reine Interna des Browsers, da aendert sich fuer die Webseiten absolut nichts.
So simpel ist es nicht, das betrifft auch "Webseiten": https://dassur.ma/things/120fps/

Hat nichts mit "3D im Web" zu tun. Sie wollen das Compositing/Rendering von der CPU auf die GPU legen. Gute Idee, macht Windows schon so seit Vista.

Machen auch schon etliche UI-Toolkits so.
Windows schickt auf dem Desktop Drawcalls an die GPU, wie WebRender das tut?

Wieso soll der Aufwand zu gross sein? Danach sieht es fuer mich aus, ausserdem gibt es ja auch keine deadline oder sowas.
Man programmiert ja hardwarenäher und muss sich auf einmal Gedanken über Shading, Drawcalls etc. machen… Zudem könnten sich Treiberprobleme noch gravierender auswirken.

Und WebVR ist absurd. Es integriert sich nicht vernünftig in einen User Workflow und man vernichtet einen nicht kleinen Teil der eh schon viel zu knappen Rechenleistung.
Web-Anwendungen sind absurd. Sie integrieren sich nicht vernünftig in einen User Workflow und man vernichtet einen nicht kleinen Teil der eh schon viel zu knappen Rechenleistung.

;)

Wie viel Zeit verbringt der Anwender heute im Browser und wie viel Zeit in anderen Programmen?

Prinzipiell ja, aber wir haben jetzt schon teilweise das Problem, dass eine im Hintergrund laufende Webseite einen in daneben/darüber laufende Spiele reingrätscht. Und wie man bisher gesehen hat, gehen Webseiten mit ihren Ressourcen absolut gar nicht gut um.
Kann man mit WebRender schon nachvollziehen. Firefox mit Animation offen? Frametimes im Spiel grottig.
Spiel belastet die GPU auch minimiert? Firefox ruckelt.

Damals hat man alles auf die GPU umgestellt, um die CPU zu entlasten, aber langsam habe ich das Gefühl, dass wir anfangen die GPU zu überlasten. Nicht unbedingt in ihrer netto Rechenleistung sondern mehr mit Overhead.
Die Pipeline wird sicher deutlich komplexer und anfälliger für Störungen.

Muss sich natürlich erst noch zeigen und soll jetzt auch nicht heißen, dass ich die Entwicklung schlecht finde. Aber wenn man wieder Anfangen muss Hintergrund/Nebenanwendungen zu deaktivieren, weil sonst das Spiel ruckelt... nunja.
Sind die Spieler so relevant?

Die Frage ist wie löst man es sonst?
https://twitter.com/metajack/status/917784559143522306

lumines

2017-11-28, 11:04:43

Ganon

2017-11-28, 11:15:54

Die Frage ist wie löst man es sonst?
https://twitter.com/metajack/status/917784559143522306

Wie gesagt, ich bin nicht gegen die Auslagerung auf die GPU, schon alleine weil es genügend Anwender gibt, die neben dem Browser sonst nichts mehr am PC/Notebook benutzen. Und wenn es nicht der Browser ist, dann irgend eine Anwendung die den Browser mitliefert.

Man muss sich halt nur Gedanken machen wo das hinführt und ich eben keine 120fps im Browser und parallel dazu 120fps im Spiel haben kann. Der Browser wird dann eben auf das Level eines Spiels gehoben und man startet ja selten 2 Spiele auf einmal genau aus diesem Grund. Und 2 120fps Webseiten parallel dazu wird dann auch schnell "lustig".

Und hier sollte man sich mal allgemein etwas zurücklehnen und mal nachdenken. Den Inhalt machen nicht die Browser-Hersteller... aber es gibt Webseiten die so dermaßen die Gerätschaften überlasten, dass das nicht mehr feierlich ist. Twitter ist nach ein paar Klicks auf "Neue Tweets" irre langsam, weil die Timeline so lang ist und voller Bilder. Letztens einen Blogpost (https://dolphin-emu.org/blog/2017/11/19/hybridxfb/) gelesen mit vielen Videos/Gifs drin wo der Schreiber vergessen hat einzubauen, dass die Videos/Animationen stoppen, wenn sie nicht mehr im Sichtbereich sind. Mein Gerät glühte förmlich.

Und wenn ich in 2017 in Browser auf ein Menü-Icon klicke auf einer 2Ghz Quadcore CPU und dann 1-2s warten muss bis es aufgeht, dann läuft hier ganz gewaltig was falsch und das ist nicht die Rendering-Engine des Browsers.

Lurtz

2017-11-28, 11:22:56

Und hier sollte man sich mal allgemein etwas zurücklehnen und mal nachdenken. Den Inhalt machen nicht die Browser-Hersteller... aber es gibt Webseiten die so dermaßen die Gerätschaften überlasten, dass das nicht mehr feierlich ist. Twitter ist nach ein paar Klicks auf "Neue Tweets" irre langsam, weil die Timeline so lang ist und voller Bilder. Letztens einen Blogpost (https://dolphin-emu.org/blog/2017/11/19/hybridxfb/) gelesen mit vielen Videos/Gifs drin wo der Schreiber vergessen hat einzubauen, dass die Videos/Animationen stoppen, wenn sie nicht mehr im Sichtbereich sind. Mein Gerät glühte förmlich.
Das tun die Browserhersteller doch schon ständig. Webseiten bekommen ein Timebudget, das sie im Hintergrund nicht überschreiten dürfen. Animationen außerhalb des Viewports werden gestoppt. Bei Videos im Hintergrund läuft nur die Tonspur weiter.

Da ist eine Menge in Arbeit…

Ganon

2017-11-28, 11:28:21

Lurtz

2017-11-28, 11:46:21

Im Hintergrund ja, aber nicht im Vordergrund. Ich rede hier vom Vordergrund, d.h. die aktive Benutzung der Webseite ist verdammt langsam. Und Animationen außerhalb des Viewports werden nicht gestoppt. Zumindest noch nicht. Das machen die Webseiten manuell.

Da sollte man sich halt mal überlegen warum ein bisschen Text und ein paar Videos hier Geräte mit mehreren GFLOPS dermaßen überlastet.

Klar können wir das Problem mit mehr Hardware erschlagen, aber dann haben wir trotzdem noch eine Webseite mit Text und ein paar Videos, die wir zur Benutzung auf einen Prozessor im TFLOPS Bereich packen müssen :ugly:
Stelle ich selten so schlimm fest, dass es wirklich störend ist. Letztendlich liegt das in der Verantwortung der Website.
Bei Webtechniken gilt halt oft dass man es nicht machen sollte, nur weil es geht.

Bei WebRender muss man Endergebnisse abwarten. Laut Mozilla reicht die simpelste moderne GPU um deutlich schneller zu werden als mit einer CPU (ja ich weiß auch die hat schon TFLOPS).

Bei den Animationen beginnt man jetzt:
https://bugzilla.mozilla.org/show_bug.cgi?id=1190721

Text-Rendering ist auch nicht so trivial wie es aussieht:
http://pcwalton.github.io/blog/2017/02/14/pathfinder/

lumines

2017-11-28, 12:15:03

Text-Rendering ist auch nicht so trivial wie es aussieht:
http://pcwalton.github.io/blog/2017/02/14/pathfinder/

Spaßfakt: iOS hat sehr lange auf Subpixel-Rendering bei Schriften verzichtet, weil dadurch der Text beim Wechsel von Landscape zu Portrait und Zoom komplett neu gerendert werden müsste. Das ging wohl in einigen Fällen zu stark auf die Laufzeit.

Je mehr Zeichen im Web mit Vektorgrafiken / Schriften umgesetzt werden, desto schwerer wiegt das natürlich. Gerade durch die ganzen variablen Auflösungen sollte man das echt nicht unterschätzen. Text wird praktisch immer gerendert, von daher wäre es echt gut, wenn man das irgendwie über die GPU optimieren könnte.

aufkrawall

2017-11-28, 12:18:36

Für Vulkan gibts eine Extension, mit der VR-Anwendungen priorisiert (oder exklusiv?) die GPU nutzen können, radv unterstützt das ab Mesa 17.3. So etwas könnte ja helfen, wenn im Hintergrund der Browser läuft.
Unter Windows gibts den Gamemode, der halt leider immer noch ein Häufchen Mist ist.

RLZ

2017-11-28, 12:22:50

Web-Anwendungen sind absurd. Sie integrieren sich nicht vernünftig in einen User Workflow und man vernichtet einen nicht kleinen Teil der eh schon viel zu knappen Rechenleistung.

;)

Ja mei. Du bist eindeutig niemand, der viel VR nutzt.

iuno

2017-11-28, 12:33:08

Ist doch schon heute so, dass z.B. Chrome die Ausführung von JavaScript im Hintergrund einschränkt. Safari hat damit (meine ich) als erstes angefangen. Funktioniert natürlich nicht perfekt, einfach weil man die Kompatibilität irgendwie erhalten muss
Das funktioniert aber auch noch nicht so richtig gut. Z.B. wenn man mehrere Fenster oder eben z.B. eine Vollbildanwendung ueber dem Browser offen hat, dann laeuft der aktive Tab trotzdem immer im Vordergrund. Prinzipiell halte ich es aber fuer richtig. Ich koennte mir auch vorstellen, dass man dafuer Schalter einbaut ob eine Webseite im Hintergrund "laufen" darf oder nicht. Gibt ja eh schon einen Haufen Domainspezifische Berechtigungen bei FF (und Chrome glaube ich auch) wie z.B. cookies, Zugriff auf Mikrofon/Kamera, Benachrichtigungen, Ortung usw.
Mozilla spricht ja auch viel davon, Arbeit einzusparen. Ich glaube schon, dass man sich da Gedanken macht.

Prinzipiell ja, aber wir haben jetzt schon teilweise das Problem, dass eine im Hintergrund laufende Webseite einen in daneben/darüber laufende Spiele reingrätscht. Und wie man bisher gesehen hat, gehen Webseiten mit ihren Ressourcen absolut gar nicht gut um.
Ist richtig. Aber dann muss man sich im Zweifel auch mal beim Webseitenbetreiber beschweren oder halt die aufwendigen Tabs in den Hintergrund stellen oder schliessen.

Ja mei. Du bist eindeutig niemand, der viel VR nutzt.
[Auch wenn es OT ist gehe ich nochmal darauf ein]
Ich auch nicht, kann es aber auch nicht nachvollziehen. Warum ist WebVR absurd, aber eine native VR-Anwendung nicht? Da geht es ja nicht um Weltklassedarbietungen, sondern darum, den Leuten schnell mal online was zeigen zu koennen. Wie eine Webseite halt. Das hat sich natuerlich auch unter der Annahme entwickelt, dass irgendwie doch noch viele Nutzer zu so einer Brille kommen. Klar, wenn man eine Demo auf einem Messestand oder im Verkaufsraum hat oder das im Buero benutzen will oder sonst was, dafuer ist es halt nichts.

aufkrawall

2017-11-28, 14:08:14

Die GPU-Auslastung war ja auch bisher bei dem traditionellem 2D-Rendering nicht zu vernachlässigen, wenn man z.B. komplexe Inhalte mit Scrolling kombinierte. Allgemein ist alles zu begrüßen, was die effiziente Ausnutzung der Ressourcen und die Performance verbessert.
Wenn Betriebssystem und Treiber zu dumm sind, die Ressourcen vernünftig aufzuteilen, muss man das halt erst mal in Kauf nehmen. Lösung trifft auf Bedarf.

Allgemein wärs für die Energieeffizienz aber auch schön, wenn das Taktverhalten von GPUs endlich mal so flexibel wäre wie das von CPUs. Bei großen GPUs grätscht da etwa Video-Decoding blöd bei der Effizienz rein. Zeit für das Little-Big-Prinzip für den Desktop bei GPUs? Damit wäre auch gleich das Problem mit der Ressourcen-Vernichtung durch den Browser generell geklärt.

Lurtz

2017-11-28, 14:19:48

Ja mei. Du bist eindeutig niemand, der viel VR nutzt.
Wow, so viele Argumente.

Mir ist absolut klar dass WebVR momentan nicht annähernd mit einer nativen Lösung mithalten kann. Das heißt aber noch lange nicht, dass WebVR in ein paar Jahren nicht sehr relevant sein könnte.

Sonst würden wir Office heute auch nicht im Browser betreiben und mit Handys könnte man nach wie vor höchstens telefonieren.

RLZ

2017-11-28, 14:26:19

Wow, so viele Argumente.
Genausoviele Argumente wie du auch gebracht hast. :freak:

Die Frage ist eher wie man den Webbrowser in VR integriert und nicht umgekehrt. Man klickt sich nicht durch eine Webseite, geht 2 Minuten in VR, dann wieder auf normalen Monitor zurück und nochmal 2 Minuten VR. Das wäre eine ergonomische Vollkatastrophe.

Normale Webanwendungen integrieren sich voll in den normalen Arbeitsablauf ohne einen Wechsel des eigentlichen Darstellungsmediums zu erfordern. Das ist eine ganz andere Geschichte.

gravitationsfeld

2017-11-28, 16:10:48

So simpel ist es nicht, das betrifft auch "Webseiten": https://dassur.ma/things/120fps/
Was ich damit meinte, ist dass es nichts fuer den Programmierer der Webseiten aendert. Es bleibt HTML/CSS. Du programmierst nicht gegen die GPU, sondern weiterhin stink normales HTML.

Was der Browser damit macht sind reine Interna. Du brauchst es mir nicht erklaeren, ich habe verstanden worum es geht.

Windows schickt auf dem Desktop Drawcalls an die GPU, wie WebRender das tut?
Ja. Seit Ewigkeiten.

Ich weiss auch nicht warum du dich an "Drawcalls" so festbeisst. Das ist nichts magisches, das ist der normale Weg wie GPUs arbeiten.

Prinzipiell ja, aber wir haben jetzt schon teilweise das Problem, dass eine im Hintergrund laufende Webseite einen in daneben/darüber laufende Spiele reingrätscht. Und wie man bisher gesehen hat, gehen Webseiten mit ihren Ressourcen absolut gar nicht gut um.

Damals hat man alles auf die GPU umgestellt, um die CPU zu entlasten, aber langsam habe ich das Gefühl, dass wir anfangen die GPU zu überlasten. Nicht unbedingt in ihrer netto Rechenleistung sondern mehr mit Overhead.

Muss sich natürlich erst noch zeigen und soll jetzt auch nicht heißen, dass ich die Entwicklung schlecht finde. Aber wenn man wieder Anfangen muss Hintergrund/Nebenanwendungen zu deaktivieren, weil sonst das Spiel ruckelt... nunja.
Welcher "Overhead"? Bis du mit 2D-Kram die GPU voll bekommst kannst du 1000 Browser-Fenster offen haben.

Ganon

2017-11-28, 16:18:51

Welcher "Overhead"? Bis du mit 2D-Kram die GPU voll bekommst kannst du 1000 Browser-Fenster offen haben.

Es gibt Fälle wo man z.B. bei der Discord-App (Electron-Kram) die Hardwarebeschleunigung abschalten muss, weil sonst in einem parallel laufenden Spiel die Performance gnadenlos wegbricht.

Ich kenne nicht jede Facette, wie man von außen Spiele mit einer anderen GPU-Beschleunigten Anwendung torpedieren kann, aber ich sehe halt nur den Effekt der bereits auftritt.

Lurtz

2017-11-28, 16:19:32

Normale Webanwendungen integrieren sich voll in den normalen Arbeitsablauf ohne einen Wechsel des eigentlichen Darstellungsmediums zu erfordern. Das ist eine ganz andere Geschichte.
Ich meine ja nur, vor 10-15 Jahren war die Ablehnung gegenüber Webanwendungen ähnlich groß bzw. das Szenario gar nicht vorstellbar.

Was ich damit meinte, ist dass es nichts fuer den Programmierer der Webseiten aendert. Es bleibt HTML/CSS. Du programmierst nicht gegen die GPU, sondern weiterhin stink normales HTML.

Was der Browser damit macht sind reine Interna. Du brauchst es mir nicht erklaeren, ich habe verstanden worum es geht.
Ich weiß nicht ob man die heutigen Frameworks für Webapps wirklich als "stinknormales" HTML bezeichnen kann. Und natürlich hat es Auswirkungen was die Browser tun. Die heutigen WebApps waren undenkbar bevor V8 und Chrome um die Ecke kamen...

Ja. Seit Ewigkeiten.

Ich weiss auch nicht warum du dich an "Drawcalls" so festbeisst. Das ist nichts magisches, das ist der normale Weg wie GPUs arbeiten.
Ist keine böse Absicht, ich bin nur Laie. Der große Unterschied bei WebRrender ist meinem Verständnis nach, dass er das Bild wie eine GameEngine möglichst oft in der Sekunde komplett neu berechnet. Mit dem aktuellen Wunschziel von konstanten 16 ms, also 60 fps.

gravitationsfeld

2017-11-28, 16:21:45

Ich weiß nicht ob man die heutigen Frameworks für Webapps wirklich als "stinknormales" HTML bezeichnen kann. Und natürlich hat es Auswirkungen was die Browser tun. Die heutigen WebApps waren undenkbar bevor V8 und Chrome um die Ecke kamen...
Groaaaaan. Es geht darum, das Webrender NICHTS daran aendert. NICHTS. Es ist eine interne Optimierung von Firefox. Nichts fuer den Benutzer oder Programmierer aendert sich, ausser dass es schneller ist. Wie jede andere Optimierung.

Ist keine böse Absicht, ich bin nur Laie. Der große Unterschied bei WebRrender ist meinem Verständnis nach, dass er das Bild wie eine GameEngine möglichst oft in der Sekunde komplett neu berechnet. Mit dem aktuellen Wunschziel von konstanten 16 ms, also 60 fps.
Browser refreshen nur wenn es sein muss. Daran wird sich auch in Zukunft nichts aendern. Wenn eine Animation laeuft, dann schafft man sie mit Webrender aber wohl locker mit 60Hz. Gut.

Das aendert trotzdem nichts daran wie Webseiten benutzt werden, wie man sie programmiert oder wie der Benutzer mit ihnen interagiert.

Es gibt Fälle wo man z.B. bei der Discord-App (Electron-Kram) die Hardwarebeschleunigung abschalten muss, weil sonst in einem parallel laufenden Spiel die Performance gnadenlos wegbricht.

Ich kenne nicht jede Facette, wie man von außen Spiele mit einer anderen GPU-Beschleunigten Anwendung torpedieren kann, aber ich sehe halt nur den Effekt der bereits auftritt.
https://docs.microsoft.com/en-us/windows-hardware/drivers/display/gpu-preemption

Braucht neue Hardware. Hat nichts mit nicht vorhandener Leistung zu tun. Und Electron gehoert in den Anus zurueckgeschoben wo es her kam.

Ganon

2017-11-28, 16:28:20

https://docs.microsoft.com/en-us/windows-hardware/drivers/display/gpu-preemption

Braucht neue Hardware. Hat nichts mit nicht vorhandener Leistung zu tun. Und Electron gehoert in den Anus zurueckgeschoben wo es her kam.

Das ist also auch bei aktuellen GPUs noch kein "Standard"? Wie gesagt, ich meinte ja auch nicht, dass die Leistung nicht ausreicht, sondern eben genau sowas hier was du verlinkt hast. Und klar gibt es diverse Software-Framework-Fails, aber nur weil es ein Fail ist, heißt das nicht, dass es nicht genutzt wird. Der Erfolg von Electron zeigt's doch.

Lurtz

2017-11-28, 16:30:10

Groaaaaan. Es geht darum, das Webrender NICHTS daran aendert. NICHTS. Es ist eine interne Optimierung von Firefox. Nichts fuer den Benutzer oder Programmierer aendert sich, ausser dass es schneller ist. Wie jede andere Optimierung.
Das ändert alles. Bei V8 war auch die bedeutendste Neuerung, dass es 10-50 Mal schneller als bestehende Javascript-Engines war:
Speed may be Chrome's most significant advance. When you improve things by an order of magnitude, you haven't made something better — you've made something new. "As soon as developers get the taste for this kind of speed, they'll start doing more amazing new Web applications and be more creative in doing them," Bak says. Google hopes to kick-start a new generation of Web-based applications that will truly make Microsoft's worst nightmare a reality: The browser will become the equivalent of an operating system.
https://www.wired.com/2008/09/mf-chrome/

Der Rest ist Geschichte, Entwickler schreiben immer noch stinknormales Javascript und dennoch haben wir heute komplette Programme im Browser.

aufkrawall

2017-11-28, 16:30:44

Eine Animation allein ist ja nicht das Problem, auf vsynctester.com schafft auch FF57 schon locker 75fps@75Hz mit Nouveau unter Linux (womit btw. nicht mal Counter-Strike 1.6 auf Pascal flüssig läuft).
Problematisch ist halt viel auf einmal und durcheinander. Allerdings fällt mir nicht so viel Web-Content ein, wo ich jetzt in meinem Surfverhalten von einer Verbesserung dort irgendwie wichtig profitieren würde.

gravitationsfeld

2017-11-28, 16:35:35

Das ist also auch bei aktuellen GPUs noch kein "Standard"?
Pascal kann es, aber ich hab keine Ahnung ob's im Treiber auch aktiviert ist.

Lurtz

2017-12-02, 03:42:42

Not bad: https://twitter.com/mike_conley/status/936728556008329219

Gast

2017-12-04, 22:22:58

Ein bisschen Sorge macht mir das aber auf mobile Geräten. Momentan wird ohnehin schon das compositing von der GPU gemacht. Wenn sich die Seite nicht ändert und nur gescrollt wird, dann macht die GPU nichts anderes, als bereits (per CPU) gerenderten Viewport zu verschieben. Wenn nur ein Cursor blinkt oder ich hier diese Zeilen Tippe, dann wird heutzutage auch nur der Cursor und der neue Buchstabe neu gerendert. Das ist hart optimiert, damit man wenig neu rendern muss.
All diese Optimierungen sind auf der Grafikkarte aber teuer. Dafür ist die so sauschnell, dass bei jeder kleinsten Änderung der komplette Frame neugezeichnet werden soll. Ob das auch schon die Optimierung beim Scrollen betrifft, kann ich jetzt nicht sagen. Das wäre schon krass, weil dass ja wirklich oft auftritt. Auf jeden Fall wird bei jeder kleinsten Animation alles neu gerendert. Ob das dann noch energiesparender ist, als die heutige Engine ist meiner Meinung nach erstmal Fragwürdig.

Zu dem Schnellen Tab wechsel: Ich frag mich ja, wie viel der Daten dann in den GPU Speicher wandert und ob das evtl. auch alles noch im System RAM vorgehalten werden muss. Gerade bei Laptops und Handys wird das wieder kritisch.

Ganon

2017-12-05, 09:22:02

Ältere Geräte und Geräte mit wenig Arbeitsspeicher sind eh schon abgehängt. Ich sitze zur Zeit ab und zu mal an einem Core 2 Duo 2Ghz Notebook mit 4GB RAM. Die Benutzung "moderner" Webseiten wie Twitter ist eine Qual. Entweder die Seite ist träge ohne Ende oder der Lüfter dreht frei (80-90% CPU Auslastung)... Da die Webseiten durch all ihren Scriptcode eh schon dermaßen träge sind und es mit WebAssembly schon mehr oder weniger eine Lösung geben könnte (keine Ahnung wie sich das Auswirken kann), kann der Browserhersteller hier eh nicht mehr viel tun. Gibt eine Menge Flaschenhälse in die man reinrennen kann. Ob nun Scriptcode, DOM-Aktualisierungen oder der Repaint...

Die Browser skalieren natürlich mit dem verfügbaren Arbeitsspeicher mit. D.h. nur weil z.B. Chrome auf einer Maschine mit 16GB RAM sich 4GB genehmigt, heißt das nicht, dass es auf einer Maschine mit 1GB RAM nicht funktioniert. Ähnlich wird es auch hier sein. Sie werden halt nur langsamer.

Ectoplasma

2017-12-05, 10:13:35

Das einzige was das bringen wird ist, dass dann auch der GPU Lüfter rauscht, wenn Firefox läuft.

aufkrawall

2017-12-05, 11:38:57

Diese PhDs haben halt keine Ahnung.

Ectoplasma

2017-12-05, 17:50:23

Ja. Seit Ewigkeiten.

Ja und nein. Das ist halt gemixt. Das Font-Rendering z.B. findet meist nicht auf der GPU statt, weil das nicht so simpel umzusetzen ist. Es gibt eigentlich so gut wie kaum UI-Bibliotheken, die zu 100% auf die GPU gehen. Alleine Dinge wie Polygone zeichnen, selbstverständlich mit Antialiasing, werden in der Regel nicht über die GPU gemacht. Es bleibt zunächst mal die Frage, was eigentlich genau damit gemeint ist, wenn man Draw Calls an die GPU schickt.

gravitationsfeld

2017-12-05, 17:50:27

Das einzige was das bringen wird ist, dass dann auch der GPU Lüfter rauscht, wenn Firefox läuft.
:facepalm:

Ja und nein. Das ist halt gemixt. Das Font-Rendering z.B. findet meist nicht auf der GPU statt, weil das nicht so simpel umzusetzen ist. Es gibt eigentlich so gut wie kaum UI-Bibliotheken, die zu 100% auf die GPU gehen. Alleine Dinge wie Polygone zeichnen, selbstverständlich mit Antialiasing, werden in der Regel nicht über die GPU gemacht. Es bleibt zunächst mal die Frage, was eigentlich genau damit gemeint ist, wenn man Draw Calls an die GPU schickt.
Das ist mir alles bewusst.

Ein bisschen Sorge macht mir das aber auf mobile Geräten. Momentan wird ohnehin schon das compositing von der GPU gemacht. Wenn sich die Seite nicht ändert und nur gescrollt wird, dann macht die GPU nichts anderes, als bereits (per CPU) gerenderten Viewport zu verschieben. Wenn nur ein Cursor blinkt oder ich hier diese Zeilen Tippe, dann wird heutzutage auch nur der Cursor und der neue Buchstabe neu gerendert. Das ist hart optimiert, damit man wenig neu rendern muss.
All diese Optimierungen sind auf der Grafikkarte aber teuer. Dafür ist die so sauschnell, dass bei jeder kleinsten Änderung der komplette Frame neugezeichnet werden soll. Ob das auch schon die Optimierung beim Scrollen betrifft, kann ich jetzt nicht sagen. Das wäre schon krass, weil dass ja wirklich oft auftritt. Auf jeden Fall wird bei jeder kleinsten Animation alles neu gerendert. Ob das dann noch energiesparender ist, als die heutige Engine ist meiner Meinung nach erstmal Fragwürdig.
Webrender zeichnet nicht alles neu bei jeder Animation.

Ectoplasma

2017-12-06, 00:38:02

@gravitationsfeld, entspann dich doch, das mit dem Lüfter war eher ein Scherz. Davon mal ab, werden wir trotzdem erst am Ende sehen, was das alles bringen wird.

Webrender zeichnet nicht alles neu bei jeder Animation.

Steht aber in der Doku (https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/), oder haben wir uns da verlesen? Übrigens entstand genau daraus auch mein nicht ganz so ernst gemeinter Kommentar von oben.

Lurtz

2017-12-06, 08:57:06

Webrender zeichnet nicht alles neu bei jeder Animation.
Sobald sich etwas verändert/bewegt zeichnet WebRender den gesamten Frame neu. Siehe die Testseiten: https://jrmuizel.github.io/webrender/arstechnica.html

DinosaurusRex

2017-12-06, 09:07:37

Passt super zum Thema:

Best Website 2017 prämiert von den CSS Design Awards: https://my.pottermore.com/hogwarts

Ectoplasma

2017-12-06, 10:40:43

Passt super zum Thema:

Best Website 2017 prämiert von den CSS Design Awards: https://my.pottermore.com/hogwarts

Irgendwie hast du das Talent, immer am Thema vorbei zu Kommentieren. Setzen 6! Oder wolltest du uns was ganz anderes sagen?

@gravitationsfeld, übrigens fängt mein GPU-Lüfter bei dem Beispiel von DinosaurusRex an zu rauschen (ist wohl ein WebGL Context). Die CPU ist gerade mal mit 2% belastet. Wenn Firefox jetzt meint genau so rendern zu wollen wie ein Game, was passiert dann wohl? Aber warten wir es ab.

gravitationsfeld

2017-12-06, 19:14:43

Es ist weitaus effizienter auf der GPU zu rendern als auf der CPU. Dafuer sind sie gemacht.

Was er da verlinkt hat, hat nichts mit WebRender zu tun. Das ist explizites WebGL.

Ectoplasma

2017-12-07, 07:37:39

Es ist weitaus effizienter auf der GPU zu rendern als auf der CPU. Dafuer sind sie gemacht.

Ein wenig mehr Differenzierung bitte! 3D und 2D Rendering sind unterschiedliche Dinge. Ein komplexer 2D Chart in einem Canvas wird auf der GPU garantiert nicht schneller gerendert, wenn man es überhaupt hinbekommt einen geeigenten Shader zu schreiben, der all das kann.

Der wesentliche Unterschied von 3D und 2D ist wohl der (korrigiere mich bitte wenn ich falsch liege), dass im 3D Bereich sämtliche Materialien, insbesondere Texturen, bereits vorliegen. Im 2D Bereich, produziert man quasi solche Dinge. Eine GPU ist wie bereits gesagt, nicht gut geeignet für das Zeichnen von Polygonen mit Antialiasing. Das ist etwas, was im Web sehr oft verwendet wird. Aber wir werden sehen.

Was er da verlinkt hat, hat nichts mit WebRender zu tun. Das ist explizites WebGL.

Sagte ich doch. Hast du dir nochmal durchgelsen, wie Mozilla in Zukunft rendern will?

Gast

2017-12-07, 23:55:05

Was passiert denn in deinem 2D Chart, was die GPU nicht machen kann? Wahrscheinlich fehlt mir da die Vorstellungskraft und was ich so an 08/15 Charts sollte eigentlich gut auf GPUs machbar sein.

Und vielleicht liege ich auch da falsch, aber machen GPUs nicht genau das: Polygone Zeichnen? AA belastet natürlich extra, aber das ist auf der CPU ja auch nicht anders.
Was GPUs meines Wissens nach nicht besonders liegt, sind Kurven höherer Ordnung. Wahrscheinlich häufigstes Beispiel: Schriften Rendern. Aber auch andere (2D) Grafiken mit Bezier Kurven oder Kreisen oder so.

Was gravitationsfeld mit "Webrender zeichnet nicht alles neu bei jeder Animation. " vielleicht meint ist folgendes:
https://github.com/servo/webrender/wiki

- Redraw each frame (when there is something to be updated - not a constant fps like games!).
- Cache results (such as vertex buffers, rasterized glyphs) where possible between frames.

Es werden also schon verschiedene Dinge gecached, aber wird dennoch alles neu gerastert.

Ectoplasma

2017-12-08, 09:24:51

Und vielleicht liege ich auch da falsch, aber machen GPUs nicht genau das: Polygone Zeichnen?

Ja sorry du hast natürlich Recht. Meinte Kurven höherer Ordnung. GPUs zeichnen Dreiecke.

Was passiert denn in deinem 2D Chart, was die GPU nicht machen kann? Wahrscheinlich fehlt mir da die Vorstellungskraft und was ich so an 08/15 Charts sollte eigentlich gut auf GPUs machbar sein.

Machbar ist alles auf der GPU, nur ob es dann schneller ist, ist eine andere Frage. Bei meinen Charts passiert genau Folgendes:

Was GPUs meines Wissens nach nicht besonders liegt, sind Kurven höherer Ordnung. Wahrscheinlich häufigstes Beispiel: Schriften Rendern. Aber auch andere (2D) Grafiken mit Bezier Kurven oder Kreisen oder so.

Schaue dir mal Bibliotheken wie Chart.js an. Eigentlich kannst du fast jede nehmen. Erstens ist Antialiasing immer an, wenn du mit einem Canvas 2D Context arbeitest, zweitens benutzen alle neueren Chart Bibliotheken Bezier Kurven (sieht einfach besser aus, wenn du Stichproben damit verbindest) und drittens werden heutzutage Charts auch schön animiert eingeblendet. Ist jetzt aber nur ein Beispiel.

Was gravitationsfeld mit "Webrender zeichnet nicht alles neu bei jeder Animation. " vielleicht meint ist folgendes:
https://github.com/servo/webrender/wiki
Es werden also schon verschiedene Dinge gecached, aber wird dennoch alles neu gerastert.

Klar kann man Dinge chachen und wie eine Textur behandeln. Aber wenn man das Ganze dann wieder animiert, nützt einem der Cache auch nicht unbedingt. Ich ging davon aus, dass WebRender wirklich alles auf der GPU macht (was mich etwas verwundert hätte). Aber da steht ja auch schwarz auf weiss, dass das eben nicht der Fall ist. So gesehen, ist WebRender jetzt auch nicht wirklich was Neues.