Internet

Mozilla wbija kolejny gwóźdź do trumny Flasha

Wojciech Kulik | Redaktor serwisu benchmark.pl
67 komentarzy Dyskutuj z nami

Shumway to narzędzie, które sprawia, że Flash staje się coraz bardziej niepotrzebny.

Flash

Ponad dekadę temu Flash dosłownie odmienił Internet i uczynił go lepszym. Niestety z czasem z ulubieńca stał się niechcianym ciężarem. Dlatego też nadszedł chyba czas, aby powiedzieć mu ładnie „dziękujemy” i na dobre się z nim pożegnać. Takie starania trwają już od kilkunastu miesięcy, a poważnym krokiem na drodze do pozbycia się tego standardu było przejście platformy YouTube na HTML5. Teraz kolejny gwóźdź do trumny Flasha wbija fundacja Mozilla.

W najnowszej wersji przeglądarki Firefox Nightly ekipa Mozilli wprowadziła udoskonalone narzędzie, które sprawia, że Flash staje się coraz bardziej niepotrzebny. Nazywa się Shumway, a jego zadaniem jest dbanie o to, by witryny internetowe wyświetlały flashowe wideo nawet wtedy, gdy w przeglądarce nie jest zainstalowana wtyczka Flash. Dzięki temu użytkownicy otrzymują pełną funkcjonalność, nie narażając swojego komputera na problemy i obciążenia, z czego plug-in ten jest właśnie znany.

Obecnie niestety Shumway radzi sobie tylko z flashowymi filmikami na stronie Amazonu i tylko na nowszych systemach operacyjnych Windows i Max OS X. Narzędzie jest open source’ową alternatywą dla Flasha, zamieniając jego programowe instrukcje na własne, bazujące na JavaScript oraz HTML5. Z czasem Shumway ma być jeszcze potężniejszy oraz radzić sobie z innymi stronami i innymi elementami, takimi jak reklamy.

Już teraz natomiast wyraźnie widać, że czas Flasha dobiega końca. Wreszcie.

Źródło: CNET, SlashGear

Komentarze

