HTML5 Canvas UI
2011-08-18T10:50:48+02:00
2011-08-19T00:15:41+02:00
2022-07-19T04:37:35+02:00
  • ok, igazad van
    Mutasd a teljes hozzászólást!
  • Látom nem érted.
    1. A téglalapokat nem kell sem elforgatni, sem eltoltni. Ezek mindig a pixeltér két tengelyével párhuzamosan helyezkednek el. Ez a lényegük, ezért lehet őket pl. a kirajzolás esetén is egyszerűen maszkolásra vagy a kirajzolási pufferből a látható részeknek megfelelő területek másolására használni.
    2. Ha animálsz, akkor sem kell eltolni és elforgatni téglalapokat, mert elemi geometrikai - ill. utóbbiak sokaságából - felépített alakzatokon belül ugyanúgy pár elemi számítás annak megállapítása, hogy egy pont benne van -e az adott alakzatban, vagy sem, mint téglalap esetén; és százszor gyorsabb, mint maga az alakzat kirajzoltatása, akkor is, ha ahhoz OpenGL-t vagy akármilyen hardveres gyorsítást használsz
    3. Főleg, hogy a te módszereddel még mindig, minden esetben ki kell rajzolni az összes vezérlőt (akkor is ha legnagyobb részük nem látszik, mert teljesen takarásban van ugye), míg a téglalapos módszernél a fa célzott bejárásaval a bináris keresés log2(n)-jéhez közelítő, töredék számú lépésből megtalálható az egy adott pont mögött látható vezérlő. (Az, hogy ténylegesen mennyire van közel előbbihez a lépésszám attól függ, hogy mennyire egyenletes a fa eloszlása ill. hogy mennyire töltik ki a befoglaló téglalapokat a gyerek-vezérlők)
    4. Ha a hit-vizsgálatra még esetleg elfogadható teljesítményt is nyújtana a módszered - a kirajzoláshoz ezt akkor nem használhatnánk fel, mert oda marha lassú, ha pixelenként kellene megállapítanunk, hogy melyik vezérlő is rajzolandó ki; tehát legkésőbb ott úgyis szükségünk lesz a téglalapokra - akkor meg minek elbonyolítani a rendundás, erőforráspazarló és memóriazabáló színezős módszerrel az egész dolgot?
    +1. Az alkalmazások 99%-ában a vezérlők 99%-a nem animált (forgatott, torzított) és vagy téglalap vagy ahhoz nagyon közelítő (pl. lekerekített téglalap) alakú, ami azt jelenti, hogy nagyon kevés téglalapból ábrázolhatók az egyes vezérlők ill. a köztük lévő tér maszkjai.
    Mutasd a teljes hozzászólást!
  • ekkor a több száz téglalap elforgatás (sin, cos műveletek), eltolás, skálázás már elég proci igényes lehet mobilon, javascriptben (főleg, ha nincs lebegőpontos egység a prociban), főleg, hogy elforgatott téglalapon már nem csak négy egész összehasonlítást kell végezni a tartalmazás vizsgálathoz

    ehelyett az én naív, buta (nem irónia, én is tudom, hogy az) megoldásom jófajta Canvas implementációval elforgat, eltol, skáláz egy négyzetet, textúrának beállítja a bitmapet, a négyzetet kirajzolja egy bufferbe, a blending egység pedig végzi a dolgát, majd egy pixel színét kell kiolvasni
    Mutasd a teljes hozzászólást!
  • egy vezérlő nem csak téglalap alakú lehet, nagyon szabálytalan objektumról volt szó

    Pixeltérben minden szabálytalan objektum leírható, lefedhető véges számú téglalappal.

    , továbbá én nem akarom kirajzolni téglalaponként, hanem az egészet egyben, mert az gyorsan megy a GPU-nak.

    De nem megy gyorsabban annál, mint amilyen gyorsan a befoglalásvizsgálat megy a téglalapokkal.

    ennek fényében a következő részednek nincs értelme, mivel általános esetet (szabálytalan objektum) nézünk.

    Tévedsz. Lásd fent!
    Mutasd a teljes hozzászólást!
  • tudjon ám view frustum cullingot is a cucc :)
    Mutasd a teljes hozzászólást!
  • Valóban ezt mindenképpen érdemes beletenni.
    (Nagyon nagy mennyiségű gyerek esetére meg már szóbajöhet valami térfelosztó hierarchia, vagy esetleg a szülőkomponens specifikus szűkítőkód (pl. egy nagyon sok elemű tábla kompoens a koordináta alapján egy pillanat alatt vissza tudja adni csak az adott sorban lévő komponenseket, erősen leszűkítve a gyerekeket. De ilyen szintű optimalizáció már csak majd a projekt későbbi fázisában lesz implementálva szvsz.) )
    Mutasd a teljes hozzászólást!
  • De, tuti gyorsabb lesz, azon egyszerű oknál fogva, hogy egy koordináta-befoglalási vizsgálat eleve mindösszesen csak négy egész-összehasonlítás (<20 órajelciklus) vezérlőnként, ami össze nem hasonlítható egy téglalap kirajzolásával; ráadásul a progresszív bejárás révén ezt az összehasonlítást is csak a minimálisan szükséges vezérlőszámra kell végrehajtani, nem az összesre, mint a kirajzolásos módszer esetében, ami szintén igen sok számítási kapacitást spórol meg.

    egy vezérlő nem csak téglalap alakú lehet, nagyon szabálytalan objektumról volt szó, továbbá én nem akarom kirajzolni téglalaponként, hanem az egészet egyben, mert az gyorsan megy a GPU-nak.

    ennek fényében a következő részednek nincs értelme, mivel általános esetet (szabálytalan objektum) nézünk.

    De mondom, hogy nem érsz el semmilyen OpenGL funkciót, hiába "rejtőzik az a canvas-ra rajzoló metódusok mögött". Böngészőből, JavaScript-ből, Canvas-on keresztül egyszerűen azokat nem éred el és kész.

    tuudom, és nem is írtam sehol....
    de ha az ember tudja, hogy mit csinál az implementáció a rajzoláskor a böngészőben (az összes böngésző a Canvasra rajzoláshoz OpenGL/DirectX-et fog használni), és lehet bufferbe rajzolni, akkor az a hasznára válhat...

    lényeg a lényeg, alapesetben persze, hogy sokkal sokkal gyorsabb a téglalapos módszer, de ha az alábbi együtt állások teljesülnek, akkor az általam említett módszer lesz a gyorsabb:
    - a canvas metódushívásai OpenGL hívásokban végződnek
    - és nem sok az overhead az OpenGL hívásig
    (tehát jól van megírva a böngésző GPU gyorsítása)
    - továbbá a téglalapos módszerrel több száz téglalappal közelíthető csak az objektum, poligonnal pedig nem jól (mert mondjuk egy bitmap mask jelöli ki az objektumot)
    - ezt az objektumot animáció során elforgatjuk, skálázzuk, eltoljuk

    ekkor a több száz téglalap elforgatás (sin, cos műveletek), eltolás, skálázás már elég proci igényes lehet mobilon, javascriptben (főleg, ha nincs lebegőpontos egység a prociban), főleg, hogy elforgatott téglalapon már nem csak négy egész összehasonlítást kell végezni a tartalmazás vizsgálathoz

    ehelyett az én naív, buta (nem irónia, én is tudom, hogy az) megoldásom jófajta Canvas implementációval elforgat, eltol, skáláz egy négyzetet, textúrának beállítja a bitmapet, a négyzetet kirajzolja egy bufferbe, a blending egység pedig végzi a dolgát, majd egy pixel színét kell kiolvasni

    zárjuk le a témát ott, hogy igen, igazad van, eltekintve néhány ritkán előforduló esettől, mindig a téglalapos/poligonos megoldás a nyerő.

    // OFF:
    érdekesség:
    C kód arra, hogy egy pont benne van-e egy poligonban:

    int pnpoly(int nvert, float *vertx, float *verty, float testx, float testy)
    {
    int i, j, c = 0;
    for (i = 0, j = nvert-1; i < nvert; j = i++) {
    if ( ((verty>testy) != (verty[j]>testy)) &&
    (testx < (vertx[j]-vertx
    ) * (testy-verty) / (verty[j]-verty) + vertx) )
    c = !c;
    }
    return c;
    }
    Mutasd a teljes hozzászólást!
  • Szia,

    Igen, az animációt majd támogatni kell (jelenleg még nincs rá támogatás). Úgy terveztem, hogy majd lopok ötleteket animáció terén olyan rendszerekből, amik támogatják (mint pl. a JQueryben láttam először 'easing' függvényeket kontrollok mozgatásánál, biztos máshol is vannak).
    Mutasd a teljes hozzászólást!
  • A fa minden egyes szintjén, csomópontján érdemes a befoglaló téglalapot (tehát azt a legkisebb téglalapot, amiben az összes gyerek-vezérlő elfér) kiszámítani és gyorstárazni, mert ez igen kevés számítási kapacitást igényel (gyakorlatilag csak két minimum és maximumkiválasztás, amelyek mindegyike azonban egyetlen közös menetben megállapítható), a vizsgálatokhoz, keresésekhez képest rendkívül ritkán történik, viszont rendkívül sok időt spórol utóbbiakban, mert töredékére csökkenti az elvégzendő vizsgálatok számát.

    Pl. gondolj bele, hogy ha a felhasználó a háttér (a z-sorrendben legutolsó elem) egy sarkára kattint, akkor a te jelenlegi algoritmusod a teljes vezérlőfát kénytelen bejárni mire eljut a háttérig. Ugyanakkor ha a befoglaló koordináták tárolva vannak a fa minden szintjén és először azokat vizsgálod (és csak ha abba beleesik a pont, akkor mész lefelé tovább a fában), akkor adott esetben csak a fa legelső szintjén kell végigmennie a keresésnek ahhoz, hogy kiderüljön, hogy a felhasználó a háttérre kattintott.
    Mutasd a teljes hozzászólást!
  • Igen, ezt így csinálom jelenleg, itt a kódja:


    // The parameters 'x' and 'y' are relative to this component's upper left corner. // Returns null if the ray did not hit any component. // Otherwise returns the component which is the deepest component in the stack of the closest (biggest w,z) hit. CCUI.Component.prototype.castRay = function (x, y) { // first put those children which can possibly be hit into the array 'canBeHit'. var length = this._children.length, i, child, canBeHit = []; for(i=0; i<length; i++) { child = this._children[i]; if(child.isPointInside(x,y)) { canBeHit.push(child); } } // sort them by w-z this._zSortComponents(canBeHit); // go through canBeHit from top to bottom (reverse order). length = canBeHit.length; var isPositive = true, c, ret; for(i=length-1; i>=0; i--) { c = canBeHit[i]; if(isPositive && (c.w < 0 || (c.w === 0 && c.z <= 0))) { isPositive = false; if(this.doesHit(x,y)) { return this; } } ret = c.castRay(x - c.x, y - c.y); if(ret) { return ret; } } if(isPositive) { if(this.doesHit(x,y)) { return this; } } return null; }

    Amiatt bonyolultabb picit a fenti kód mint elsőre várná az ember, hogy egy komponens gyerekeit z(,w) orderben vizsgálom, de 0-ánál a komponenst magát is meg kell néznem. (A gyerkek z-je a szülőjükhöz rendszerében van értve, a szülő rendszerében a szülő (vagyis amit a szülő paint()-je rajzol) mindíg a 0-ánál van, ez axióma a rendszeremben.) A komponens 'doesHit' metódusa van megvizsgálva 0-ánál: a doesHit alapban mindig true-t ad vissza, vagyis teljeskitöltésű téglalapnak vesszük a komponenst, de a doesHit felüldefiniálható, így részleges áttetszőségeket lehet csinálni, pl. ahogy csinálok is lekerekített sarkoknál.
    (Ez a cucc max. másodpercenként pártucatszor hívódik, így sebességigénye nem igazán kritikus, de amúgy mindent már eleve (algoritmikusan) eléggé optimálisan kódolok és majd komolyabb profiling után a legkritikusabb dolgokra különösen rámászok.)

    Más: említetted, hogy szívás, hogy kódból csinálom a clippinget. Annyiból nem olyan nagy szívás, hogy a clipping region-t a canvas API-ban lehet állítani, vagyis a clippinget a böngésző natív kódja csinálja.
    Mutasd a teljes hozzászólást!
  • a nagyon szabálytalan (konkáv) objektumokra rátérve pedig az elemi téglalapos módszer nem biztos, hogy minden esetben gyorsabb lesz

    De, tuti gyorsabb lesz, azon egyszerű oknál fogva, hogy egy koordináta-befoglalási vizsgálat eleve mindösszesen csak négy egész-összehasonlítás (max. 10-20 órajelciklus) vezérlőnként, ami össze nem hasonlítható egy téglalap kirajzolásával, még akkor sem, ha az hardverből történik (és nem pixelenként); ráadásul a progresszív bejárás révén ezt az összehasonlítást is csak a minimálisan szükséges vezérlőszámra kell végrehajtani, nem az összesre, mint a kirajzolásos módszer esetében, ami szintén igen sok számítási kapacitást spórol meg.

    pl, ha animálva van az objektum, forog össze vissza, torzul, akkor hozzá kell igazítani a sok kis téglalapot is (nem jó az előre eltárolt) minden frame-ben.

    Egyrészt az animáció igen speciális eset - a legtöbb alkalmazás nem animál gyakorlatilag semmit (maximum mozgat, átméretez, de akkor is jellemzően vagy szigorúan téglalap alakú, vagy ahhoz közelítő alakú vezérlőket, amik igen kevés lefedő téglalap uniójaként leírható). Másrészt ha animálsz, akkor az általad felvetett színtérképet is éppen ugyanannyiszor kell újraképezni, mint a befoglaló téglalapok halmazát.

    A harmadik és egyben legfontosabb dolog viszont az, hogy ha egy objektum tényleg animálva van (tehát nem bitképek sorozata az animáció, amely esetben ugye nyilván egyébként se lehet mást csinálni, mint pixelenként rajzolni és vizsgálni mindent), akkor eleve poligonként vagy elemi geometriai elemek halmazaként van leírva. Ez esetben akkor nem is szükséges a lefedő téglalapokra bontás, mert egyszerű matematikai módszerekkel megvizsgálható ezen elemi geometriai objektumokon belül is a befoglalási vizsgálat a pontra. Utóbbiak - tehát egy kör, ellipszis, poligon, stb. - pont-befoglalási vizsgálatának számításigénye nyilván összevehető a téglalap esetében esedékessel.

    A téglalapos módszer a valóban "szabálytalan" felületek esetében jut szerephez, ahol mondjuk mondjuk egy bitmap képezi az átlátszósági maszkot és/vagy az adott körvonal elemi alakzatokból effektíven nem építhető fel.

    Míg az általam korábban említett bufferes megoldásom akár meg is előzheti a "sok kis téglalapot transzformáljuk el az animációnak megfelelően" megoldást, mert jó eséllyel a Canvas-t rajzoló metódusok mögött OpenGL hívások rejtőznek, és pikk pakk ki lehet egy másik bufferbe rajzolni az objektumot újra.

    De mondom, hogy nem érsz el semmilyen OpenGL funkciót, hiába "rejtőzik az a canvas-ra rajzoló metódusok mögött". Böngészőből, JavaScript-ből, Canvas-on keresztül egyszerűen azokat nem éred el és kész.
    Mutasd a teljes hozzászólást!
  • köszi a magyarázatot, ezt értem, és én is így gondolom

    a nagyon szabálytalan (konkáv) objektumokra rátérve pedig az elemi téglalapos módszer nem biztos, hogy minden esetben gyorsabb lesz:
    pl, ha animálva van az objektum, forog össze vissza, torzul, akkor hozzá kell igazítani a sok kis téglalapot is (nem jó az előre eltárolt) minden frame-ben.
    Míg az általam korábban említett bufferes megoldásom akár meg is előzheti a "sok kis téglalapot transzformáljuk el az animációnak megfelelően" megoldást, mert jó eséllyel a Canvas-t rajzoló metódusok mögött OpenGL hívások rejtőznek, és pikk pakk ki lehet egy másik bufferbe rajzolni az objektumot újra.

    még mielőtt belekötsz: tiszta sor, hogy alapesetben a te módszered sokkal gyorsabb, de itt számításba kell azt is venni, hogy a GPU nagyon gyorsan végez egy ilyen feladattal, és egy pixel színét kell csak kiolvasni
    Mutasd a teljes hozzászólást!
  • "elég a kontrolfa progresszív bejárása", ezt nem értem, pls fejtsd ki, mit értesz alatta

    Egyszerűen a vezérlőket egy olyan fában (is) nyilván kell tartani, ahol z-sorrend szerint rendezettek az egyes ágak (ez a kirajzolásnál úgyis kell), és ebben progresszív módon lefelé dolgozva meg kell találni mindig azt az újabb és újabb alágat, amelynek befoglaló téglalapján belülre esnek a kattintási koordinták - egészen addig, amíg egy levélig (vezérlőig) el nem jutunk. Ez a vezérlő lesz az, amelyikre a felhasználó kattintott. Ehhez végig mindössze csak kisebb-nagyobb vizsgálatokra van szükség a koordinátákkal (annak megállapításához, hogy egy adott téglalapon belül vannak -e).

    Ha meg akarunk engedni kattintás szempontjából részben vagy teljesen transzparens vezérlőket is (pl. overlay rétegek), akkor egyszerűen azokat ignorálni kell a vizsgálat szempontjából, és ha nem találunk megfelelő vezérlőt, akkor a keresésben visszafelé kell lépni és újabb egyezést keresni. (Lásd backtrack.)

    "Szabálytalan" (nem téglalap) alakú vezérlők esetében szintén alkalmazható a módszer, csak ott értelemszerűen a szabálytalan alakot leíró ill. felépítő elemi - diszjunkt, de potenciálisan illeszkedő - téglalapok halmazán kell a pont-befoglalási vizsgálatot elvégezni.
    Mutasd a teljes hozzászólást!
  • opengl-t példaként hoztam fel, hogy ott lehet változtatni a render targetet, és hogy ott így szokás megoldani a pickinget, még ha ki is neveted a megoldást, amely megoldás áthozható tetszőleges platformra, ha nem csak a képernyőre, hanem bufferbe is lehet rajzolni
    [látom azért neked se sikerült teljesen felfogni mit írtam]

    "elég a kontrolfa progresszív bejárása", ezt nem értem, pls fejtsd ki, mit értesz alatta

    "Bár nem erről volt szó ám..." ebben igazad van, tényleg nem olvastam végig a topicot :)
    Mutasd a teljes hozzászólást!
  • Most meg OpenGL-lel jön, miközben végig arról volt szó, hogy ez az UI a böngészőben, Canvas+JS alapokon kerül majd felépítésre (ergo, OpenGL elérése szóba se jön)...
    Mutasd a teljes hozzászólást!
  • object pickhez én is a befoglaló téglalapokat ajánlom első körben, a kattintás által metszett téglalapokhoz tartozó UI objecteket aztán ki lehet újra rajzolni Z orderben, mindegyikhez egy színt rendelve, és a koordináták által kijelölt pixel színéhez tartozó object lesz a kiválasztott.

    Jézusom... Színekkel megkeresni, hogy melyik objektum van a kattintás alatt? Valójában ehhez semmit nem kell rajzolni, hanem elég a kontrolfa z-order szerint rendezett változatának progresszív, rekurzív bejárása, és egyszerű "kisebb-nagyobb" koordinátavizsgálat.

    Újrarazoláshoz dettó nem kellenek színek, hanem egyszerűen scanline segítségével megállapítható az a minimális számú diszjukt téglalap, ami leírja az újrarajzolandó területet. (Ezeket aztán érdemes az őket metsző vezérlők halmazának megállapításához felhasználni - mert a többi vezérlővel felesleges foglalkozni, mert úgysem lesz újrarajzolandó pixelük -, és csak azokat egy átmeneti pufferbe kirajzoltatni, majd onnan az előbbi téglalaplista felhasználásával az újrarajzolandó területek tartalmát a célfelületre kimásoltatni. Másik - lassabb, de memóriatakarékosabb - lehetőség minden egyes téglalalpra a benne látható vezérlők kirajzoltatását újból és újból végrehajtani úgy, hogy a téglalapot vágási határokként értelmezzük; így közvetlenül a célfelületre, vagy egy korlátozott méretű átmeneti pufferbe lehet rajzolni.)

    Bár nem is erről volt szó ám, hanem arról, hogy az UI-n belül definiált és az azon kívül, a DOM-ban létező objektumokat is tudni kellene z-helyesen rendezni ill. kirajzolni, azon egyszerű oknál fogva, hogy pl. videólejátszást, külső weblap befűzését, stb. nem fogja tudni megoldani a canvason belül.

    De te még ezt se értetted meg. Ami persze nem akadályozott meg benne, hogy tiszta erőből osztsd az észt.
    Mutasd a teljes hozzászólást!
  • "kattintás által metszett téglalapokhoz tartozó UI objecteket aztán ki lehet újra rajzolni Z orderben, mindegyikhez egy színt rendelve", azt kifelejtettem, hogy mindezt ne a képernyőbufferbe, hanem egy másikba (OpenGL alatt lehet változtatni a render targetet pl)

    Sting: ez van válasz helyett?
    (nekem is ki kellett próbálnom a gagyi smileykat :)
    Mutasd a teljes hozzászólást!
  • "GetCursor csak pollozásra jó" -> Sting! Ha fele annyi időt töltöttél volna azzal, hogy átgondold, hogy érdemes megcsinálni, mint amennyit a kommentbeli hülyeséget írtad, akkor a komment írásának másik felét megspóroltad volna.

    Összeroppantam érveid súlya alatt...
    Mutasd a teljes hozzászólást!
  • object pickhez én is a befoglaló téglalapokat ajánlom első körben, a kattintás által metszett téglalapokhoz tartozó UI objecteket aztán ki lehet újra rajzolni Z orderben, mindegyikhez egy színt rendelve, és a koordináták által kijelölt pixel színéhez tartozó object lesz a kiválasztott. 8 réteg esetén a szín 3 bit, tehát mindjárt nem 1920x1080x32, tizede, jó esetben kisebb az újra kirajzolandó régió is.

    Másik megoldás (ezt nem gondoltam át, lehet, hogy bugos): nem csak befoglaló, hanem a legnagyobb beírható téglalapot is lehet használni, ekkor ha a kattintás a legfölső ilyenben történt, akkor mást nem is kell vizsgálni
    Mutasd a teljes hozzászólást!
  • Üzleti alkalmazásokra egy alap komponenskönyvtár tökéletesen megfelel, aki videózva akar hupákolni az ne ezzel a könyvtárral akarja megtenni hanem menjen el a youtube-ra oszt ott hupákoljon. Én nem látom azt az apokalipszist amit felvázoltál, de majd nadhamhu megmondja hogy mit tapasztal sebesség terén.
    Mutasd a teljes hozzászólást!
  • Szia,

    Ne foglalkozz Sting kommentjeivel, árad belőlük a visszahúzó erő. Ahelyett, hogy a negatív kommentjeire felelsz, inkább fejleszd a cuccot, mert szerintem több órád ment már a fórumban a vele való harcra.

    "GetCursor csak pollozásra jó" -> Sting! Ha fele annyi időt töltöttél volna azzal, hogy átgondold, hogy érdemes megcsinálni, mint amennyit a kommentbeli hülyeséget írtad, akkor a komment írásának másik felét megspóroltad volna. Hagyjad, had fejlessze a cuccot.

    Mellesleg én is fejlesztek egy nagyon alap, gagyi GUI-t OpenGL ES-re, végzős egyetemistaként eszembe nem jutott volna pollozni, szal Sting jobb ha nem csillogtatod a több éves fejlesztői tapasztalatod gagyi kommentekben.

    // más: animáció támogatást mindenképp építs be
    nálam így van: az UI objectek meghívják a hozzájuk beállított animator objektumot az animate függvényükben, amit az engine hív
    Mutasd a teljes hozzászólást!
  • Viccelsz? Még 1920x1080-as felbontásban, teljesképernyős megjelenítésben és 24 bites színmélység + 8-bit alpha mellett is csak 8MB egy réteg tárolásához szükséges memória mennyisége akkor is, ha minden pixelnek fixen megvan a fenntarott helye (akkor is, ha a ténylegesen látható pixelek befoglaló téglalapja csak töredéke a teljes felületnek). Ez ugye egy mai asztali gépen gyakorlatilag nullának tekinthető.

    Ettől persze még zabálhat száz gigát is egyetlen réteg egy böngészőben ha az ótvarul van megírva, de én akkor is azt mondom, hogy az már eleve jelentősen fog lassítani a kirajzoláson ha a clippingre is figyelned kell, az egyes elemek mozgatása az UI-n belül meg kifejezetten lassú és ronda lesz. Ami sokkal inkább fog zavarni bárkit, mint az, hogy 300 mega helyett 350-et vagy 400-at fog enni a böngészője.
    Mutasd a teljes hozzászólást!
  • Ugyanakkor ahogy írtam én nem javasolnám, hogy te legyél okosabb a böngésző helyett és mesterségesen redukált a rétegek számá

    Meg kell vizsgálnom, hogy mekkora a költsége a böngészőben egy (adott esetben nagyrészt amúgy átlátszó) canvas memóriában tartásának. Ha pl. nincs különösen nagy költsége (pl. nem hoz nekik létre canvasméretű, minden pixelt tartalmazó memóribuffert), akkor semmi értelme redukálnom a rétegek számát, és n+1 canvassal kell dolgoznom. Remélhetőleg ez a helyzet. Ha nagy a memóriaköltség, akkor érdemes lehet redukálni a számukat. Meg kell néznem.
    Mutasd a teljes hozzászólást!
  • Mivel mindegyik videó ill. DOM-szintű beágyazott elem (pl. videó) előtt és mögött is lehet nem DOM-szintű (csak a GUI-don belül definiált és létező) elemed, ezért n darab DOM-szintű beágyazott elem esetében n*2+1 az a minimális rétegszám amiből biztosan megoldható az ábrázolás (ebből ugye n darab lesz a DOM-szintű elemek rétegeinek száma, és n+1 a canvas elemek száma). Persze ha az egyes elemek DOM-szintű között nincsenek nem DOM-elemek vagy azok egy szinten vannak egymással, akkor akár n+1 réteg is elég lehet, de a lényeg, hogy n*2+1 az a minimális rétegszám amire biztosan minden eset helyesen leképezhető.

    Ugyanakkor ahogy írtam én nem javasolnám, hogy te legyél okosabb a böngésző helyett és mesterségesen redukáld a rétegek számát a minimálisan szükségesre (az egymást vagy egyáltalán nem, vagy teljesen fedők összevonásával), mert ezzel csak azt éred el, hogy a te JS-ben írt és így lassú kódodnak több munkája legyen (pl. figyelned kell majd a rajzolóműveletek vágására (clipping), és a vezérlők mozgatásánál neked kell másolnod és újrarajzolnod a régiókat, megint csak a vágásokat is figyelembe véve), miközben a hardveresen gyorsított böngészőtől még azt a lehetőséget is elveszed, hogy legalább ezen a téren besegítsen neked (pl. a vágás és a mozgatás terén).

    Szóval én a helyedben minimum ablakonként/panelenként külön canvas-t nyitnék és kezelnék a rajzoláshoz.
    Mutasd a teljes hozzászólást!
  • Megtisztelő, hogy elvárod tőlem, hogy mindenre gondoljak előre, pl. embedded cuccok parciális kitakarására is egy olyan cuccnál, aminél abszolút nincs az embedding a középpontban. Triviális problémák átgondolását tudom garantálni, de mindenféle subtle kis dolog jóval előre való átgondolásának attól tartok azért vannak bizonyos korlátai az esetemben.
    Ha mindenki olyan precízen átgondolna mindent mint te, akkor nem csak minden 10-edik startup futna be, hanem mindegyik, és persze nem mantráznák annyira az iterálás szót sem, agilis módszertanok sem léteznének, stb... Mindenki csak megtervezne dolgokat, majd megvalósítaná őket, és kész is! Milyen szép is volna.
    Mutasd a teljes hozzászólást!
  • De azért remélem érted, hogy ezeket a dolgokat azelőtt kellett volna végiggondolni, hogy egyetlen sort is leírsz - nem ám, hogy akkor, amikor már "a Buttonnak pl. van vagy egytucat propertyje"...
    Mutasd a teljes hozzászólást!
  • Valóban nyithatok több canvast, amelyekhez a domban különféle z értéket rendelek. Lehet minden canvas egy helyen egy méretben, csak a felső canvasok nagyrésze átlátszó lenne. Sőt írhatok olyan algoritmust, ami kitalálja, hogy mennyi a legkevesebb canvas amivel adott esetben megoldható a probléma. Pl. egyetlen embedded videó esetén max 2 canvas szükséges, 'n' embedded videó esetén bonyolultabb a kérdés, de első intuícióm szerint legtöbb 'n+1' canvassal mindenképpen megoldható. Ezen gondolkodom még...
    Mutasd a teljes hozzászólást!
  • Na szóval a precizitás kedvéért:

    Az egyetlen valóban súlyos probléma eddig (legalábbis amit most gyorsan feldolgoztam és felfogtam az írásodból), amire nem látszik megoldás, az az, hogy embedded flash, java applet és videók parciális kitakarása nem fog működni. Ez egy komoly hátrány.

    Örülök, hogy felvetetted a problémát. Most az a kérdés, hogy ezzel a hátránnyal érdemes-e egy ilyen rendszert fejleszteni. Valóban nem egyéttelmű a válasz, én arra hajlok, hogy igen, ettől még fejleszteni kell ezt, de megfontolandó az ellenkező vélemény is természetesen.
    Mutasd a teljes hozzászólást!
  • Ezt csak most láttam meg. Ezek jó észrevételek. Valóban ezeket csak a canvas elé tudom tenni, vagyis, egy alkalmazás csak úgy tudja őket megjeleníteni, hogy teljesen előtérben vannak vagy eltűnnek (főleg a video érdekel, a flash és az applet annyira nem).

    Ez így nem teljesen igaz, mert pl. több canvas-t is létrehozhatsz az eredeti dokumentum DOM szintjén, amikkel pl. - legalábbis pl. iframe esetében - meg tudod valósítani a z-order-helyes részleges fedést*. Sőt, igazából lehet, hogy rétegenként, ablakonként érdemes lenne külön canvas-t nyitni, és akkor azok mozgatását is a böngészőre lehetne bízni, azon túl, hogy a z-index helyes rajzolás problémája is megoldódna, és az egéresemények kezelése is egyszerűsödne.

    *Flash embed esetén ez már nem egyértelmű, mert ott van hogy a böngésző eleve nem tartja tiszteletben a z-index-et és a Flasht mindig minden felett jeleníti meg, amely esetben ugye biztosan nem tudsz vele mit csinálni.
    Mutasd a teljes hozzászólást!
  • Flash applet, videó, iframe, stb. hogyan lesz beágyazható az UI-ba?


    Ezt csak most láttam meg. Ezek jó észrevételek. Valóban ezeket csak a canvas elé tudom tenni, vagyis, egy alkalmazás csak úgy tudja őket megjeleníteni, hogy teljesen előtérben vannak vagy eltűnnek, parciális takrás nem megy. (főleg a video érdekel, a flash és az applet annyira nem). A másik jó észrevételed az volt, hogy majd mobillal külön foglalkozni kell. Ez a 2 dolog szívás, de nem elég nagy szívás ahhoz, hogy emiatt ne lássam értelmét a rendszer fejlesztésének.
    Mutasd a teljes hozzászólást!
abcd