Přejít k navigační liště

Zdroják » JavaScript » Vytváříme kreslicí aplikaci s HTML5 canvasem (dokončení)

Vytváříme kreslicí aplikaci s HTML5 canvasem (dokončení)

Články JavaScript, Různé

Jsme tu opět s návodem k používání canvasu. V dnešním druhém dílu dokončíme naši kreslicí aplikaci, přidáme další kreslicí nástroje (kreslení obdélníků a úseček) a zmíníme řadu nápadů, jak můžete výslednou aplikaci sami vylepšit.

Tento článek je druhým dílem překladu anglického originálu vydaného na Dev.Opera. Jeho první část jste si mohli přečíst před několika dny.

Přidání dalších kreslicích nástrojů

Nyní k aplikaci z minulého dílu přidáme další kreslicí nástroje. Každý z nich bude mít svůj vlastní objekt s příslušnými událostmi.

Nejprve přidáme rozbalovací menu, ve kterém může uživatel mezi jednotlivými nástroji vybírat. Toho docílíme přidáním následujícího kódu:

<body>
<p><label>Drawing tool: <select id="dtool">
  <option value="rect">Rectangle</option>

  <option value="pencil">Pencil</option>
</select></label></p>
<!-- ... -->
</body> 

Dále upravíme náš skript z minulého dílu, aby dokázal pracovat s více nástroji:

// ...
// Aktivní nástroj.
var tool = false;
var tool_default = 'rect';

function init () {
  // ...
  // Získej prvek select.
  var tool_select = document.getElementById('dtool');
  if (!tool_select) {
    alert('Chyba: nenalezen prvek dtool!');
    return;
  }
  tool_select.addEventListener('change', ev_tool_change, false);

  // Aktivujeme výchozí nástroj.
  if (tools[tool_default]) {
    tool = new tools[tool_default]();
    tool_select.value = tool_default;
  }
  // ...
}

// ...
// Obsluha události pro změnu nástroje.
function ev_tool_change (ev) {
  if (tools[this.value]) {
    tool = new tools[this.value]();
  }
}

// Tento objekt obsahuje implementace všech kreslicích nástrojů.
var tools = {};

// Nástroj tužka.
tools.pencil = function () {
  // ...
};

// ... 

To by stačilo (kompletní kód najdete v příloze). Kód výše nastavil obsluhu událostí pro prvek <select>. Implementace všech kreslicích nástrojů je umístěna v objektu tools a proměnná tool obsahuje instanci aktivního nástroje. Funkce ev_tool_change() zajišťuje, aby proměnná tool vždy obsahovala instanci nástroje vybraného uživatelem.

Výhodou našeho kódu je, že každý nástroj může mít svou logiku umístěnou uvnitř instance nezávislou na zbytku kódu. Jakmile je nástroj aktivován, můžete dělat opravdu cokoliv chcete, např. ptát se uživatele na řetězec, číslo nebo jiný vstup.

Vytvořili jsme si tak dobrý základ pro tvorbu dalších nástrojů. Pojďme se tedy podívat na implementaci dalšího kreslicího nástroje.

Kreslení obdélníků

Implementujme tedy nástroj pro kreslení obdélníků a otestujme si výsledek (aktualizovaný skript):

// ...
tools.rect = function () {
  var tool = this;
  this.started = false;

  this.mousedown = function (ev) {
    tool.started = true;
    tool.x0 = ev._x;
    tool.y0 = ev._y;
  };

  this.mousemove = function (ev) {
    if (!tool.started) {
      return;
    }

    var x = Math.min(ev._x,  tool.x0),
        y = Math.min(ev._y,  tool.y0),
        w = Math.abs(ev._x - tool.x0),
        h = Math.abs(ev._y - tool.y0);

    context.clearRect(0, 0, canvas.width, canvas.height);

    if (!w || !h) {
      return;
    }

    context.strokeRect(x, y, w, h);
  };

  this.mouseup = function (ev) {
    if (tool.started) {
      tool.mousemove(ev);
      tool.started = false;
    }
  };
};
// ... 

Implementace tohoto nástroje je jednoduchá a snadno pochopitelná. Obsahuje stejné základní kameny jako nástroj pro kreslení tužkou. V tomto případě si ale uložíme počáteční bod, který potřebujeme pro nakreslení obdélníku při každém pohybu myši.

