Az emu képét jobban megnézve, olyan mint az ep128emu-ban a 2-es image quality, kissé "elmosódott". Ott leveszem 0-ra a jobb teljesítményért, akkor pengeélesek lesznek a pixelek.
A JSEP esetében nem történik valami subpixel rendering? Mert olyasmit emlegettek némelyek, hogy akkor lassabb lesz a megjelenítés a canvas-on, vagy mi...
Okos megfigyeles, 5 pont. Konkretan megint kiseloadas jon, hogy mirol is van itt szo
Mint par epizoddal ezelott a folytatasos kisregenyemben kifejtettem
tobb okbol sem tud interlaced-et az JSEP. Ennek egyik oka, hogy nem ertem annyira pontosan en se feltetlen
a masik viszont duplan is performancia szempontjabol: feltetelezem, hogy a ket half frame ugyanaz, tehat eleg 25Hz-enkent frissiteni (innen jon a kijelzesben az xx/40 a timeoutnal, msec-ben, ami altalaban 39, de ez kerekitesi dolog, most ne menjunk bele). Igy, nem eleg, hogy fele olyan surrun, de fele annyi adatot is kell frissiteni, gondolom ebbol erezheto, hogy azert lassabb lenne egy preciz emulacio. Ha megnezed az jsep debug ablakat (ami pirosas szinre valt futas kozben, ha van meg uj debug uzenet kozben):
Canvas native size is 736x256, display size is 736x512
Na itt van a kutya elasva. Az emulator szempontjabol az emulalt frame buffer fele akkora, mint ahogy kijelzo a browser. Ezt egyszeruen meg lehet oldani, ui a browsernek meg lehet mondani, hogy mas dimenzioban jelenitse meg, mint amekkora a valodi merete. Ennek ertelmet mar fentebb boncolgattam: jolval gyorsabb, mintha JS-bol kene csinalni. Ilyen esetben a browser szepen scale-eli a dolgot, viszont van egy mellehatasa: o mindenkeppen ilyen smoothing/miegymas algoritmussal meretezi at. Hozzateszem, meg igy is gyorsabb (!), mintha JS-bol mindenfele simitas, csicsa, subpixel izebize antialis nelkul duplan raknam ki, mert browserben ez jol van optimakolva, es/vagy akar GPU-t hardware-esen is hasznalja a sajat muveleteihez.
Szoval igen, valoban el van kenve kisse, de ezt nem az JSEP hanem a browser csinalja. Ez persze felfoghato pozitivnak is (a tul eles pixelek kevesbe retro feelinget keltoek), attol fugg, honnan nezzuk. Amugy a debug dolgokat tovabb nezve, lathatsz vmi hasonlot is:
Canvas smoothing parameter with imageSmoothingEnabled is not supported
Canvas smoothing parameter with mozImageSmoothingEnabled is tried to be altered from true to false
Canvas smoothing parameter with mozImageSmoothingEnabled has been tried to be altered to false
Canvas smoothing parameter with webkitImageSmoothingEnabled is not supported
Canvas smoothing parameter with msImageSmoothingEnabled is not supported
Canvas smoothing parameter with oImageSmoothingEnabled is not supported
No, itt en konkretan azt probalom, hogy kikapcsolni ezt a feature-t, erre minden browsernek van valami sajat modszere (mivel ez nem teljesen szabvany dolog, elvileg ez a browser maganugye, kevesbe lehet kapcsolgatni), ami vagy mukodik vagy nem
Kikapcsolni azert akarom, mert erzesem szerint az gyorsit valamennyit, hogy a browsernek nem kell antialiasolni meg izelgetnie csak siman x2 vertikalis zoom-al kirakni a kepet.
Vallalkozo szellemueknek kiserlet! Allitsuk meg az emut (vagy meg el se legyen inditva run-nal) es kerjunk egy javascript console-ot (firefoxon: ctrl shift k), majd a leges legalso sorba ahova lehet gepelni irjuk be ezt, enterezve persze a vegen:
canvas.style.height = canvas.height.toString() + "px";
Ekkor az fog tortenni, hogy a canvas kijelzett es fizikai merete ugyanaz lesz. Poenbol most lehet a run gombbal inditani az emut. Valojaban az JSEP emulacios szinten pont igy latja, az csak egy trukk, hogy dupla fuggoleges meretben rakom ki
Igy viszont talan nincs is semmi rendereles, es talan gyorsabb is az emu emiatt is, meg persze amiatt is hogy a videokari fele kevesebb adatot kell browsernek atvinnie.