FF: 7m breite Grafik wird lokal angezeigt, aber nicht im Web
Linuchs
- grafik
1 Rolf B0 Der Martin2 Felix Riesterer0 MudGuard
Moin,
eine 127 Takte lange Partitur (5-spurig) habe ich mit MuseScore als „kontinuierliche Ansicht“ ausgegeben, also als eine Zeile.
Die soll - gesteuert von einer mp3-Datei (currentTime) - unter einem Marker durchlaufen, sodass der Ton und die Note unter dem Marker übereinstimmen.
Wenn ich height:30em angebe, ist die Grafik 36.000px breit ≈ 7m und wird im Firefox nicht angezeigt, bei rechte Maustaste > Grafik anzeigen ist sie aber da. Wenn ich sie 40em hoch mache, ist sie mit dem FF auch lokal nicht zu sehen.
PaleMoon kann sie anzeigen und ziemlich korrekt ablaufen lassen.
Muss ich hier passen oder gibt es einen Trick?
Danke, wenn ihr die Seite mal mit verschiedenen Browsern testet.
Hallo Linuchs,
Keine Ahnung warum der Fuchs sie nicht mag. Bei mir tut er's auch nicht. Standalone-Darstellung funktioniert. Ein Bug in riesigen SVGs?
Chrome zeigt sie an, ist aber bei der Darstellung nicht auf dem Punkt. Teils ist sie über einen Takt daneben. Das hat mehrere Gründe:
Der Scrollbar unter der Notengrafik ist so eine Sache. Er ist natürlich nützlich, um sich die Partitur anzuschauen, aber wegen des transforms schrumpft er im Laufe des Abspielens auf 0 und ist irgendwann ganz weg. Das irritiert.
Besser wäre, mit scrollLeft auf dem div Container um das img zu scrollen statt mit transform. Glaub ich.
Gib dem img ein display:block (dann passt das auch mit 100% Höhe) und einen linken und rechten Margin so, dass Anfang und Ende des abzuspielenden Bereichs genau unter dem roten Strich sind. Das ist etwas tricky:
margin-right: calc(75% + 4px - 35px);
margin-left: calc(25% - 50px)
Die 75% und 25% kommen aus der Platzierung der roten Linie. Die 4px sind die Breite der roten Linie. Die Korrekturwerte 35px und 50px sind dagegen Image-Abhängig und natürlich auch abhängig davon, auf welche Größe Du es skalierst. Diese Werte musst Du zur Laufzeit berechnen, fürchte ich. Aber die kannst Du dann in custom properties (siehe SelfWiki) ablegen.
margin-right: calc(75% + 4px - var(--offset-left));
margin-left: calc(25% - var(--offset-right));
Die Werte für --offset-left und --offset-right setzt Du ins style-Attribut des img Elements, inclusive der px Einheit.
Und die scrollLeft-Eigenschaft des Elterncontainers kann dann von 0 bis X laufen, mit X = Breite des img minus 4px minus --offset-left minus --offset-right.
Das Parent-Element vom img sollte dann kein overflow-y:scroll mehr haben, das ist ein unnötiger Scrollbar.
MuseScore ist übrigens nicht gut geeignet für deine Zwecke. Es ist kostenlos, sicher. Die Autoren haben vielleicht Ahnung von Musik, aber keine gute Ahnung von SVG und das Ergebnis ist ein 6,3MB großes Datenmonster voller Redundanzen und mit Zahlenwerten mit unsinnigster Wahl der Nachkommastellen.
Wogegen Du auch nicht gefeit bist - warum setzt Du in movePartitur ein toFixed auf currentSec und currentProzent, wenn Du die Scrollposition bestimmst? Da rechnest Du doch noch und kannst keine Rundungen gebrauchen.
Rolf
Hallo Rolf,
erstmal tausend Dank, dass du dich so sehr in meine Problematik hineinkniest.
So eine scrollende Notenlinie mit Ton habe ich auf Webseiten noch nie gesehen, ist womöglich eine Weltneuheit. Da ich alles mit kostenloser Software und kostenloser Beratung gemacht habe, steht diese Idee und die Umsetzung für jedermann kostenlos zur Verfügung.
Wenn das bei Sängern und Musikern „ankommt“, könnte ich die Erstellung solcher Webseiten wohl automatisieren. Im Moment kämpfe ich ja noch manuell mit jedem Pixel.
Deine Ausführung arbeite ich in den nächsten Tagen ab, sie quillt ja über vor Ideen.
Gruß, Linuchs
@@Rolf B
MuseScore ist übrigens nicht gut geeignet für deine Zwecke. Es ist kostenlos, sicher. Die Autoren haben vielleicht Ahnung von Musik, aber keine gute Ahnung von SVG und das Ergebnis ist ein 6,3MB großes Datenmonster voller Redundanzen und mit Zahlenwerten mit unsinnigster Wahl der Nachkommastellen.
Vermutlich sollte man das SVG vor der Weiterverwendung optimieren. ImageOptim hat einen SVG-Optimierer mit eingebaut, aber es sollten sich auch andere finden lassen.
🖖 Живіть довго і процвітайте
Hallo,
Wenn ich height:30em angebe, ist die Grafik 36.000px breit ≈ 7m und wird im Firefox nicht angezeigt, bei rechte Maustaste > Grafik anzeigen ist sie aber da. Wenn ich sie 40em hoch mache, ist sie mit dem FF auch lokal nicht zu sehen.
die SVG-Grafik ist 6 MB "schwer" und will eine ViewBox von rund 196000px Breite haben, das wäre bei mir gut die 120fache Bildschirmbreite. Okay, du skalierst sie auf eine Größe, die bei meinen Anzeigeeinstellungen 41525px ergibt, bei 327px Höhe.
Zur Anzeige muss der Browser dieses Monster in eine Rastergrafik umwandeln. Die braucht Arbeitsspeicher in der Größenordnung von etwa 1 GB, wenn man von der im SVG "bestellten" Originalgröße ausgeht, und immer noch rund 40..45 MB, wenn man direkt von der skalierten Größe ausgeht.
PaleMoon kann sie anzeigen und ziemlich korrekt ablaufen lassen.
Respekt. Nun ist Pale Moon aber auch sehr viel genügsamer mit dem eigenen Speicherbedarf als sein Cousin.
Muss ich hier passen oder gibt es einen Trick?
Ich vermute, das wird bei einem gewissen Prozentsatz der Besucher einfach am Ressourcenbedarf scheitern, weil der eine oder andere Browser einfach mit den Dimensionen des entstehenden Bildes überfordert ist.
Einen schönen Tag noch
Martin
Hallo Martin,
danke für die Abschätzung der Größenangaben und Speicherbedarf, das eine oder andere gebe ich zwecks Kontrolle als console.log aus.
Ich hatte die Grafik anfangs von MuseScore als PNG erstellt. Die Datei ist noch größer als die SVG, die Anzeige zur Unkenntlichkeit verschwommen.
Natürlich habe ich mir auch im MuseScore Forum Rat geholt wegen des Exports von Daten. Dort bekomme ich genauso freundlich und prompt Antwort wie hier bei SelfHTML.
Ein Rat ist, Noten und Liedtexte als XML Datei einem andern Programm zu übergeben:
„Wenn Du die Musescoredatei als MusicXML exportierst und mit musicxml2ly ¹) in eine Liliypond-Datei verwandelst, kannst Du proportionale Notation ²) generieren und als SVG, PNG, etc. ausgeben ³)”
¹) https://lilypond.org/doc/v2.23/Documentation/usage/invoking-musicxml2ly
Eine weitere Baustelle, aber auch für Linux zu haben ...
Hallo,
LilyPond für Notensatz - wer kennt das Programm?
Die Leute auf der Mailingliste (englischsprachig): www.mail-archive.com kennen das Programm sehr gut. Im deutschsprachigen Lilypondforum gibt es auch ein paar…
Gruß
Kalk
Lieber Linuchs,
wenn ich den Zoom auf 67% herunterschraube, sehe ich die Grafik scrollen. Im aktuellen FF (Linux Mint).
Dein Konzept finde ich prinzipiell gut, aber es scheitert an den Unabwägbarkeiten, die unterschiedliche Plattformen so mit sich bringen. Meiner Meinung nach bist Du besser damit bedient, für jede Kombinationsmöglichkeit ein fertiges Video mit passender Audio-Spur anzufertigen. Da hast Du dann garantiert synchrones Bild mit Ton. Und da die Browser das inzwischen ja wirklich gut auf jeder Plattform anzeigen können, sollte das die zuverlässigste Darreichungsform sein.
Was die Tempoänderungen in der Wiedergabe angeht, so verwende ich einen Youtube-Plugin, der mir die Wiedergabe in 10tel-Schritten schneller oder langsamer erlaubt. Aber gerade habe ich etwas recherchiert und gefunden, dass es via JavaScript anscheinend eine Möglichkeit gibt, die Wiedergabegeschwindigkeit von Medien zu steuern. Das spräche auch dafür, künftig Videos einzusetzen, anstatt die Komponenten live zusammen rendern zu lassen.
Liebe Grüße
Felix Riesterer
Lieber Felix,
danke auch an dich, dass du Zeit investierst, um mir zu helfen.
ein fertiges Video mit passender Audio-Spur
Ist nicht die Idee, die hinter meiner Mühe steckt. Schon länger biete ich ein Mischpult auf Webseiten (auch oben auf der „problematischen“ Seite), damit jede Stimme / Instrument die eigene Spur zum Üben lauter stellen kann, aber die anderen hört. Mit zunehmender Sicherheit die eigene Spur leiser.
Das läuft recht zuverlässig und die rollenden Noten sind eine neue Herausforderung.
Hi,
eine 127 Takte lange Partitur (5-spurig) habe ich mit MuseScore als „kontinuierliche Ansicht“ ausgegeben, also als eine Zeile.
Also die ersten 7 Takte könnte man m.E. schon mal weglassen. Da passiert ja nix. Macht aber die Graphik ein gutes Stück kleiner.
Bei mir wird, wie bei Felix, die Graphik in der Seite dargestellt, wenn ich die Seite kleiner zoome …
Evtl. muß der Browser nicht die komplette Pixel-Graphik aufbauen, wenn Du mit CSS den angezeigten Bereich einschränkst. IIRC gibt es ne clip-Eigenschaft (oder so ähnlich).
cu,
Andreas a/k/a MudGuard
Hallo MudGuard,
was außerhalb des scroll-Containers ist, dürfte der Browser ebenfalls wegoptimieren.
Mir ist aber aufgefallen, dass Firefox die Grafik ausblendet, wenn ihre Breite über 32768 Pixel geht. Da scheint ein hartes Limit im Fuchs zu sein.
Update: https://bugzilla.mozilla.org/show_bug.cgi?id=591822 - angeblich behoben.
Rolf
Hallo
was außerhalb des scroll-Containers ist, dürfte der Browser ebenfalls wegoptimieren.
Mir ist aber aufgefallen, dass Firefox die Grafik ausblendet, wenn ihre Breite über 32768 Pixel geht. Da scheint ein hartes Limit im Fuchs zu sein.
Update: https://bugzilla.mozilla.org/show_bug.cgi?id=591822 - angeblich behoben.
Soweit ich erkennen kann, ist dies vor einigen Jahren in Version 54 ausgerollt worden. Wenn Linuchs nicht eine noch ältere Firefox-Version einsetzt, dürfte es sich nicht um diesen Bug handeln. usnahme wäre, wenn die Programmierer den den Bug verursachenden Code wieder in das Programm hineinexpediert hätten … über 50 Hauptversionen später.
Tschö, Auge
Hi,
Mir ist aber aufgefallen, dass Firefox die Grafik ausblendet, wenn ihre Breite über 32768 Pixel geht. Da scheint ein hartes Limit im Fuchs zu sein.
Update: https://bugzilla.mozilla.org/show_bug.cgi?id=591822 - angeblich behoben.
Soweit ich erkennen kann, ist dies vor einigen Jahren in Version 54 ausgerollt worden. Wenn Linuchs nicht eine noch ältere Firefox-Version einsetzt, dürfte es sich nicht um diesen Bug handeln. usnahme wäre, wenn die Programmierer den den Bug verursachenden Code wieder in das Programm hineinexpediert hätten … über 50 Hauptversionen später.
Das war damals ja wohl eine generelle Beschränkung für Bildbreiten.
Hier könnte es sich um eine Beschränkung im svg-Renderer handeln …
cu,
Andreas a/k/a MudGuard
Hallo
… usnahme wäre, wenn die Programmierer den den Bug verursachenden Code wieder in das Programm hineinexpediert hätten … über 50 Hauptversionen später.
Zu allererst: Ich kaufe ein „A“. 😁
Das war damals ja wohl eine generelle Beschränkung für Bildbreiten.
Hier könnte es sich um eine Beschränkung im svg-Renderer handeln …
Das ist mir beim stöbern in dem Bugreport auch aufgefallen. Da gibt es einen Kommentar, der auf einen HG-Commit mit Beispieldateien verweist und in jenem Archiv gibt es nur und ausschließlich Pixelgrafiken (GIF, JPG, PNG). Aber wie Rolf schon sagt, das in beiden Fällen identische Limit von 32767 Pixeln (16 Bit) riecht streng nach einem zumindest ähnlichen Problem.
Tschö, Auge
Hallo Auge,
du hast schon recht, aber der Schwellwert ist trotzdem auffällig. Ich hab nur keine Lust, mich in den Mozilla-Bugprozess zu knieen…
Rolf
Hallo Andreas,
Evtl. muß der Browser nicht die komplette Pixel-Graphik aufbauen, wenn Du mit CSS den angezeigten Bereich einschränkst. IIRC gibt es ne clip-Eigenschaft (oder so ähnlich).
Wenn das ginge ...
Ich hatte schon an tiles gedacht wie bei Landkarten. Aber das manuelle Zerstückeln von großen Grafiken wäre ein K.O. Kriterium für die Verbreitung des Konzepts.
Hallo Linuchs,
sowas sollte man auch automagisieren können.
Rolf
Hallo Rolf,
sowas (Grafik stückeln) sollte man auch automagisieren können.
Ja, PHP-Grafikbearbeitung, Dateiverwaltung, Datenbank und PHP-Erzeugung der Seiten (wer sonst sollte die erzeugten Grafiken kennen?).
Alles schön und gut für eine Erweiterung. Im Moment ist doch noch gar nicht klar, wie genau die Browser Noten unter einer roten Linie positionieren und bewegen können. Und wo sonst noch an Grenzen gestoßen wird.