67
Zaloguj się, aby skomentować
avatar
Dodaj
Komentowanie dostępne jest tylko dla zarejestrowanych użytkowników serwisu.
  • avatar
    Konto usunięte
    I bardzo dobrze. Moim zdaniem największa realna zasługa Jobs'a to właśnie wbicie pierwszego solidnego gowździa do trumny tej zakały technologicznej.
    Czas całkiem pozbyć się flasha.
    5
  • avatar
    Genocide
    chociaż by poprzez powyższy fakt - należy mu się "szacunek".
  • avatar
    ziemjak
    Zielone oszołomy z Greenpeace muszą jakoś zdobyć na utrzymanie swojej organizacji przestępczej, to co rusz gdzieś podnoszą raban. Eko-terroryści straszą to ociepleniem klimatu, to wyginięciem jakiegoś gatunku, albo odwalają takie akcje jak w dolinie Rospudy. Bardzo ciekawie przedstawia sytuację George Carlin w tym filmiku. https://www.youtube.com/watch?v=Gtszpk9zLL4
  • avatar
    Genocide
    hmmm... gdyby nie opcja z pozycjonowaniem flasha a raczej braku pozycjonowania tego CUDOWNEGO silnika graficznego - flash dziś byłby najpotężniejsza maszyną do tworzenia stron.
    To co dziś oferuje HTML 5 ( w animacji strony, guziczkach, menu - megamenu, przewijanych textach, o płynosci tych animacji nawet nie wspominam )... FLASH oferował dobre 15 lat temu!!! ... to sformułowanie "Już teraz natomiast wyraźnie widać, że czas Flasha dobiega końca. Wreszcie." jest trochę moim zdaniem nie na miejscu... bo fakt, że NIKT go nie rozwija zwł, w dziedzinie pozycjonowania nie oznacza, że to zakała internetu - wręcz przeciwnie - gdyby nie on to każdy większy portal - zawalony reklamami ślimaczył by się totanie. Co najlepsze nawet filmiki we flash w 720p chodzą płynnie na starszych platformach typu amd XP2500 ( zabytek obecnie ) ...
    -2
  • avatar
    Konto usunięte
    Ooo no i baja jeszcze tylko jak by dalo sie pograc w giery flashowe i bylo by calkiem spoko.
  • avatar
    Balrogos
    Tylko YT na HTML Odtwarza tylko 360p i 720p, inne tryby nie banglaja wogole.
  • avatar
    Kadzidło
    html5 na yt dziala po prostu lepiej, mam starego kompa, na ktorym flash juz tak zamulal ze az strach, od kiedy ustawilem sobie html5 na yt filmiki zaczely chodzic plynniej, lepiej, ladowac sie szybciej, jednyna wada jest tylko taka ze 720p to jest max dostepnej rozdzielczosci filmikow, ale mam nadzieje ze to sie wkrotce zmieni
  • avatar
    Qpers
    WSZYSTKO byle w końcu pozbyć się tego gównianego Flasha!

    Ile czasu Flash działa bezawaryjnie? A-dobę (choć i to już zawyżony czas).
  • avatar
    skoti
    Tworzenie modeli to zupełnie inna bajka i inna warstwa abstrakcji i mało ma wspólnego z samym WebGL. Grafika mało obchodzić powinno api.

    Przesadzasz chyba z tym UV ;]. Każdy grafik eksportujący dane gdziekolwiek wie, że V idzie w OpenGL i pochodnych w górę, a w DirectX w dół. Ofc tym może się zająć programista (v=1-v)... częściej widuje się panikę przy odwróconych normalnych, ale to bardzo małe problemy, przy konieczności wchłonięcia algebry liniowej i geometri analitycznej, aby bez problemu interpolowac kwaterniony w których zapisano obroty kości i konwersji ich do macierzy obrotu przekazywanej do shadera jako uniform.

    Tworzenie takich modeli nie jest trudniejsze czy łatwiejsze... jest inne. Zdecydowanie bliższe tworzeniu modeli do gier kilkanaście lat temu i modelowaniu pod telefony jakieś 7 lat temu. Gdy Vram miałeś 8MB pamięci musiałeś się jeszcze bardziej napocić.

    Chcę, żeby webmaster zajmował się tylko działką czyli programowaniem (też z WebGL). Ofc większość (99.99%? Wygląda groźnie, ale do faktycznie trudnych rzeczy przygotowanych jest wielokrotnie mniej ;p) nie jest do tego przygotowana i czeka ich mniej więcej rok nauki, aby się sprawnie poruszać (dlatego w stanach nie uczy się webmasterów, a kusi się programistów OpenGL i poducza webdeveloperki, bo czas skraca się z lat do tygodni - tak samo z grafikami - nie szkoli się grafików 2D, a zatrudnia się grafików doświadczonych w tworzeniu lowpoly dla embeded - Ci praktycznie z automatu nadają się do pracy). Jednak taki uczący się webGL webmaster niech sobie zatrudni grafika, bo miałby za dużo roboty i nauki w sumie (webgl+grafika 3d) na kilka lat, aby w głowie wiadomości się poukładały, bez gwarancji sukcesu. Tak samo jak nie jest dobrym pomysłem, aby webmaster był człowiekiem orkiestrą w stronach 2d (też grafika powinien sobie do pary zatrudnić, bo webmasterzy sami próbujący swoich sił z 2d to niezbyt często dobry pomysł... a ciężko porównać wiedzę, potrzebną do 2d, a do 3d i to przy mocnych ograniczeniach)
  • avatar
    Konto usunięte
    Tworzenie modeli do różnych zastosowań jest inne, ale też wymaga różnego poziomu wiedzy i doświadczenia.
    Render wybaczy wszystko, a jak nie to zaraz ktoś poprawi w photoshop'ie i to na tyle. Nikt nie wnika w topologię, import, eksport, pliki, formaty, atrybuty. Jak dalej brzydtko wygląda, to dadzą TurboSmooth^4 i renderuje się to godzinami.

    Renderowane animacje trudniej edytować w post-processing'u wiec bardziej trzeba się przyłożyć, ponieważ obiekty są również oglądane z różnych stron. Wymagania są nieco większe, ale wciąż siedzimy w jednym pakiecie oprogramowania, który potrafi prowadzić za rączkę, wyręczać i wybaczać. Nawarstwiają się jednak problemy z brakiem stabilności softu, którym wszystkiego poprawić nie potrafi za użytkownikiem.

    Modele 3d do gier są znacznie bardziej wymagające. Potrzeba już mniej lub bardziej przemyślanej topologii modeli oraz wyższej dokładności. Do tego dobre mapowanie UV i unwrap UV dla drugiego kanału, a na koniec skinning pod animacje szkieletowe. Na koniec jednak pakujemy wszystko w FBX i cześć. Najwyżej ktoś nie otworzy pliku w swoim sofcie i poprosi o konkretniejszą wersję FBX(np. 2012.3 ASCII), lub odwrócą mu się osie, któregoś z podstawowych atrybutów.
  • avatar
    Konto usunięte
    Modelowania i dostarczanie treści 3d do WebGL jest znacznie bardziej wymagające. Nie ma już kolorowych UI, kontenerowych FBX, ani nawet komercyjnego softu. Zamiast tego mamy nigdy niedokończone skrypty działające z linii komend, z wieloma zależnościami, których twórca nie chciało się zbytnio opisywać(eksporter OpenCTM + Maya x64 + Windows x64 to już apogeum). Zabugowane eksportery, które działają tylko w jednej wersji softu albo są zdolne do przetworzenia jedynie podstawowych atrybutów(zapomniej nawet o czymkolwiek poza vertices, faces, normals i UV1). Jeśli mamy eksporter to jeszcze dobrze. W innym przypadku potrzeba korzystać z eksportu, formatu wymiany i formatu konwersji, a konwerter akceptuje np. tylko i wyłącznie zabugowaną wersję OpenCollada 1.3, a na dodatek dane przechodzą wtedy przez 5 operacji kodowania/dekodowania. Przy większej ilości czynników i braku możliwości polegania na sofcie, trzeba tracić czas na budowanie sampli testowych i śledzenie tego, co dzieje się z naszą geometrią na kazdym z etapów operacji. Czasami jest łatwo i wszystko po prostu działa ze względu na to, że dany projekt nie wymaga niczego ponad standardowe minimum, ale realizacja kompleksowego projektu komercyjnego wymaga znajomości zasad działania geormetrii na najniższym poziomie jej atrybutów.
    Jak wspomniałeś jest inaczej i oczywiście raz rozwiązany problem jest rozwiązany na dobre, ale nie wiadomo kiedy pojawią się kolejne. Tym bardziej, że to bardzo eksperymentalna nisza i bardziej przeciera się nowe szlaki, a nie chodzi scieżką wytartą przez kogoś innego. Trzeba polegać najbardziej na sobie i swojej wiedzy.