Zkuste si ale nakreslit dva obdélníky. Vidíte, kde je problém? Jistě, první obdélník je smazán voláním metody clearRect(). Tohle volání nemůžeme odstranit, protože pak by celý nástroj byl nepoužitelný (každý obdélník nakreslený během pohybu myši by zůstal na obrazovce).

Použijeme proto pro náš nástroj pomocný canvas. Iniciační skript přidá nový prvek canvas se stejnými rozměry, jaké má náš původní canvas, a umístí jej přes něj. Všechny nástroje tak musí kreslit do pomocného canvasu a když je jejich operace ukončena, budou nakreslené pixely přeneseny do původního canvasu.

Vyzkoušejte si živou ukázku, ve které už bez problému nakreslíte více obdélníků.

Podívejme se na provedené změny v našem skriptu. Iniciační funkce bude vypadat takto:

// ...
var canvas, context, canvaso, contexto;

function init () {
  // Najdi prvek canvas.
  canvaso = document.getElementById('imageView');
  if (!canvaso) {
    alert('Chyba: Nemůžu najít prvek canvas!');
    return;
  }

  if (!canvaso.getContext) {
    alert('Chyba: neexistuje canvas.getContext!');
    return;
  }

  // Získej 2D context canvasu.
  contexto = canvaso.getContext('2d');
  if (!contexto) {
    alert('Chyba: nelze získat context!');
    return;
  }

  // Vytvoř pomocný canvas.
  var container = canvaso.parentNode;
  canvas = document.createElement('canvas');
  if (!canvas) {
    alert('Chyba: nemůžu vytvořit nový canvas!');
    return;
  }

  canvas.id     = 'imageTemp';
  canvas.width  = canvaso.width;
  canvas.height = canvaso.height;
  container.appendChild(canvas);

  context = canvas.getContext('2d');

  // ...
} 

Nová funkce img_update() vypadá následovně:

// Funkce nakreslí canvas #imageTemp na vrch canvasu #imageView,
// a vymaže canvas #imageTemp. Funkce je zavolána vždy,
// když uživatel dokončí kreslicí operaci.
function img_update () {
  contexto.drawImage(canvas, 0, 0);
  context.clearRect(0, 0, canvas.width, canvas.height);
} 

Po dokončení každé kreslicí operace musíme zavolat funkci img_update(), aby se nakreslené pixely uložily do vytvářeného obrázku. Upravený nástroj tužka by vypadal takto:

// Kreslení tužkou.
tools.pencil = function () {
  // ...
  this.mouseup = function (ev) {
    if (tool.started) {
      tool.mousemove(ev);
      tool.started = false;
      img_update();
    }
  };
}; 

V případě kreslení tužkou i kreslení obdélníku je kreslicí operace ukončena, jakmile uživatel uvolní tlačítko myši. Stačí tedy, když přidáme volání img_update() do obsluhy události  mouseup.

Musíme provést ještě drobnou úpravu v kaskádových stylech našeho dokumentu:

<style type="text/css">
  #container { position: relative; }
  #imageView { border: 1px solid #000; }
  #imageTemp { position: absolute; top: 1px; left: 1px; }
</style> 

Přidaná pravidla zajistí, aby byl dočasný canvas umístěn přes canvas původní.

Kreslení úseček

Když už máme všechno připraveno, je přidávání nových nástrojů velmi snadné. Skript s implementací kreslení úseček bude obsahovat následující kód:

tools.line = function () {
  var tool = this;
  this.started = false;

  this.mousedown = function (ev) {
    tool.started = true;
    tool.x0 = ev._x;
    tool.y0 = ev._y;
  };

  this.mousemove = function (ev) {
    if (!tool.started) {
      return;
    }

    context.clearRect(0, 0, canvas.width, canvas.height);

    context.beginPath();
    context.moveTo(tool.x0, tool.y0);
    context.lineTo(ev._x,   ev._y);
    context.stroke();
    context.closePath();
  };

  this.mouseup = function (ev) {
    if (tool.started) {
      tool.mousemove(ev);
      tool.started = false;
      img_update();
    }
  };
}; 

A to je celé, vyzkoušejte si živou ukázku.

Nástroj je podobný nástroji pro kreslení obdélníků. Funkce mousedown() uloží souřadnice počátečního bodu, které se použijí v metodě mousemove() pro nakreslení úsečky.

A co dál?

