Új hozzászólás Aktív témák

• #15298 WonderCSabo félisten dqdb #15296

  Új Válasz 2010-12-06 23:13:35 #15298

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WonderCSabo

  félisten

  válasz dqdb #15296 üzenetére

  A Jaegermonkey ezen semmit se segít. Egyrészt mert ki is van kapcsolva a chrome-ra... Másrészt a JS team tesztelte, és a JM nem volt gyorsabb a chrome-on a TM-nél. Persze a TM Fx4-es változata magában gyorsabb az Fx3.x-nál, szóval vmennyire igazad van.

  Természetsen egyetértek, az Fx4 gyorsabb, reszponzívabb, az egész UX sokkal jobb mint az Fx3.x-nél. De sajnos az előbb említett okok miatt szörnyeb be tud lassulni. Egy pl.:

  - töltesz egy odlalt
  - közben megnyitsz egy új fület
  - az animációja szaggatni fog, mivel a JS motort lefoglalja az oldal betöltésekor futó szrkiptek

  Ezt pl. chrome-content processz szeparációval totál lehetne oldani. És meg is fogják, de az Electrolysison való munka csak egy pár napja kezdődött el...

  Persze, h. marha jó dolog a XUL, talán a legjobb dolog az Fx-ben, de sajnos ez a nagy hátulütője van.

  Azon csodálkozom, hogy eddig nem írtak XUL → natív kód közötti fordítót (vagy csak nem tudok róla).

  Tudtommal nem, bár hirtelen nem is tudom elképzelni, hogyan működne úgy (bár a JS fordítókat se tudtam ezelőtt...)

  A Jetpack alapú bővítmények minél gyorsabb elterjedése azért lenne jó, mert eléggé nagy tehermentesítést jelentene, ha eddigi script alapú közvetítő rétegek helyett az addonok közvetlenül natív kóddal kommunikálnának.

  ööö, milyen natív kód?

  xabolcs: Nem, egyáltalán nem tévedsz, a jetpack nem tud mélyebben belenyúlni az Fx-be, egy picit kibővített userJS-ek ezek, a lényeg itt az egyszerű írhatóságon van.

Új hozzászólás Aktív témák