Оказа се доста прост алгоритъм с доста интересна история, която и сами може да си прочетете

Демо може да видите тук: http://dailyffs.com/life/

Сорсът е тук: https://gist.github.com/1102964

Коментарът към сорса от страна на @skanev е тук: https://twitter.com/skanev/status/95213748092026880

Това, което искам да кажа в тази статия е, че колкото и да са бързи съвремените Javascript engine-и и колкото и разни светила и икони на браузър вендорите да се хвалят, че производителността скача многократно от версия до версия, това не значи че не може да забързате всичко още малко много. Цената на „забързването“ е „угрозняване“ и оптимизиране на кода. В моя конкретен случай – на една функция, която се вика 60000 пъти на преизчисление.

Въпросната фунцкия:

function getLiveNeighbours(id, data) {
  var x = id % canvas.width;
  var y = parseInt(id / canvas.width);

  var cnt = 0;
  for (var i = -1; i < 2; i++) {
    for (var j = -1; j < 2; j++) {
      if ((i != 0 || j != 0) &&
        !(x+i < 0 || x+i >= canvas.width || y+j < 0 || y+j >= canvas.height) &&
        data.data[4*((y+j)*canvas.width+(x+i))] != THE_BLACK) {
        cnt++;
      }
    }
  }
  return cnt;
}

Простата оптимизация на кода включва:

1. Премахване на извикването на функцията (тялото на функцията се ползва директно) – спестява 60000 извиквания и времето за изпълнение на една итерация пада от 500ms на 270ms
2. Заменяне на двата вложени цикъла проверяващи за броя на съседни клетки – от 270ms на 150ms
3. Опростяване на пресмятанията (премахване на умножения) – от 150ms на 60ms
4. Създаване на локални референции към често използваните данни (вместо постоянни извиквания от типа „obj.data“ при изчисленията се създава и използва локална променлива) – от 60ms на 50ms

// (4)
var width = canvas.width*4;
var d = data.data;
var nd = newdata.data;
var cw = canvas.width;
var ch = canvas.height;
var base = 0;