Nyní byste měli mít dobrou představu, co je třeba k vytvoření takové kreslicí aplikace. Kromě kreslení do canvasu musíte vzít v úvahu také několik bodů:

  • Aktuální struktura objektu kreslicího nástroje je postavená na událostech. Pro některé nástroje budete potřebovat další události jako jsou pre-activation, post-activation nebo deactivation. Například nástroj „Vlož obrázek“ může po uživateli vyžadovat zadání URL, ale pokud to uživatel zruší, musí skript nějak zrušit aktivaci nástroje.
  • Budete určitě potřebovat další obsluhy událostí. Pouhé tři, které jsme použili, nebudou stačit (vzpomeňme kontextová menu, dvojklik atd.). Přidání dalších událostí do seznamu by mělo být triviální.
  • Budete chtít uchovat historii pro operace Undo / Redo. K tomu můžete zvolit ze tří přístupů: uchovat v paměti nakreslený obrázek po každém kroku, pamatovat si všechny provedené operace (jako makro) nebo kombinace předchozích dvou způsobů. Každý má své pro i proti. První je rychlejší a snazší na implementaci, ale vyžaduje hodně paměti a v případě velkých obrázků bude ukládání historie pomalé. Druhá metoda je komplexnější a pomalejší, když budete ukládat příkazy v historii a znovu je spouštět. Hybridní metoda je nejkomplexnější řešení, ale v závislosti na situaci může být řešením nejrychlejším.
  • Pro řadu kreslicích operací se budou hodit klávesové zkratky. Kreslicí objekt pak bude potřebovat obsluhovat víc událostí.
  • Každá nástroj by měla mít svou vlastní sadu vlastností (např. barva, tloušťka atd.).
  • Můžete zvážit použití SVG spolu s canvasem pro větší spektrum možností.
  • Základem aplikace je její uživatelské rozhraní: příkazy, nástroje, klávesové zkratky a zvládnutí obecných use cases. Vaše aplikace musí být příjemná pro denní používání.

Pokud se chcete naučit víc, podívejte se na open source projekt Paint.Web. Tutoriál, který jste právě dočetli, vychází z kódu použitého v projektu Paint.Web, proto by pro vás neměl být velký problém kódu porozumět.

Tento článek je překladem textu Creating an HTML 5 canvas painting application, jehož autorem je Mihai Sucan a je zde zveřejněn s laskavým svolením Opera Software.

Komentáře

Subscribe
Upozornit na
guest
14 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Ped

Nejsem aktivnim webovym vyvojarem, ale kdysi jsem delal graficka dema a pocitacove hry a proto si myslim ze mam ke canvasu co rict. Trochu jsem preletel pohledem jeho definici a cetl jsem taky tyto tutorial clanky a mam par pochybnosti o aktualnim navrhu (ja vim ze to jsem si vzpomnel moc "brzo" a ze to spis patri jinam nez sem, ale zase chtel bych nejdriv slyset nazory jinych lidi aby mne pripadne opravili a az pak to napsat nekam kde se to dostane i ke tvurcum canvasu).

Podle mne canvas neumi par zakladnich veci ktere budou jeho pouziti znacne limitovat (nebo jsem jen nepochopil jak je udelat, tak mne pripadne opravte).

1) neumi spolupracovat se zbytkem HTML na urovni pixelu, t.j. nejde vytvorit "overlay" canvas nad strankou ktera zobrazuje treba nejaky text, v tom overlay canvasu toto "pozadi" precist na urovni pixelu a udelat s nimi nejakou operaci a vykreslit je do canvasu samotneho.
Tahle vlastnost je klicova pro *netusene* moznosti pouziti canvas, treba konkretne bych rekl ze tahle vlastnost by umoznila uplne nahradit textove operace (v kombinaci s nejakym hidden div-om kde by se vypsal libovolnym HTML zpusobem text (treba i flash), canvasem nad nim by se sejmul v podobe bitmapy a (upravil+)pouzil se nasledne jako obrazek v jinem canvasu). Dalsi konkretni napad je efekt "vlneni" a ruznych jinych deformaci, treba pri zvyraznovani aktualni polozky menu na kterou ukazuje kurzor. A slovo "netusene" vyjadruje prave ten zbytek.

