Czy_adobe_powinno_udoskonalic_system_eks_miniCzy adobe powinno rozwinąć skrypty, zwane powszechnie ekspresjami w Adobe After Effects? Andrew Kramer poruszył ciekawą dyskusję na swoim blogu zastanawiając się nad przyszłością programu Adobe, związku z przeniesieniem aplikacji Adobe Creative Suite 5 tylko na platformę 64 bitową. Uznałem że warto poruszyć ten temat także w naszym serwisie, patrząc na ożywione reakcje użytkowników na blogu.

Po co ten wpis?

Autor zwraca przedewszystkim uwagę na powolne działanie skryptów w AAE CS5, opierając się na przykładzie jednego ze swoich wcześniejszych projektów. Zauwazył on że mimo przeniesienia after efectsa na platformę 64 bitową, Adobe nie unowocześniło systemu skryptów. W zasadzie od czasów Creative Suite CS3 do którego został publicznie udostępniony oficjalny przewodnik po skryptach, system ten został nieznacznie rozwinięty głównie poprzez dodanie nowych metod do istniejących obiektów. O wprowadzonych zmianach możemy przeczytać tutaj w języku angielskim: zmiany wersji CS4 zmiany wersji CS5. Autor zaznacza że obecny system pozwala co prawda na często przez niego używane bezproblemowe łączenie parametrów czy kompozycji, jednak nie nadaje się do bardziej skomplikowanych projektów. Andrew Kramer zaproponował kilka rozwiązań i sam nawoływał użytkowników do składania propozycji zmian, które chce złożyć w oficjalnym raporcie dla firmy Adobe.

Problemy z ekspresjami

Zwrócił on także uwagę na sposób w jaki działa jego darmowy skrypt sure target (skrypt ułatwiający kontrolę kamery, którą można łatwo skierowac na konkretne obiekty w świecie 3D), gdzie zbyt wiele „celów” powodowało znaczne spowolnienie działania skryptu, a czasem nawet znane większości użytkowników lagi, czyli tymczasowe zatrzymania w jego działaniu. Rozwiązał ten problem po prostu tworząc na twardo kolejne klatki kluczowe, zamiast przeliczać ścieżkę animacji, jednak to rozwiązanie również okazało się mocno nie efektywne, jeśli chodzi o szybkość działania. Autor uważa że ze strony deweloperów istnieje sposób na przyspieszenie działania ekspresji poprzez dopuszczenie ekspresji do wyższego poziomu proceduralnego.

Zmiany, zmiany…

Sam zaznacza że nie wie jak przekształcić skrypty na poziomie jądra tego systemu, aby działały szybciej na poziomie aplikacji. Jednak zaproponował pewne rozwiązanie, które pomogło by np we wspomnianym sure target. Chce aby wartości klatek kluczowych dla wybranych przedziałów były zapisywane w pamięci podręcznej aplikacji – cache, zamiast ich ciągłego przeliczania. Jest to rozwiązanie pośrednie, które ma swoje plusy, jednak moim zdaniem, przypomina to łatanie dziury plastrem. Zadziała, ale na dłuższą metę to jest dokładnie to samo co jak określił autor „baking” czyli zapisywanie na twardo klatek kluczowych, tyle że bezpośrednio na pamięci podręcznej co teoretycznie powinno przyspieszyć dostęp do tych danych, bez konieczności zaśmiecania osi czasu zbędnymi klatkami kluczowymi. Zaleca on także aby system ekspresji powiązać bezpośrednio z jądrem systemu AAE, udoskonalić „współpracę” z pluginami tak aby nie działały w zakresie jednej warstwy oraz wprowadzić system grup warstw, tak aby zmieniając jeden ze skryptów, automatycznie zmieniły się „połączenia” innych skryptów w grupie, bez konieczności ich ręcznej zmiany na każdej warstwie. Nie zapomniał także o dodaniu łatwego w obsłudze kontrolera świata 3D, tak aby jak to określił „aby umieszczenie i kontrola nad obiektami nie wymagała kwalifikacji informatycznego geniusza” Zaproponował też rewolucję w postaci wprowadzenia globalnych zmiennych (ang. global variables).

Okiem MF

Muszę się zdobyć na odrobinę krytyki tego wpisu. Tak naprawdę część pomysłów jest po prostu niewykonalna ze względu na sposób w jaki działają skrypty w Adobe After Effects. Po krótkim zapoznaniu się z oficjalnym podręcznikiem do skryptów do wersji CS3 (wraz z wprowadzonymi później zmianami ) system ekspresji adobe after effects jest oparty o technologię JAVA, w którym to programiści Adobe udostępnili dostęp do modyfikacji obiektów wewnątrz programu przy pomocy gotowych klas i powiązanych z nimi metod. Jednak jest to system niezależy od jądra programu. Jest to tak zwany język programowania wysokiego poziomu, charakteryzuje się przedewszystkim brakiem możliwości ręcznego operowania na pamięci i operowaniu zadaniami tylko na poziomie wysokoproceduralnym. Całe zarządanie pamięcią w JAVA wykonuje automatyczny „zbieracz śmieci” (ang. garbage collector). Działa on w ten sposób, że traktuje każdy zaprogramowany element (nawet zmienną) jako obiekt, po czym poprzez proste oznaczenie przez programistę obiektu jako new (przy tworzeniu) i delete (przy usuwaniu), nasz znajomy śmieciarz sam zajmuje się adresowaniem i zwalnianiem pamięci. To już niestety w zasadzie niweczy pomysł Andrew Kramera co do zapisywania klatek kluczowych do cache, jak i apel o przeniesienie procedur skryptów na inny poziom. Podobnie też JAVA jest językiem obiektowym i trzyma się tego bardzo mocno, przez co przez swoją strukturę wyklucza istnienie globalnych zmiennych. Choć istnieje metoda na wprowadzenie takiej zmiennej tworząc nową klasę, ze zmienną zdeklarowaną jako publiczna, jednak będzie ona działać tylko wewnątrz ew. plug-inu, może ona pozostać niedostępna dla reszty programu, ze względu na niezależność systemu ekspresji w AAE.  Tak naprawdę w obecnym systemie wykonalnym z mojej perspektywy jest jedynie pomysł grupowania „połączeń” między obiektami, tak aby zmiana jednego, uaktualniła skrypt pozostałych obiektów w grupie.  Adobe w tym momencie stoi w pewnym rozkroku między możliwościami, a ułatwieniem dla użytkowników operowania skryptami wewnątrz after efectsa. Rezygnacja z obecnego systemu, i powiązanie go jądrem After Effects oznaczało by napewno zmianę używanego języka, na taki, który byłby zdolny do obsługi bardziej zaawansowanego zarządzania pamięcią jak i wizualizacji 3D chociażby poprzez ingerencję w obsługę OpenGl, z której AAE obecnie korzysta. Osobiście najchętniej widział bym język oparty o C++, choć we wspomnianymi przezemnie możliwościami, skrypty mogły by zostać zdominowane przez „informatycznych geniuszy”, tym samym stając się zbyt odległe dla szarego użytkownika. Warto wspomnieć, że ręczna ingerencja w OpenGl na obiekty w matrycy świata 3D stała by się przedsmakiem do wprowadzenia pełnej obsługi 3D, a to zpewnością nie spodoba się takim producentom oprogramowania grafiki trójwymiarowej jakim jest chociażby firma AutoDesk…