2020 is shaping up to be an amazing year for JavaScript Internationalization API.
After many years of careful design we’re seeing a lot of the work now coming close to completion with a number of high profile APIs on track for inclusion in ECMAScript 2020 standard!
Let’s cut to the chase. Here’s the list of APIs coming to the JavaScript environment of your choice:
In just about a week Warsaw will be hosting a major JavaScript event – Falsy Values.
Falsy Values is brought to you by the two people – Damian Wielgosik and Paweł Czerski – who made their way onto the Web Event Stage last year with their widely praised Front-Trends conference.
This year, they focus on hardcode JavaScript. This conference is not about soft disciplines, not about social science, it’s solely about hacking the modern Web.
With stellar workshops and talks, with names such as Douglas Crockford, Tantek Çelik, Tom Hughes-Croucher and our homegrown stars like Kornel “porneL” Lesiński, it has what it takes to be the powerful event to be at.
Now, such an event is not going to happen on its own, it takes passion, dedication and the one thing we all should value most – time – to shape it up and deliver.
One of the unique features of this conference is that it really is handmade by those two fellows who work 24/7 right now to plug all the cables in the right slots, bring supply to the tables and speakers to the microphone.
All hands on deck!
As you may have guessed from the title – we believe we could use some help during the event itself!
If you’re located in Warsaw, or if you will be here for the time of the event, and you’re looking for a chance to participate in what’s going to happen there, help us make it perfect, learn the unique lesson from behind the scenes, here’s your chance!
We’re looking for geeks who seek experience in helping us run this event. Several brave souls to support speakers, guide the crowd through the agenda, run fiercely to aid some brother in JavaScript arms who’s in danger of any kind (like – you know that moment when your WiFi doesn’t work?)
We expect you to be there with us (even an hour before the opening), assist when needed and enjoy the conference. We offer an opportunity to learn, gain experience and help us make the best event in the JavaScript world since Brendan invented this monster!
Get in touch with us! Email me (gandalf at mozilla dot org) or contact Damian and Paweł directly and we’ll go from there. Hurry up, we only have 5-7 slots available!
Poniższy tekst jest tłumaczeniem artykułu “Content aware image resizing“, zamieszczonego na stronie hacks.mozilla.org na licencji Creative Commons Attribution 3.0 United States License. Autorem tekstu jest Christopher Blizzard. Spis wszystkich tłumaczeń artykułów z hacks.mozilla.org dostępny jest na stronach wiki.aviary.pl.
Zmiana rozmiaru obrazka z uwzględnieniem zawartości jest metodą skalowania obrazka bez zniekształcania zawartości, innymi słowy: nielinearne rozszeranie obrazków. Algorytm ten został po raz pierwszy opisany przez Shai Avidan i Ariela Shamira i opublikowany w 2007 (“Seam Carving for Content-Aware Image Resizing.”)
Od tego czasu powstało kilka świetnych implementacji tego algorytmu dostępnych na licencjach wolnego oprogramowania takich jak wtyczka do Gimpa czy CAIR – aplikacja napisana w C++.
Teraz, dzięki Canvas i językowi JavaScript możliwe jest wykonanie tego w przeglądarce bez użycia wtyczki.
Od wersji 1.5, Firefox oferuje możliwość manipulacji bitmapą z poziomu API Canvas. Wersja 3.5 nie tylko wprowadza jeszcze szybszy silnik JavaScript, ale też dodaje nową metodę dla Canvas – createImageData – umożliwiając tworzenie nowych rozwiązań.
Na potrzeby tego dema został zaimplementowany fragment algorytmu do zmiany rozmiaru obrazka z uwzględnieniem zawartości. Szerokość zdjęcia może byc zmieniana dynamicznie bez zmiany jego wysokości. Ta implementacja korzysta z wykrawania szwów (seam carving) do zmiany rozmiary obrazka, śledząc mało widoczne pionowe linie.
Jest to cztero-krokowy algorytm zagnieżdzony. Jedna iteracja zmienia rozmiar obrazka o jeden piksel. Na początek obrazek jest pobierany do kontekstu Canvas, a następnie rozpoczyna się iteracja:
Każdy z poprzednich kroków przechowuje w rozmiarze źródła zdjęcia całą matrycę danych. Choć te matryce nie są pełnymi zdjęciami, tylko artefaktami po algorytmie, przechowywanie ich jest znacznie wygodniejsze niż użycie prostych tablic (JS Array) i dlatego własnie wykorzystana jest tu metoda kontekstu Canvas o nazwie createImageData. Jedną z zalet zastosowania takiego procesu jest to, że można pokazywać pośrednie kroki które zostały wykonane w trakcie obliczania efektu końcowego.
To demo pokazuje w jaki sposób można wykonać bardziej inteligentne zmienianie rozmiar obrazka niż proste spłaszczanie pikseli w CSS. Mając możliwości manipulowania obrazek oraz moc obliczeniową dostępną z poziomu przeglądarki otwiera nowy zakres możliwości do tworzenia aplikacji WWW prezentujących dane wizualne użytkownikom. A to demo to przecież korzysta tylko z ułamka tych możliwości…
Wczoraj Mozilla ogłosiła prace nad silnikiem TraceMonkey. TM jest modyfikacją aktualnego silnika Gecko – SpiderMonkey, do którego dodana została opracowana przez pracowników Uniwersytetu Kalifornijskiego implementacja algorytmu JIT. Nie jest to może żadna czarna magia, po prostu opóźnienie wykonywania skryptów JS (każdy kto pracował z JS wie, jakie ograniczenia wydajności JS nakłada – nikt raczej nie pokusiłby się o tworzenie silników graficznych 3D w JS) jako interpretowanych jest tak duża, że okazało się, iż opłaca się skompilować wstępnie kawałki kodu JS i w przypadku występowania powtarzających się procedur odpalać skompilowane fragementy zamiast interpretowania kodu na bieżąco.
Efekty są bardzo wydatne.
Każdy kto śledzi planetę Mozilli widział już wykresy Brendana, Shavera i Schrepa. Ja wykonałem małe testy na benchmarku Dromaeo autorstwa niezrównanego Johna Resiga.
Wykonałem dwa testy – w Fx 3.0.1 i dzisiejszej kompilacji nocnej z włączonym JIT dla treści stron.
Wynik dla Fx 3.0.1, Wynik dla Minefield trunk i wynik porównania dwóch. Przyspieszyć o kolejne 46%? Nieźle… co? 😉
Najlepszą informacją w tym wszystkim jest to, że Brendan twierdzi, że JIT powinien być szybszy w dokładnie każdym teście. Jeśli gdzieś nie jest, jest to błąd i będą to teraz poprawiać… Całość implementacji zajęła 60 dni i jest to wersja bardzo wstępna, najbliższe miesiące powinny przynieść kolejne przyspieszenia wraz z optymalizacją nowych możliwości.
Co z Tamarinem? Tamarin to znacznie bardziej poważny eksperyment, wymagający dużego nakładu pracy. Ma być on podstawą silnika ActionScript, który zastąpi obecny w platformie Mozilla 2 (i w efekcie w Firefoksie 4).
Obecnie prace nad nim trwają w osobnym repozytorium na hg.mozilla.org, i zostanie on włączony do mozilla-central prawdopodobnie po wydaniu Fx3.1. Tamarin ma być oczywiście znowu, znacznie szybszy od TraceMonkey (gdyż będzie korzystał z jego dobrodziejstw i dodawał kolejne), będzie też pierwszą implementacją języka JavaScript 2.0 (który dla mnie jest przede wszystkim pokornym wzięciem największych dobrodziejstw Pythona:) ) ale można go już dziś przetestować kompilując tamarin-central.
Kolcami tej róży są problemy z debuggerami. JIT sprawia, że cały proces interpretacji przestaje być deterministyczny i nie za bardzo wiadomo jak to obejść. Na razie przy włączonym Venkmanie, Gecko wyłącza JIT, ale nie jest to optymalne rozwiązanie i będzie trzeba poczekać, aż Gijs wróci z wakacji i podejmie decyzje co dalej z Venkmanem…
Jeśli ktoś chce włączyć JIT, to może to zrobić na dwóch poziomach – dla stron i dla samego Firefoksa (about:config i szukaj “jit”). Włączenie dla Firefoksa oczywiście znacznie poprawia jego wydajność (duże części Fx napisane są w JS), ale jest w tym momencie dość ryzykowne. Natomiast dla stron jest dość stabilnie (zanotowałem kilka wywaleń w Gmailu i Facebooku tylko) i z każdym dniem będzie lepiej 🙂
Docelowo, w ActionMonkey i Mozilla 2, celem Mozilli jest aby jak najwięcej kodu było pisanego w JS, a wydajność JS była porównywalna z kodem kompilowanym (C++)… Coś co wydawało się niemożliwe, nie tylko stało się realne, ale jest aktualnie celem programistów w projekcie Mozilla. Mam nadzieję, że się uda 🙂