2) double/triple buffer – pro hladke/neblikajici animace naprogramovane jednoduchym zpusobem je dulezite aby bylo mozne si pripravovat novy vysledny obrazek "mimo" pohled uzivatele a az ve chvili kdyz je dokonceny, tak nim nahradit obrazek stary. Aktualne to patrne pujde udelat canvasem v hidden div-u, ktereho obsah se nasledne prenese do toho viditelneho, ale potrebuji a) potvrdit ze to vubec takhle jde obejit a ze malovani do hidden divu je funkci (ja jsem moc linej napsat tech par radku jscriptu :), omlouvam se), b) nativni podpora double/triple bufferu by patrne umoznila mnohem lepsi vykon. Na modernim PC kdyz se bavime o canvasu velikosti 500×500 to uz prakticky asi clovek nepociti, ale v pripade ruznych mobilnich web browseru a her to muze udelat rozdil mezi vhodnosti/nevhodnosti canvas-u jako "platformy". Taky v pripade triple buffer techniky by slo nechat jednotlive prepnuti na novejsi obrazovku na prohlizeci, ktery by ji mohl vhodne synchronizovat s prekreslovacim paprskem. Kdyz si predstavim ze steluji plynulost animace 60Hz casovacem v jscriptu, tak mne jima hruza. Mozna podcenuji presnost casovych udalosti jscriptu, ale osobne od toho cekam jen problemy, a nativni podpora je nativni podpora.

3) dalsi funkce pro praci s pixel bufferem canvasu.
3a) zakladni pro manipulaci v ramci samotneho canvasu, t.j. nejake vysoce optimalizovane presouvani obdelniku, idealne vcetne zakladnich transformaci. Aktualne kdybych chtel udelat jednoduchy "text scroller", tak bud v kazdem framu budu malovat cely text od znovu, nebo rucne po jednotlivych pixelech popresouvam stary text o par bodu dal a domaluji zbytek, co v jscriptu asi neni uplne nejlepsi napad, i kdyz moderni jscript enginy tohle nejspis zkompiluji do nativniho kodu. Presto nativni manipulacni funkce by meli zarucit slusny vykon v kazdem browseru.
3b) malovani z jinych obrazku, vid. clanek z teto serie http://zdrojak.root.cz/clanky/pseudo-3d-hry-v-html5-canvasu-s-raycastingem/ kde je zrejme ze ne kazdy browser to implementuje stejne. Rozhrani by melo byt jednotne a dostatecne restriktivni aby bylo jiste ze implementace bude co se tyce vykonu hodne optimalni. Pripadne restrikce at si pak vyresi konrektni aplikace jak uzna za vhodne, ale lepsi primitivni rozhrani s velkym vykonem (ktere jde nakonec vzdy obejit manipulaci jednotlivych pixelu za cenu nizkeho vykonu), nez neurcite rozhrani s neurcitym vykonem ktere v kazdem browseru funguje jinak. Kazdopadne malovani z jinych obrazku bude velmi dulezite pro ruzne formy "texturovani" a "spritu".

Treba jsem neco pochopil spatne, tak mne pripadne opravte/doplnte/poradte, nebo pokud se mnou nesouhlasite a myslite si ze aktualni podoba canvas je opravdu tak uzasna ze moje pripominky jsou nepodstatne.

Ale IMHO canvas aktualne s danym 2d contextem je velmi omezeny, az bych rekl ze skvela myslenka byla dusledne pohrbena.

Ped

"Tohle se zvažovalo, ale z bezpečnostních důvodů nelze pripustit"

To je velka skoda… kdyby to slo nejak udelat, ze by treba HTML atributem oznacilo casti ktere muze canvas nacist.. ale cele to zni uz moc slozite.
Tohle samotne na nestesti limituje pouziti (i zneuziti :)) canvas zcela zrudnym zpusobem.

"Lze urcite pouzit sejmuti casti canvasu a nove vykresleni takto sejmute casti na definovanych souradnicich."

To bude vzdy o dost pomalejsi nez nativni podpora nekterych zakladnich operaci.

"Lze pracovat s obrazky pochazejicimi z teze domeny, na ktere se nachazi stranka s cavasem."
Otazka zni jestli to jde delat velmi velmi rychle a ve vsech browserech stejne. Snad se to brzo sjednoti a vyladi vykon.

"Omezeny vzhledem k cemu?"
Vid. texturovany "3D Wolfenstein", ktery ma naprosto tragicky vykon. Aktualne bych odhadoval ze canvas je na tom vykonove hur nez flash. A flash je naprosta tragedie v porovnani s nativnim kodem. Wolf3D v 320×200 v 256 barvach fungoval velmi slusne jiz na 386 25MHz. Dnesni mobily jsou nekolikrat vykonnejsi, ale s tim canvas wolfem ma trochu problem i 2GHz PC, pri podobnem rozliseni a jen 4 nasobne barevne hloubce.

