cacheAsBitmap eiert

[hgseib]

[OT]
es gibt vektor- und pixelgrafik.
vektorgrafik beschreibt den inhalt des bildes. auf diese 'beschreibung' kann man zugreifen und objektmässig ändern. vektorgrafiken sind postscript, DXF usw.
pixelgrafik (==bitmap) ist eine anhäufung von vielen punkten. ohne inhaltliche struktur. TIFF, GIF, jpeg usw. es gibt dann auch noch mischungen. z.b. PICT beinhaltet sowohl vektor als auch pixel. die variationen sind unzählbar.
pixelgrafik kann nur komplett geändert werden, oder es wird dazu ein wirkungsbereich ausgewählt.
um vektorgrafiken ansehen zu können müssen diese in pixelgrafik umgewandelt werden, das heisst rendern.
zum speichern auf die festplatte werden die daten kompremiert. GIF z.b. zeilenweisse, bei jpeg werden 8x8 punkte durch eine matrix dargestellt.

wird ein bild in den speicher geladen, dann wird eine 'GWorld' erstellt und darin die grafik dekompremiert (ausgepackt). im speicher kann man ein bmp oder gif nicht mehr von einem jpeg oder tiff unterscheiden! hier gibt es nur noch den unterschied zwischen schwarz/weiss, graustufe, farbe usw. - also die anzahl der bits je pixel (alpha und ebenen usw. sind mehrere einzelbilder).
erst beim speichern entscheidet man sich wieder, welche art das bild sein soll.

----------
früher, als prozessoren noch mit 1MHz betrieben wurden, gab es noch die variante, aus einem bild ein programm zu machen. wenn man aber den maschienencodebefehl weglässt bleibt auch nur das bitmap übrig.
----------

jetzt zu flash:
angenommen, ein mc besteht aus mehreren überlagerten flächen mit farbverlauf. dann wird das jeweils neu berechnet (in eine GWorld gerendert) - es könnte sich ja etwas geändert haben. spätestens jetzt unterscheidet sich das nicht mehr vom reinen pixelbild, das auch (dazu) gerendert wurde. die einzelnen GWorld's werden jetzt in den bildschirmspeicher compostet (wenn's zuviel ist, dann kommt der bildschirmrefrech noch ehe dieser vorgang abgeschlossen ist - das sind dann diese versetzten darstellungen).
damit richtest du übrigens im speicher auch nur eine GWorld ein:
new flash.display.BitmapData(...

neu in 8 ist cacheAsBitmap
ich denke, der name ist irreführend. da gibt es keinen cache, sondern nur ein flag. das besagt halt: nicht neu rendern, nim die GWorld vom letzten mal.
und, das ist keine feste einstellung, flash erkennt durchaus, wenn sich das mc geändert hat. siehe anhang: während der änderung geht es merklich langsammer. danach wieder schneller.


soweit wunderbar! aber ...
flash ist halt nicht nur für diese 'wusch'- bewegungen da! auch kleine, auch langsame bewegungen sind möglich (und die nicht nur rein waagrecht-, senkrecht und unter 45grad, sondern durchaus auch unter anderen winkeln). das geht aber nicht mit filtern und nicht mit cacheAsBitmap wegen der erzwungenen pixelausrichtung (auf letzteres könnte ich bei langsamen bewegungen verzichten, auf die filter möchte ich nicht verzichten. gerade von der bewegungsunschäfte hatte ich mir viel versprochen) und der daraus resultierenden hopserei.

ich hoffe, das die erklärung mit der GWorld verständlich war. und es wäre programmiertechnisch gesehen durchaus möglich gewesen, auch die per filter erzeugten GWorld's in kleineren schritten zu rendern und die schnellere pixelausrichtung rein per flag zu setzen (also bei einer filteranwendung genauso wie bei reinen mc's).

ist halt nicht :-( finde ich aber extrem ärgerlich.

[André Michelle]

ich denke, der name ist irreführend. da gibt es keinen cache, sondern nur ein flag. das besagt halt: nicht neu rendern, nim die GWorld vom letzten mal.

Ich glaube, da irrst du ?
In GWorld sind die Objekte nicht mehr trennbar, weil alles übereinander gerendert wird. Daher muss die Vektorgrafik in einem Bitmap zwischengespeichert werden, wenn man im nächsten Frame damit arbeiten will.

[hgseib]

"..In GWorld sind die Objekte nicht mehr trennbar, weil alles übereinander gerendert wird.."
würde lieber sagen auf eine ebene zusammengerendert. wie ein jpg aus einer photoshop-datei mit 50 ebenen abgespeichert. und ja, das ist nicht mehr trennbar (deshalb das original aufheben ;-).

"..Daher muss die Vektorgrafik in einem Bitmap zwischengespeichert werden.."
die vektordaten (sind ja nur zahlen und ab und an ein bisschen text) bleiben original erhalten. sonst könnte man einen winkel nicht von z.b. 30 auf 31 grad verändern. aus diesen vektoren wird dann wieder eine neue GWorld gerendert.
bisher halt bei jedem onEnterFrame immer wieder neu. mit der 8 nur noch, wenn ein vektor geändert wurde.

mein dilema: positionen sind auch vektoren. nur die berücksichtigt flash8 nicht so, wie ich mir das wünsche (im zusammenhang mit filtern). pech.

[tinic]

Ich bin der author der neuen bitmap routinen und habe ein paar kommentare. Entschulding im vorraus aber mein deutsch laesst zu wuenschen uebrig, so mein kommentar ist in englisch. :-)

