AS3/OSMF: Bug im MediaPlayerSprite bei Browser-Resize

OSMF 2.0 hat einen Bug: Ich positioniere ein MediaPlayerSprite mittig auf der Bühne und skaliere es so, dass es eine gewisse Fläche immer füllt. Das Video darf links/rechts oder oben/unten aus der Fläche rausragen, solange die Fläche gefüllt ist (“scale proportional outside”).

Wenn ich allerdings den Browser ganz schmal ziehe, sehe ich unregelmäßig andere Ausschnitte des Videos. Die x-Position des MediaPlayerSprites stimmt genau, das Video darin aber nicht.*

Und, noch abstruser: Wenn ich den Browser am Rand anfasse und skaliere, dann verhält sich das Video anders, als wenn ich den Browser in der Ecke anfasse. Darauf muss man auch erst mal kommen; das sollte man sich merken für’s nächste Projekt.*

*getestete Flash Player Versionen: 11.x (nicht alle), 12.0

Wie auch immer: OSMF 1.6 hat diesen Bug ebenfalls, OSMF 1.5 allerdings nicht. Dafür sieht das Video in 1.5 unschön aus; offenbar ist smoothing nicht gesetzt. Es ist nicht ganz offensichtlich, wie man an das Video eines MedaPlayerSprites rankommt, aber das soll hier nicht das Thema sein 🙂 Weitere Einschränkung: StageVideo gibt es erst ab OSMF 1.6 – vielleicht liegt der Bug also auch im StageVideo?

HTH

AS3/OSMF: Auf NetStream zugreifen

Letztendlich hat mir das nicht weitergeholfen, aber da ich recht lange danach googlen musste: So geht’s [Quelle]:

Auf LoadEvent.LOAD_STATE_CHANGE kann man wohl auch prüfen [Quelle], ka, ob das nötig ist:

AS3: Lesbarer “link-report”

Mit dem mxmlc lassen sich “Link-Reports” erstellen; entfernt vergleichbar mit dem “Größenbericht” aus der Flash-IDE: Welche Klassen sind in meiner SWF enthalten, und wie viel Platz belegen sie. Die Compileroption dazu (in Ant-Schreibweise aus FDT):

Allerdings sind diese Linkreports schlecht lesbar. Ich möchte auf einen Blick sehen, welche Klasse der Grund dafür ist, dass mein SWF 2 MB statt 500 KB groß ist. Gut, dass es Theo Hultberg gibt: Der hat eine XSL geschrieben, um den Linkreport in eine verständliche Form zu bringen (hier der Blogeintrag und die lokale Kopie der XSL). Ant kann XSL von haus aus:

Das Ergebnis kann sich sehen lassen: Nach Größe sortiert und mit Verlinkung auf die Klasse/SWC

linkreport

[AIR] Art der Internetverbindung abfragen

Basierend auf diesem tollen Post (via Björn) ist folgende Funktion entstanden:

Den default-Parameter “*” zu verwenden macht allerdings fast nie Sinn; stattdessen benutze ich

  • “wifi” für WLAN
  • “en” für Ethernet
  • “mobile” für 3G usw

HTH

AS3: Eingebettete XML

Wer Fehler a la

identifier vor xmltagstartend erforderlich.

oder anderen kryptischen Kram bekommt, sollte die XML so einbinden:

Also: mimeType beachten, und dass die eingebettete Klasse nicht direkt auf XML gecastet wird. Außerdem ignoreWhiteSpace, das’ ja klar 🙂

Library-SWCs mit FDT erstellen

Es ist recht einfach, ein komplettes Projekt als SWC zu kompilieren: Rechtsklick auf’s Projekt -> Run as -> FDT SWC Library (Quelle). Ein Ant-Skript wäre schöner, aber grundsätzlich ist es so erst mal einfach. Was die Sache nämlich an anderer Stelle verkompliziert, ist der allseits beliebte Fehler 1047:

Parameter initializer unknown or is not a compile-time constant.

bzw.

Parameterinitialisierer unbekannt oder keine Kompilierungszeit-Konstante.

Dieser tritt dann auf, wenn man eine Konstante als default-Übergabe-Parameter nutzt, und die Klasse mit der Konstante erst nach dieser Klasse kompiliert wird. Oder so. Es gibt haufenweise Einträge dazu im Bug-Tracker, teilweise schon jahrealt, leider ohne Ergebnis. Die längste Antwort von Adobe (die nicht “OK, wird noch mal geprüft” lautet) ist “Wäre schwierig zu implementieren, machen wir nicht.”^^

Deshalb folgende Lösungsansätze:

  • Ein Workaround im Netz ist es, einfach keine Konstanten zu nutzen – das ist natürlich Quatsch.
  • Ein anderer ist es, die entsprechende Funktion zu ändern – statt “foo:Number=MyConstants.FOO” “foo:Number=NaN”. Man prüft dann in der Funktion auf NaN, und setzt ggf. dort erst die Konstante. Das funktioniert, aber das will man eigentlich nicht für externe Libraries (ich meine damit projektexterne Libraries, nicht das Projekt an sich, was hier ja auch eine Library werden soll^^) .
  • Dann: Unter Project Properties -> FDT Build Path -> Build Order die Reihenfolge der SWCs und Sourcefolder so zu ändern, dass die Klasse eben zuerst kompiliert wird. Geht auch nur, wenn Konstanten-Klasse und aufrufende Klasse in verschiedenen Packages liegen einen separaten Eintrag im Build-Path haben
  • Deshalb habe ich gerade ein neues Package einen neuen Ordner angelegt, zum Build-Path hinzugefügt, dort unter den korrekten Pfad die aufrufende Klasse verschoben, und dieses neue Package diesen neuen Ordner (heißt bei mir “compilerbug”) mit der oben beschriebenen Methode als erstes kompiliert 🙁 auch unschön, aber so muss ich wenigstens keine Klasse anderer Leute anfassen

Das nervt mich gerade extrem, hat jemand eine bessere Lösung?