Proste u (interaktivni) grafiky je prvni bariera celkovy vykon. A u celkoveho vykonu hraje znacnou roli navrzene API. Nekdy prilisna univerzalnost poskodi vykon dane funkce nekolikanasobne. A v tomhle smeru podle mne canvas nasadil zatim latku velmi nizko a diky aktualnimu navrhu API bude slozite ji radikalne zvednout.

Rado2

Nejako mi to asi večer už nemyslí. Ale neviem prísť na to, v čom by spočívalo nebezpečenstvo. Javascript predsa má aj tak prístup k DOMu svojej stránky, takže si ju môže čítať priamo, tak prečo by bol problém čítať bitmapu vlastného framu?

Rado2

No povedzme že JS nemá prístup k vloženým ActiveX a objektom (word doc, flash, atď). To je jediné čo by cez canvas videl navyše a to sa dá ošetriť tak, že namiesto obsahu takýchto objektov by browser do canvasu skopíroval napr. len bielu plochu.
Ale aj tak neviem ako by ten útok mal fungovať, že by na útočníkovej stránke bol vložený JS, čo vytvorí do stránky objekt a otvorí v ňom napr. http://192.168.1.100/secret.doc a potom ho cez canvas prečíta? Zdá sa mi to dosť nepravdepodobné, musel by to byť nejaký bývalý zamestnanec a firma by musela naozaj používať docy namiesto HTML a napokon neviem či to vôbec webbrowsery povoľujú, vkladať do dokumentov na internetových doménach obsah z intranetu.

Ped

Co treba specialni atribut pro vsechny html znacky ktere canvas ma videt, treba.:
<div canvas="visible-all-childs">
… vsechno tady canvas uvidi…
</div>
Implementace zni slozite (aby se odfiltrovaly SVG a pod.), pokud se neudela jednoduchym dvojitym renderovanim, t.j. do offscreen transparentniho buffra (v podstate do canvas) by se vyrenderoval jenom ten <div> a podstrcil canvasu jako zdroj pixelu. Tohle by podle mne slo implementovat relativne jednoduse, vcetne dynamicke zmeny DOM.

V principu je to souboj o to, co je canvas. Jestli je to doplnkovy nastroj k tomu co web browser jiz umi, nebo jestli je to oddeleny modul. To prve by bylo mnohem uzitecnejsi. Je to univerzalnejsi (t.j. ma to vetsi moznosti), min narocne na vyvoj a na adopci do stavajicich aplikaci. Proste jednou za cas kdyz se vam to hodi, tak tam nejaky ten canvas prihodite a nechate ho udelat tu extra praci navic co HTML nezvladne.

To, ze aktualne je to oddeleny modul, se projevuje treba jiz na navrhu funkci pro kresleni textu, ted kazdy browser krome toho ze tento problem jiz musel vyresit pro obycejne zobrazeni textu v HTML bude muset mit dalsi znacny kus (nekterym lidem mozna "wrapper" nad low level funkcemi neprijde az tak hrozny, ale podle mne kdyz je jen vysledkem spatneho navrhu, tak je to spatny hodne) kodu ktery udela to same pro canvas. Vyrobci browseru pro mobilni zarizeni budou urcite stestim bez sebe, kolik zbytecne zabrane RAM kodem timhle pristupem vznika. (flash je typicky priklad v podstate nezavisle aplikace uvnitr jine aplikace ktere vzajemne delaji spoustu stejnych veci, ale kazda naprosto vlastnim kodem a stylem … canvas IMHO miri stejnym smerem, jenom bude tento kod navic integrovan ve zdrojaku k tomu puvodnimu)
Takze ve finale je vysledkem mnohem omezenejsi nastroj a snizeni kvality zdrojoveho kodu browseru (co ma dopad na vykon, bezpecnost a rychlost vyvoje).

IMO canvas jako oddeleny modul je zbytecny balast navic, tech par veci co umozni podle mne nestoji za to kolik prinese problemu a dalsi bobtnani browseru samotnych. Tech par demo ukazek mne nepresvedcili, ze by to stalo za ty dusledky, co jsem videl by slo nahradit flash nebo java appletem. Jesti nekomu vadi ze oboji vyzaduje externi plugin, tak v tomhle pripade je to podle mne jen slovickareni, teoreticky canvas je pak na stejne urovni jako kdyby se Adobe domluvil s Mozillou, pridal zdrojaky flash playeru do jejich repozitare a spravovali to spolecne jako jeden projekt.

