Devel.cz Lupa Měšec Podnikatel Root Zdroják.cz DigiZone Slunečnice Vitalia TopDrive KupDnes Navrcholu NovýTarif Dobrý web Weblogy Woko Jagg Computer.cz SK: MojeLinky

Hlavní navigace

Názor k článku
Vytváříme kreslicí aplikaci s HTML5 canvasem (dokončení)

Peter Helcmanovsky aura:80
30. 4. 2009 10:53 Nový

Otazky...

celé vlákno
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 500x500 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.