14 komentářů k článku Vytváříme kreslicí aplikaci s HTML5 canvasem (dokončení):

  1. Ped

    Otazky...
    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.

    1. Martin HassmanAutor příspěvku

      Re: Otazky...
      neumi spolupracovat se zbytkem HTML na urovni pixelu

      Tohle se zvažovalo, ale z bezpečnostních důvodů nelze pripustit, aby canvas mohl načítat „bitmapu“ vyrenderované stránky. Má takový přístup pouze k obrázkům a navíc jen pocházejícím z téže domény. Dalsi moznosti by byly zajimave, ale ve stavajici webove architekture to nejde povolit.

      udelat canvasem v hidden div-u

      Ano, lze vytvorit neomezene mnozstvi skrytych canvasu, do nich kreslit, obsah mezi nimi kopirovat, stridave je zobrazovat atd.

      zakladni pro manipulaci v ramci samotneho canvasu

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

      malovani z jinych obrazku

      Lze pracovat s obrazky pochazejicimi z teze domeny, na ktere se nachazi stranka s cavasem.

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

      Omezeny vzhledem k cemu? Vzhledem k tomu, co se dnes s canvasem dela, mam pocit, ze jeho stavajici moznosti jsou vicemene dostatecne. Ze by slo pridat a jit mnohem dal, o tom zadna (a urcite se bude casem dal rozvijet), ale vzhledem k tomu, jakou funkcionalitu potrebuji vyvojari na webu, bych to nevidel nijak tragicky.

      1. Ped

        Re: Otazky...
        "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.

      2. Rado2

        Re: Otazky...
        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?

        1. Martin HassmanAutor příspěvku

          Re: Otazky...
          Protože ve vykreslené stránce jsou i informace, ke kterým takový JavaScript přístup nemá, což by ve výsledku skýtalo řadu možností. Napovím např. vykrádání dokumentů (obrázků) z firemního intranetu jejich screenshotováním, pokud firemní uživatel, který má do intranetu přístup, navštíví zákeřnou stránku. Používání počítačů návštěvníků jako robofarmu pro lámání captch nějakého serveru… A našli bychom i další možnosti.

          1. Rado2

            Re: Otazky...
            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.

            1. Martin HassmanAutor příspěvku

              Re: Otazky...
              To je jediné čo by cez canvas videl navyše

              To jen v pripade, ze by bylo zajisteno, aby se do jeho screenshotu nedostal zadny pixel, ktery nema (treba pixel z obsahu intranetove stranky v iframu, ke ktere JavaScript normalne nema pristup), coz by v pripade, kdy bude stranka poskladana z rady iframu (ty muzou byt navic jeste polopruhledne, ruzne pootocene a deformovane pomoci SVG atd.) znamenalo pri screenshotovani canvasem kazdy pixel velmi peclive zvazovat. Tahle uloha by pravdepodobne reseni mela, ale byl by to raj na bezpecnostni chyby v prohlizecich, bezpecna implementace by vubec nebyla snadna a rozhodne by se hned tak nepovedla.

              Mezi dalsi dokumenty, ktery by prohlizec videl, jsou treba obrazky, ty muzou byt cenne samy o sobe nebo proste nest informacni hodnotu (grafy, interni fotografie atd.). Presnou URL utocnik vzdy nemusi znat, muze zkouset genericke URL z ruznych CMS, vyuzit pri tom navic CSS exploitu (historie adres v uzivatelove prohlizeci). Takove obrazky muze prohlizec z intranetu nacist uz dnes, ale vzhledem k tomu, ze se nedostane k jejich obsahu, to neni az takovy problem. Pri screenshotovani by to byla dalsi vec, ktere by se muselo predejit.

              napokon neviem či to vôbec webbrowsery povoľujú, vkladať do dokumentov na internetových doménach obsah z intranetu.

              Ony to muzou povolit, protoze prohlizec nemusi mit vzdy vubec paru, co je internetova a co intranetova zona.

              A to se stale divame na tenhle problem izolovane, kdyz bychom si ho zkombinovali se stavajicimi bezpecnostnimi problemy, kdo vi, jake moznosti bychom jeste objevili. Obecne by se implementaci screenshotovani canvasem vytvorilo velmi rizikove misto, coz je ted asi to posledni, co web potrebuje a nedivim se, ze to bylo zamitnuto.

              1. Ped

                Re: Otazky...
                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?

                1. Martin HassmanAutor příspěvku

                  Re: Otazky...
                  Co treba specialni atribut pro vsechny html znacky ktere canvas ma vide

                  Takhle bezpečnost na webu nefunguje, takový atribut by neznamenal žádnou ochranu navíc, stále jej může do stránky vložit tentýž skript, který provádí screenshotování. Ve zbytku komentáře jsme se bohužel rychle ztratil.

    2. Jirka Kosek

      Re: Otazky...
      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 ;-)

  2. Ken Vas

    Canvas mne nebere
    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 ?

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=2998