Yes, if you turn on bitmap caching for a movie clip and translate that movie clip we do not apply sub pixel bitmap rendering. Main reasons: We have special BitBlt routines which are about twice as fast than going through the standard vector and bitmap renderer in Flash. This is essentially a shortcut in the rendering pipeline. We made a choice here and picked performance as being more important. This applies to filtered objects in general.

In a future release there will be a way to turn sub pixel precision, but not in Flash 8. There is a lot of work required to make this happen behind the scenes and currently there are only couple of engineers including me who work on this stuff.

Keep in mind that sub pixel rendering (basically it's just simple bilinear filtering) of bitmaps is extremely slow, about 4 times slower since it's all done in software (it's MMX/SSE/AltiVec optimized already). I anticipate that once we finally use hardware to render and compose bitmaps in a future release this drawback will go away.

Hope that explains it a little bit...

[hgseib]

aha, prominente leute ;-)


"..Entschulding im vorraus aber mein deutsch laesst zu wuenschen uebrig.."
meins auch. und erst mein englisch ;-)

alle sagen: "flash muss schneller werden" und jetzt hat MM 'ohne rücksicht auf verluste' versucht das zu erreichen. das verstehe ich!

ich kann meinen kunden, die langsame bewegungen haben wollen, diese filter nicht anbieten. bilder mit filter springen von punkt zu punkt.

ich muss wie bisher auch bilder in photoshop erzeugen. ich möchte doch nichts neues haben, sondern 'nur' mit diesen bildern das selbe machen, was ich auch mit geladenen bildern machen kann. diese routinen existieren. da muss nichts neu programmiert werden.


"..In a future release there will be a way to turn sub pixel precision, but not in Flash 8.."
ok, 2 years later ;-)

[hgseib]

"..There is a lot of work required to make this happen behind the scenes.."
falls die entwicklungsabteilung von MM nicht weiss wie man sowas machen kann, habe ich hier mal ein muster angehängt ;-)

die technik ist ab flash4 einsetzbar (benötigt den _alpha befehl, dann natürlich mit einem loop und nicht mit onEnterFrame - sollte klar sein).

[tinic]

Zitat von hgseib

"..There is a lot of work required to make this happen behind the scenes.."
falls die entwicklungsabteilung von MM nicht weiss wie man sowas machen kann, habe ich hier mal ein muster angehängt ;-)

die technik ist ab flash4 einsetzbar (benötigt den _alpha befehl, dann natürlich mit einem loop und nicht mit onEnterFrame - sollte klar sein).

We know exactly how the algorithm works, there are actually now two different implementations in the player now. :-) That is not really the problem. The problem here is how bitmap caching is defined and use cases we tried to address. And as I explained we have separate very fast bitmap blitting routines which currently do not support bilinear filtering on that level.

What I really want to see in the future is a way to 'lock' the bitmap of a movie clip, retaining its bitmap size at all times, not requiring rerendering when the movie clip is scaled, rotated, transformed or moved by sub pixels. This should provide another performance boost for some use cases and will also allow you to move it by sub pixels.

I know that the current solution is not perfect. But hey we are people too and I already worked way too much than is good for me health wise for Flash 8. ;-) I promise I'll try to fix this for the next version.

[hgseib]

my answer is a joke ;-)

if somewhat does not go, then one must look for a solution for it.
I found my solution!

[Aerks]

@hgseib

Mal den ganzen Kram + Filtergedöhns doch mit Bitmap.draw() in ein BitmapObjekt rein. Danach hast du nur noch einen Clip mit attachtem Bild und der Filtereffekt ist "eingebacken".

In diesem Fall sollten die Interpolationsroutinen doch wieder greifen (denke/hoffe ich)

OK. Pech nur, wenn du denn Filter animieren willst , aber wenn ich recht verstehe willst Du eh nur den Weg über Photoshop einsparen.

Viele Gruesse
=:] Aerks

[Hugo1of2]

alles kein prob mit animieren wenn man sie _richtig_ nutzt kann man auch mit den BitmapData sachen animierte filter machen. habsch alles schon gemacht. das is , meinermeinung nach, am ende sogar schneller als richtiges animieren

(applyFilter <--das zb ma anschauen)

[hgseib]

hab mein schneckenrennen noch ein bisschen optimiert.
rennt jetzt gleichmässiger und in alle richtungen.
benötigt jetzt 3 ebenen. speedy ist mehr ein spass. aber, wenn man in ebene a und b ein bild mit bewegungsunschäfte reinsetzt, dann sieht das auch besser aus, als 'nur' mit filter 10 punkte weiter springen.

weils zu gross ist hier:
http://www.seibsprogrammladen.de/fra...ispiele/flash7
-> langsam
Langsame Bewegungen und Schneckenrennen


@Aerks:
"..Photoshop einsparen.."
- muss bei jeder änderung/anpassung neu gemacht werden
- 'stufenloses' verändern ist nicht drinn
- fettere dateigrösse und
- nicht vektorisierbar.
da gibt es schon mehrere gründe, warum ich von blur begeister hätte sein können ...

@Hugo1of2:
"..habsch alles schon gemacht.."
prima!!! dann lade doch bitte mal ein beispiel von dir hoch, bei dem sich ein filter langsam bewegt.