(nasledujici odstavec je myslen obecne bez ohledu na existenci canvas, ale je snad zrejme co z toho pro canvas vyplyva)
Browserova platforma pro hry je sice v principu velmi neefektivni vymysl, ale prakticky se jiz ted pouziva (vid. treba Quake live, snaha o 3D engine u Opery a Googlu, ruzne java/flash hry a i ciste HTML/CSS hricky), bud jsou hry na urovni toho co aktualni platforma umoznuje, nebo se to obchazi ruznymi pluginy typu shockwave nebo primo activeX komponentou. Takze tenhle vyvoj uz zastavit nepujde. Jednotne, jednoduche a vykonne [a zdarma, idealne otevrene] API nativne implementovane v browserech by pomohlo v tom, ze bude jednodussi udelat browser pro nove platformy s podporou temer vseho co by bylo na webu k nalezeni. Ruzne pluginy zpusobuji ze treba platforma bez flash playeru ma aktualne velky problem a spousta "internetu" pak "nefunguje".

Jestli to chapu tady z reakci spravne, tak SVG umi manipulovat s tim co se vykresluje v HTML jinym zpusobem? (ja SVG nikdy nestudoval, bral jsem to jako vektorovy graficky format) Neni to uplne stejna dira jako canvas?
Pozor, ted se ptam jako laik ktery o dane problematice nic konkretniho nevi, takze se omlouvam jestli je to uplne spatne, ale ma naivni predstava je, ze k cemu ma pristup originalni DOM, k tomu ma pristup i js z daneho DOMu, ne? T.j. kdyz neco zobrazuje nejaky tajny obrazek, tak by to IMHO melo jit v jscriptu dane stranky nacist jako soubor byte po bytu a odeslat si to na vlastni server pres nejaky ajax dotaz. Takze bezpecnost takoveho obrazku je tak velka, jak tezke je vlozit takovy zakerny jscript do dane stranky. Prijde mi to stejne jako problem s tim ze canvas vidi veci z daneho DOMu taky, ten taky by vysledny obrazek odeslal jenom tam, kam ho jscript zamiri, ne?

Jirka Kosek

V mládí jsem si taky hrál s grafikou v assembleru (C=64 a x86), ale canvas je běží v prohlížeči a tam je celá grafika a manipulace s objekty pojata na mnohem vyšší úrovni.

ad 1) Pro různé operace s již existujícím obsahem stránky — ořezávání, posuny, aplikace filtrů apod. je mnohem elegantnější využití schopností SVG. Je to jednodušší pro vývojáře — pracuje na mnohem vyšší úrovni a prohlížeč to může dělat rychle, protože implementace SVG animací a filtrů může být velice těsně navázána na akcelerovaný grafický sub-systém OS.

ad 3a) Pokud chcete animovat/posouvat text, tak je přece nejjednodušší opět použít SVG animace anebo měnit pozici obyčejného textu pomocí CSS a JS časovače.

Canvas je takové rychlé a jednoduché řešení pro jednoduchou grafiku na stránkách — grafy, mapy, protože prohlížeče nenabízejí pořádnou podporu pro SVG. To, že někdo v 2D canvasu píše 3D aplikace je jeho problém, na to canvas nebyl navržen. (Ale on Javascript taky nebyl úplně navržen na to, co se v něm teď píše ;-)

Ken Vas

Canvas mne nejak nebere.

K cemu ma slouzit ?

Ma to byt dalsi moznost pro tvorbu aplikaci na OS nezavisle aplikacni platformy ?
To je hodne nerealna predstava, asi jako plnohodnotne aplikace pres prohlizec poustene v Java nebo Flash.

Jedine uplatneni vidim mozna v grafech nebo reklamnich bannerech, s tim, ze neni potreba dalsi plugin.
Nebo si nekdo mysli, ze js je programovaci jazyk nove generace, v kterem se budou psat treba i ty hry ? (ten Wolfstein pro Canvas je nesmysl nejvetsi).

Na ten humbuk, ktery kolem canvasu je, dost slabota.
Nebo se mylim ?

BFU

Tak a šup zpátky na Roota.

norwi

Mýlim se nebo Canvas není pro explorer, píše mi to ho to nepodporuje

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.