for (var i = 0; i < d.length/4; i++) {
  var x = i % cw;
  var y = parseInt(i / cw);

  var cnt = 0;
  // (1), (2), (3)
  if (x > 0 && d[base-4] != THE_BLACK) cnt++;
  if (x < cw-1 && d[base+4] != THE_BLACK) cnt++;
  if (x > 0 && y > 0 && d[base-4-width] != THE_BLACK) cnt++;
  if (y > 0 && d[base-width] != THE_BLACK) cnt++;
  if (x < cw-1 && y > 0 && d[base+4-width] != THE_BLACK) cnt++;
  if (x > 0 && y < ch-1 && d[base-4+width] != THE_BLACK) cnt++;
  if (y < ch-1 && d[base+width] != THE_BLACK) cnt++;
  if (x < cw-1 && y < ch-1 && d[base+4+width] != THE_BLACK) cnt++;
  ...

В крайна сметка производителността скочи 10 пъти, макар логиката на кода да изглежда по-зле от преди. Не, че преди изглеждаше много красива, но все пак

Разбира се има и още един доста по-умен начин за техническа оптимизация – Web Workers. Те са панацеята на всички проблеми, началото и края, давид и голиат, содом и гомор, ин и ян… за тях може да почетете тази статия - Mandelbrot + Web Workers

Забележка:

• става дума за проста техническа оптимизация на кода, а не за подобрения на алгоритъма!
• вероятно оптимизациите в javascript engine-ите не се фокусират върху случаи на извикване на функция 60 хиляди пъти… а би трябвало.

Обичам фрактална графика и поради липса на по-смислено занимание тези дни, реших да напиша визуализатор за Mandelbrot. Имплементацията ползва готините Web Workers, за да се справи с тоновете сметки и Canvas за да изобрази резултатът на екрана.

48 web worker-a се борят да запълнят 800х600 пиксела пространство и да си призная се справят по-добре от очакваното… е, все още си е бавно, но е 48 пъти по-добре отколкото без възможност за паралелно изпълнение на алгоритъма .

Резултатът може да видите тук – http://dailyffs.com/mandelbrot/

А кодът е достъпен тук – https://gist.github.com/1023445

Забележка: работи само с Firefox, защото другите браузъри или нямат web workers или не поддържат предаването на по-сложни обекти от/към worker-ите.

Ontwik е сайт, който събира в себе си записи от различни конференции на web тематика и дава възможност на всеки да ги гледа… безплатно. Темите, които следя са предимно Javascript, Ruby, Rails, Python, Django, Git, HTML5, но има още много други. Голямата част от лекциите са наистина качествени и интересни, като има записи на web гурута като David Hansson – създателят на Rails,  Tom Werner – един от създателите на Github, Линус Торвалдс, Brendan Eich – създателят на Javascript, и още много други.

Оставям ви с една много готина презентация на David Hansson:

„Why Ruby?“ – RubyConf X Keynote from David Heinemeier Hansson on Vimeo.

Тестове показват, че е напълно възможно да се създаде proxy cache poisoning (да се вкара вреден код в кеша на проксито), защото прокситат не разбират от Upgrade handshake-а, който WebSockets ползва. Това дефакто е проблем на прокситата, а не на протокола на WebSocket-ите, но за жалост не е възможно да се оправят всички прокси сървъри по света , за това се налага да се префасонира протокола на сокетите . Препоръката за сега е да се промени стандарта и да се полза CONNECT handshake-a вместо Upgrade handshake, тъй като прокситата го интерпретират правилно.

Най-вероятно няма да видим WebSocket-и във Firefox скоро, поне докато проблемът не бъде разрешен и стандартът не дефинира нов метод за handshake.

Повече подробности може да прочетете на http://www.0xdeadbeef.com/weblog/2010/12/disabling-websockets-for-firefox-4/ и http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html

Update: Opera спира поддръжката на WebSockets също – http://annevankesteren.nl/2010/12/websocket-protocol-vulnerability

На 20-и и 21-и Ноември в Интерпред (София) ще се проведе OpenFest 2010 и ако сте от хората, които обичат отворения код и семинарите, значи със сигурност ще сте там!

OpenFest се провежда за 8-ми пореден път, като тази година в програмата е включена сесия с Lightning Talks

Освен „стандартните“ презентации обаче, тази година се надяваме да обагатим програмата на OpenFest и с една сесия Lightning Talks – изказвания, които по правило продължават по не повече от 5 минути всяко и следват непосредствено едно след друго. Освен че са изключително интересни и забавни за присъстващите, тези кратки презентации предоставят незаменима възможност за нови участници да се представят за първи път, без да е необходимо да изнасят цяла лекция.

Така че ако имате нещо интересно, което да споделите за 5 минути с феновете на отворения код – тогава е времето.

Аз лично обмислям няколко теми за HTML5 – „HTML5 и (сигурната смърт на) Flash“, „Историята на HTML5 в 5 минути“ и „Бъдещият HTML5 в днешния уеб“

Тези дни хората от Mozilla Labs стартираха конкурс за разработка на изцяло уеб базирана игра. Състезанието се казва Game On 2010 и дава възможност на всички гейм или уеб разработчици да покажат на какво са способни, но… само с HTML(5)/Javascript/CSS.

Да – правилно прочетохте! Flash, Applet-и и други плъгини не са позволени, защото основната идея на конкурса е да покаже на какво са способни модерните браузъри. А те наистина са способни! HТML5 & Friends докараха на белия свят доста новости и купища ексцентрични API-та – Canvas елементът,  SVG (директно в html кода), WebGL, Web Sockets (двупосочна свързаност), няколко API-та за data storing, Video елементът и още много интересни благинки.

В конкурса могат да участват както индивидуални разработчици, така и екипи. Естествено и за награди е помислено, като за сега от Лаба са обявили само наградата за първо място – два билета за Game Development Conference 2011 в Сан Франциско, с включен път, хотел и храна. Награди ще има и за още дузина категории, така че запретвайте ръкави

Крайният срок за участие е 11.01.2011г.

Успех на всички

П.П. Аз лично смятам да се включа и съм навит за обединяване на усилията с други ентусиасти.

Ето и списък с промените:

• Разположението – меню с всички бутони и контроли в ляво, до менюто е платното, а под тях е информативен текст.
• Менюто се дели на 4 части – бутони с основни функции, бутон и контроли за crop, бутон и контроли за рисуване върху платното (избор на дебелина и цвят на четката), поле за въвеждане на специфичен ключ (ключа се ползва в URL-a с изображението).
• Информативния текст се дели да две паралелни колони, като в лявата има информация за функциите на уеб-туулчето, а в дясната има текст с общо предназначение.
• Състоянието на кенвъса по подразбиране трябва да има рекламен вид – да казва колко е лесно и полезно туулчето.
• Цветовете: Тъмно синьо, жълто, оранжево и бяло (за текста). Топлите и студени цветове, някак си противно на логиката, си паснаха. Тъмно синьото и бялото бяха първите два избрани цвят, които да си призная, разбрах че си пасват благодарение на това лого – http://screenshoot.me/7r04fQ . За оранжавото знаех, че е енергичен цвят, а за жълтото че прави много добър контраст с черно и тъмни цветове (освен това ми е любим). И така от цялата каша се роди една палитра, която е ЕДИНСТВЕНАТА свястна палитра, която някога съм подбирал.
• Бутоните и контролите представляват Canvas елементи и са изцяло генерирани от Javascript. Един ден ще бъдат заменени от HTML5 Web Forms.
• Наех домейн за уеб-туулчето – screenshoot.me
• Donation бутонче – домейнът струва пари
• Футър
• Undo – в случай, че нещо се обърка тотално.

Това „разкрасяване“ за пореден път подтвърди мнението ми, че хубавията дизайн се постига много по-трудно отколкото самата функционалност. Дано поне да си е заслужавало труда  и парите за домейн и да привлече повече потребители

С това обаче добрите вести не свършват, оказва се че и по HTML5 Forms работата върви с пълна пара, но какво точно ще видим в следващата версия на браузъра е трудно да се каже на този етап.  Пълен списък с прогреса по различните елементи и атрибути има тук: https://wiki.mozilla.org/User:Mounir.lamouri/HTML5_Forms

Последното нещо, с което ще ви занимая е един доста впечатляващ експеримент – Smoke Screen . Накратко това дава възможност на вашия HTML5 браузър да показва Flash анимации без да ползва Flash player… ъ-ъ-ъ странно нали . В случая цялата работа се извършва от Javascript + Canvas  елемент и преди да възкликнете „За какво би било полезно това, при положение че Flash плейърът е фрий“, ще ви напомня че  много съвременни смартфони не поддържат Flash (iPhone) и някои от CEO-тата на компаниите производители (Стив Джобс) публично се заклеха, че съпорт за Flash няма да има НИКОГА!

Та така, Web-a си върви, кучетата си лаят и определено ни чакат интересни месеци до излизането на Firefox 4.0

Понеже всичко до сега звучи прекалено хубаво, ще се наложи да ви приземя малко, защото Web Socket-и за сега се поддържат само от Google Chrome, но рано или късно и другите browser vendor-и ще се усетят откъде духа вятъра. И понеже вече се приземихте ето и едно примерно приложение, което сглобих – MultiDraw. Идеята е чрез HTML5 Canvas елемента и Web Socket-и да се постигне паралелно рисуване от множество клиенти върху платно. Сървърната част е на Python 2.6 и ползва модула asyncore от стандартната библиотека, който симулира асинхронно четене и писане от сокети.

Ето кодът, който се отнася до web socket-ите при клиента:

var s = new WebSocket("ws://" + document.location.host + ":6789/");
// създаване на сокет съединение на порт 6789
s.onopen = function(e) { document.title = 'MultiDraw - Online'; }
// функция, която да се изпълни при установена връзка
s.onclose = function(e) { document.title = 'MultiDraw - Offline'; }
// функция, която да се изпълни при прекратяване на връзка
s.onmessage = function(e) {
// функция, която да се изпълни при пристигане на съобщение (съобщението е в e.data)
    var data = e.data.split(" "); // обработваме съобщението...
    draw(data[0], data[1], data[2], data[3], data[4], data[5], data[6], data[7]); // ... и чертаем върху Canvas-а
}
...
s.send([x, y, e.pageX, e.pageY, color, brushSize, lineCap, lineJoin].join(' ')); // изпращане на съобщение

При сървъра, единственото по-екзотично е хендшейк съобщението и това, че всяко съобщение започва с нулев байт и завършва с 0xFF (може да го видите в кода на сървъра).

Кодът на клиента и сървъра е тук – http://gist.github.com/339983 .

Happy Web Socketing

P.S. Незнам дали забелязахте, ама редакторът на спецификацията за Web Socket-ите е „Ian Hickson, Google, Inc.“, така че няма нищо странно, че  тези чудесии се появяват именно в Chrome за първи път