Ez a számláló a poszt nézettségét mutatja. Mindenképp olvasd el ezt a posztot a részletekért.

Kamera támogatás (b1372)

penge™ | 2012. április 17.

Reggel felkeltem és azt kérdeztem: Mivel lehetne még hátráltatni az életemet megkeserítő Drag and Drop bugot, ami nagyban rontja a tesztelési élményt is? Hát íme, a sokak(?) által várt kamera támogatás. Mentségére szóljon, hogy Facebookkal és a Google-val ellentétben Operáék legalább ismerik a privacy szót. Ennek eredménye lehet Badge felturbózása és egyúttal a Geolocation is bekerült.

Akit érdekel (és van webkamerája) itt vannak demók: Photo Booth, Polaroid, Color Picker, Explode and Speedo (Megjegyzés: mind kérni fog kamera hozzáférést, a Speedo a Geolocation-höz is)

És most lássuk a vizuális változásokat. Az új popup így néz ki:

Ami még változott, hogy mostantól két másik helyen is látni fogod, ha valami hozzáfér a webkamerához. Egyszer a címsorban,

A háttérben lévő füleknél pedig a fülek jobb oldalán:

Valamint arról is értesítést kapsz, ha egy oldalon inaktív ugyan, de előzetes engedélyezés miatt bármikor hozzáférhet a kamerához mindenféle jelzés nélkül. Erről a halvány kamera ikon árulkodik:

Ezekkel a legördülőkkel tudod beállítani a jogosultságokat:

Most pedig következzen a szokásos.

Ismert hibák:

  • DSK-359770 Out of Process Plugins tabokkal kapcsolatos fagyást okoz (leginkább indításkor)
  • HTML5 Drag and Drop fejlesztése folyamatban. Ami a korábbiban nem működött az most se fog. (illetve a pontos kattintáshoz mesterlövész egér vagy több éves gamer múlt kell - a szerk.)Sad Panda
  • HTML5test.com-on fagyhat és egyéb problémák léphetnek fel Mac alatt
  • Streaming esetén színproblémák Mac alatt
  • OTW-8246 A 64 bites változatot nem támogatja a Google+ (browser sniffing)
  • DSK-361109 Címsáv legördülő nem jelenik meg mikor több szót tartalmazó laptartalomra keresünk (?)

Változások listája (Core):

  • CORE-45558 Beleértve a nem-közvetlen kép dekódolást a megfelelő tabon(?) az opera:cpu sem szerepelt az Other-ben
  • CORE-45571 A beépülők zabálták a legtöbb CPU időt az Other-en belül az opera:cpu-ban
  • CORE-45480 Biztonságos lapok címe a global_history.dat-ból elveszett indításkor
  • CORE-45363 onconnect event.source.postMessage(); throws Unhandled DOMException: INVALID_STATE_ERR (ez nyírta ki a HyperTranslate-et és a HotkeyBB-t is)
  • CORE-45475 dojo http://dojotoolkit.org/ AMD loader - WRONG_THIS_ERR
  • CORE-45631 "visibility: hidden" dobozok átlátszósággal zabálták a CPU/GPU időt az átlátszóság miatt
  • CORE-43147 Box-shadow with offset and negative spread radius hatással volt a görgetési teljesítményre

Változások listája (Desktop):

  • DSK-355083 Új privacy menedzser UI a kamerához és a Geolocation-höz
  • DSK-359155 Dragonfly bezáródott a popuppal/tabbal együtt
  • DSK-358039 Tab Stack skinnél hiányzott 1 pixel felülről
  • DSK-333648 A lokalizált kiegészítők mappájában nem talált ikont
  • DSK-322573 Ctrl+Backspace csak a per-t távolította el az URL-ből, nem a hozzá tartozó útvonalat
  • DSK-359210 Az Extender menü nem volt hozzáférhető, ha a fülsáv oldalra volt helyezve (reméljük második nekifutásra restart után is marad)
  • DSK-355586 Zoom fokozat indításkor az állapotsávon
  • DSK-352303 Crash e-mail fiók készítésekor
  • DSK-331761 Könyvjelzőkkel kapcsolatos összeomlás indításkor
  • DSK-361101 Crash a fájl kiválasztás dialógusban Windows alatt
  • DSK-359159 Manage Links fül (Ctrl + Shift + L vagy Ctrl+Alt+L a régi kiosztásnál) üres
  • DSK-360628 Összeomlás az Add Mail dialógus bezárásakor
  • DSK-358485 Szöveg kihúzása egy szövegdobozból, majd vissza a szöveg eltűnését okozta
  • DSK-358486 Mikor egy szövegdoboz körül húztunk szöveget, nem jelölte semmi
  • DSK-359461 META description header nem került hozzáadásra, mikor a Jegyzetekbe húztunk
  • További összeomlás javítások

Változások listája (Windows):

  • DSK-358448 Runtime error 6025 pure virtual function call indításkor
  • DSK-359678 Összeomlás, mikor egy fület kihúztunk az ablakból, hogy újat hozzunk létre
  • DSK-360081 Összeomlás könyvjelzők átrendezésekor
  • DSK-359762 Külső programokból nyitott linkek privát fülön nyíltak meg, mikor egy privát fül volt fókuszban
  • DSK-357221 [HWA] Nem lehetett opera:configban keresni
  • DSK-348133 [HWA] Rossz font rendering fekete háttéren
  • DSK-360626 [HWA] A Windows telepítő beállt
  • DSK-327663 [HWA] Összeomlás indításkor (Intel GMA 4500)

Változások listája (Mac):

  • DSK-316810 Sok CSS3 kurzor nem jelent meg
  • DSK-358894 Link húzása majd egy dobozba dobása új tabot nyitott
  • DSK-358378 Linkek húzása framekben helytelenül jelent meg
  • DSK-359445 UI elemek nem animálódtak Drag-and-Drop test után
  • DSK-358161 [HWA] Szöveg nem nyomtatódott ki
  • DSK-360189 [HWA] Néhány SVG összeomlást okozott
  • DSK-358323 [HWA] Web fontok láthatatlanok lettek transform után

Letöltés (Opera 12.00 b1372)

A bejegyzés trackback címe:

http://magyaropera.blog.hu/api/trackback/id/tr474456799

Kommentek:

A hozzászólások a vonatkozó jogszabályok értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a Felhasználási feltételekben.

Med1on 2012.04.17. 15:02:09

Most már tényleg csak az az Opera Reader hiányzik a korábban látott újdonságok közül. Most már úgy gondolom, hogy az sem marad ki a sorból.

Dzsini 2012.04.17. 15:10:41

A "további összeomlás javítások" között lehet valami más is a plugin kezelővel, mert egyelőre úgy néz ki jobban viseli a flash tartalmakat pl. betöltődés közben görgetve (kopp kopp).

Az Explode pedig zseniális, igazából én azt is nehezen hinném el, hogy ilyet lehet csinálni valós időben különálló programmal, nemhogy böngészőben :) Fantasztikus hol tart már a tudomány / kezdek megöregedni.

Imurai 2012.04.17. 15:24:16

Eddig (szintén kipi-kopi) működni látszik, nem annyira omlósz :D

penge™ · http://www.thevenusproject.com/ 2012.04.17. 15:33:39

@Dzsini: Explode demó (akiknek nincs webkamerájuk): craftymind.com/factory/html5video/CanvasVideo.html

@Med1on: Mondtam én, hogy a HWA fog a legtovább tartani. Most be akartam próbaképp kapcsolni, de még a forced sem működött (valószínűleg blocklist-en van a GeForce 7xx)

Med1on 2012.04.17. 17:29:52

@penge™: Biztos nagyon gonosz vagyok, de első körbe letiltanám az XP-t is, meg a GeForce 7000 sorozathoz hasonló régi vitézeket is. Így hamarabb kész lenne a HW, utána pedig ha sikerülne csiszolni a dolgot, akkor jöhetne az XP, de a régi kártyákon még akkor is elgondolkoznék.

MosoMasa 2012.04.17. 17:38:57

"Valamint arról is értesítést kapsz, ha egy oldalon inaktív ugyan, de előzetes engedélyezés miatt bármikor hozzáférhet a kamerához mindenféle jelzés nélkül."

Ez miért is jó nekem? ... ööö nem a figylmeztetés, hanem hogy bárki bekapcsolhatja a kamerámat ...

Dzsini 2012.04.17. 17:58:39

@MosoMasa: kicsit rosszul lett megfogalmazva, annyit jelent, hogy azon az oldalon te előzőleg engedélyezted a kameraelérést, és az működik akkor IS, ha épp nincs az előtérben az a fül, tehát figyelj oda magadra :)
Mivel bekapcsolható az is, hogy az oldal egyszeri kérdés után ne kérje többször az engedélyt, így akár meg is feledkezhet róla a felhasználó, ez a jel figyelmeztet rá.

MosoMasa 2012.04.17. 18:19:20

@Dzsini: Értem én, de akkor is gáz ... csak gondolj bele ... ki az aki lesi (átlag user) hogy https, vagy mi van kiírva ki lesi az összes jelet?
Ki az aki emlékezik mindenre, mit engedett és mit nem?

Dzsini 2012.04.17. 18:26:06

@MosoMasa: Ez a funkció egy minimális felhasználói tudatosságot vár el a usertől.
Elméletileg bármelyik flash tartalomnál is engedélyezheted a webkamera (és mikrofon!) elérést, az még csak nem is figyelmeztet többször, ha egyszer már leokéztad. Itt legalább a böngészőn egy látható jele van, hogy az adott oldal ilyesmit művel (ha a webkamerán nincs aktivitási lámpa vagy ilyesmi).
Egyébként több ismerősnél láttam, hogy a laptopján le van ragasztva a kamera, mert ők még paranoiásabbak :)

twollah / bRoKEn hOPe, sUppLeX · http://freewaresoftwarenews.blogspot.com/ 2012.04.17. 18:47:19

Tovabbra is benn ragad az opera_plugin_wrapper_32.exe a folyamatok kozott ha kilepek a programbol es zabalja a CPU idot.
A rendszer:
- Win 7 Ultimate 64 bit 4GB RAM, Q6660, Java SE Runtime Environment 7.0 Update 3.

penge™ · http://www.thevenusproject.com/ 2012.04.17. 19:22:18

@Dzsini: Te is félreértetted. Az a tabon (ami akkor is látszik, ha inaktív) jelzi. A címsorban lévő szürke jel azt jelzi, hogy a kamera nem aktív, de mivel az adott domainen engedélyezve van, ezért bármikor aktív lehet, HA
1. A http://www.example.com/index.php-ről a www.example.com/camera.php-re navigálsz.
2. Ha fut a háttérben egy script, ami aktiválja valamilyen okból azok az oldalon, amin éppen tartózkodsz, mert például valaki csatlakozik az oldalsávon futó webkettes webalkalmazásodhoz.

Tehát arra szolgál, hogy FIGYELJ ODA, hogy éppen miután végeztél a webchattel ne hagyd úgy a böngészőt, miközben olyat csinálsz, amit nem akarsz közkinccsé tenni, mert lehet, hogy az oldal gonosz és házi pornóra vadászik. :D

"a laptopján le van ragasztva a kamera, mert ők még paranoiásabbak"

-> Az a biztos. Kár, hogy a beépített mikrofonban attól még hallatszik a nyögés és a cuppogás. Néha még a nevek is tisztán. :D

Szóval a device managerben sem árt leválasztani, azt elvileg nehéz lenne kivitelezni, hogy egy vírus engedélyezze, majd ezzel egyidőben kiközvetítse valahova az élő adást, mindezt észrevétlenül.

@MosoMasa: Ezt úgy mondod, mintha legalább annyi oldalon kéne engedélyezni a Geolocation-t és a webkamerát, ahány oldalon a JavaScriptet. :D

1. Én arra is emlékszem, hogy hány oldalon engedélyeztem az On Demand Plugin-t. (vagyis kapcsoltam ki)
2. Ha mégsem, akkor override.ini megnyit, majd Ctrl+F és F3
3. Nem sokan lesik ezeket az infókat, ahogy az állapotsávon sem, hogy hova mutat egy link. Ezért történhet meg 2012-ben olyan, hogy rákattint valaki egy javascript: kezdetű linkre, ami ingyensört ígér, aztán persze cookie/session ID lopás áldozata lesz.

Végül is érthető, rohadtul megterhelő tud lenni megmozdítani a szemgolyódat, mielőtt rákattintasz egy linkre, főleg ha előtte órákon át kapáltál, kaszáltál, gyomláltál, ültettél és tehenet etettél... a FarmVille-ben.

@twollah / bRoKEn hOPe, sUppLeX: Akkor nálad valami egyedi probléma lehet, vagy szoftverkörnyezet, vagy döglődő Windows (általános hiba egyes processzek beragadása).
Mindenhol, minden beépülővel (Flash, Sivlerlight, Java), vagy csak egy bizonyos beépülővel/egy bizonyos oldalon?

Tudod reprodukálni, vagy random, vagy mindig mindentől függetlenül beragad?

Flash verzió? Ha 64 bites rendszer, miért nem 64 bites beépülőket telepítesz (már ha van az adott beépülőből 64 bites)?

penge™ · http://www.thevenusproject.com/ 2012.04.17. 19:49:06

@Med1on: Azért egyrészt a 7-es széria (de még a 6-os is) röhögve elviszi a Vistát/Win7-et Aero-val.

Addig akinek kényszerből (értsd: gyenge a gépe) kell XP-t telepíteni, annak már nagyon gyenge és régi gépe lehet, max GeForce 4-es kártyával. Neki az a legkisebb gondja, hogy nem tudja XP-n a hardvergyorsítást használni, amúgy se tudná.

A többiek viszont NINCSENEK RÁKÉNYSZERÍTVE(!) az XP használatára. Vagyis az ebből származó hátrányokat viseljék büszkén (vagy váltsanak).

Az átlaguser ha nagyon csóró még mindig ott a warez (nem akarok senkit buzdítani rá, csak jelezni, hogy nincs kényszer). Cégeknél meg ne gyorsítsanak hardvert. Egyrészt mert ha csóró a cég, akkor eleve valami Tesco Gazdaságos Celeron van, másrészt pedig, mert hivatalosan guglizniuk kell meg olyasmit csinálni, amihez nem feltétlenül szükséges Mancikának hardvergyorsított böngésző.

Tehát a kettőt talán nem kéne összevetni. Az XP pedig sajnos elsőszámú prioritást élvez éppen azért, mert 2 év múlva megszűnik még a kitolt terméktámogatás is.

Ráadásul ha a Microsoft úgy támogatja a régi hardvereket, hogy az XP portot elkerülte, akkor (ha eltekintünk az összeesküvésektől és a teljesen természetes korrupciótól) feltételezhetjük, hogy míg a régi kártyák támogatása nem igényelt (akkora) többletfejlesztést, addig az XP-re való portolás igen. Főleg, ha hozzávesszük, hogy nem véletlenül kukázott az Opera is egy csomó OS-t (például Solaris, OS/2) és nem véletlenül döglött már meg a fejlesztés alatt egyszer Win98-ban, egyszer pedig Win2k alatt.

Meg 18 gigás winsxs mappa se véletlenül van...

És még sorolhatnám, hogy míg az XP visszamenőleges támogatása egy időrabló átok, addig hardver esetében maximum a teljesítménytényező az, ami miatt úgy döntenek, hogy kukázzák, mert olyan lassú lenne, mint egy diavetítés. De a teljesítményigény nem nőhet a végtelenségig, mert egyik végletből se jó esni a másikba. Szóval ha valami megoldható kicsiben is (lásd: Opera telepítő), akkor miért hízzon feleslegesen hanyagságból?

Egyébként meg az asztali gép koncepciót sikeresen megölték (illetve folyamatban), tehát teljesen értelmetlen lenne CSAK videokártyát cserélni. Mert használt 8x és 9x-ért egy ezres is sok, normálisabb kártya pedig olyan, mint a fedélzeti számítógép a Trabantba (még ha a táp el is bírja). Tehát akkor már frissítsük az egészet. Új RAM-ok, új alaplap, akkor már új CPU, akkor már időszerű lenne egy SSD is, legalább rendszerpartíciónak és a végén akkor már "csak" párezer egy SATA-s vinyó/DVD író, legyen már az is és akkor nem kell PATA csatoló az alaplapra. Apropó, csatolók: akkor legyen már egy moduláris táp is, mert az egész összeszerelésben a kábeldzsungellel való kínlódás tart a legtovább, (főleg mióta a jumpertüskés időszakot magunk mögött hagytuk).

És ott is van a végösszeg, ami már nem kevés.

És ez még csak a gép. Akkor már egyúttal le lehetne cserélni a monitort is TFT-re/fullHD-re/nem TN panelesre (kinek mi van otthon) vagy csak DVI-sre/HDMI-sre, hogy ahhoz se kelljen átalakító.

MosoMasa 2012.04.17. 20:09:55

@penge™: Most megint arról beszélsz, hogy te mit szoktál és te mit tudsz!
Az átlag user nem tud ilyeneket számontartani, már csak azér semmert nem tudja mire kell figyelnie.
a script futtatás nem ugyanez. Azt előbb-utóbb megtanulja, mert ugye ha nem látja az oldalt, akkor táncsak gondolja, hogy valami nem stimmel. Ellenben a kamera és a mikrofon nem szembetűnő.az meg nagyon gáz, hogy külön bogarászni kell hogy kikapcsolja az ember ...
Mint mondtam, a legtöbb felhasználó azzal az infóval sem tud mit ezdeni, hogy http vagy https mit jelent, vagy lejelent-e valamit, vagy van e különbség a www és a http között, az ftp-ről már ne is beszéljünk!
Így aztán nem várható el hogy emlékezzen. Ennyi erővel az összes jelszavát is megjegyezheti, minek a jelszókezelő ...
Az meg hogy mennyi ilyen oldal van és ebből mennyit látogatok meg megint csak nem mérvadó. lényeg, hogy létezik. Ugye van pár oldal ami vírusos ... a többség azonban nem, mégis tartasz vírusfogót!
Aztán majd jelennek meg a YT-n a fasza kukkolós videók!
Azon a YT-n, amit az opera még mindig úgy néz mint egy marslakót.

MosoMasa 2012.04.17. 20:13:29

@MosoMasa: A YT-hez hozzáteszem, hogy a chrome is csak nézett a saját dolgaira az utóbbi időben , meg az FB-re is, stb.... bár mintha konszolidálódna a helyzet náluk, gondolom kifoltozták a hibákat ... nem tologatják maguk előtt évekig.

Dzsini 2012.04.17. 20:14:43

Találtam egy vidám stressztesztet a böngészőknek :)
(érdemes előtte minden fontosat elmenteni)
www.hubblesite.org/newscenter/archive/releases/2012/01/image/a/warn/
erről az oldalról a 170 megás 20x16ezer pixeles jpg-t lementve és megnyitva a böngészőben:
Az IE 32 és 64 bites is kirak egy X-es keretet pár másodperc után, nem is próbálkozik.
Az Opera (64 bit, Win7) gyors mozdulattal felzabál 3-3,5 giga memóriát a négyből, majd kb. 10 perc vinyózümmögés után megjeleníti a képet, bár igencsak érzéketlen marad egy ideig a böngésző és az egész rendszer körülötte.
(az Irfanview laza 1 gigás memóriafoglalással megelégszik, pár másodperc alatt megjeleníti)
Más böngészőm nincs :)

MosoMasa 2012.04.17. 20:17:57

@penge™: "Szóval a device managerben sem árt leválasztani, azt elvileg nehéz lenne kivitelezni, hogy egy vírus engedélyezze, majd ezzel egyidőben kiközvetítse valahova az élő adást, mindezt észrevétlenül."

Pedig létezik ilyen...

Med1on 2012.04.17. 20:39:56

@penge™: A görgetéses bugról állítólag ezt mondták az illetékesek:

“Devs have acknowledged it and they say that the fix is not easy and they don’t currently have any idea when or if it will be fixed.” Which isn’t very encouraging, if that’s actually true.

Elég cinkes a dolog, a favbrowsers csúnyán odapirított az Operának.

penge™ · http://www.thevenusproject.com/ 2012.04.17. 20:43:12

@Dzsini: Annyira nem vészes: i.imgur.com/7Syo9.png

99 mega fölött bezártam, mert akkor kezdte a Windows kilapozni önmagát, amit nem vártam meg, de addig szépen, ciklikusan renderelődött. Még bele is tudtam zoomolni helyenként. A Ctrl+W lenyomását követő 2-3 másodpercen belül bezáródott a tab, a memóriahasználat pedig drasztikusan lecsökkent. Azaz visszacsökkent a szokásos 3-450 közé.

Nyilván ha 2 gigától több RAM lenne a gépemben (mondjuk minimum 8), akkor nem okozna gondot.

Amúgy az IrfanView nálam már 6000x8000-es képeknél is érezhetően fáziskésésben van. Mondjuk biztos azért mert ott van élsimítás, meg gamma meg minden, ami ilyen képnézegetőkben szokott.

@MosoMasa: Vagyis nem csak a vírusirtón, de az UAC-on is átverekedi magát? És még telepíteni se kell hozzá MANUÁLISAN semmit, egyszerűen csak betölteni egy weboldalt? Mutass egy ilyet.

MosoMasa 2012.04.17. 20:59:08

@penge™: Nem az a lényeg, hogy min verekszi át magát, hanem hogy léteznek - vagy legalábbis léteztek erre megoldások, amik valahogy mégiscsak működtek. Nyilván vagy hozzáférhettek a géphez valamilyen módon, vagy a kedves user közreműködése is kellett ... de ez tök mindegy a téma kapcsán.
Itt ugyanis ezek szerin nem kell vírus sem, elég feledékenynek vagy figyelmetlennek lenni.

Dzsini 2012.04.17. 21:02:07

@penge™: Ezért írtam, hogy le kell menteni vinyóra, és onnan megnyitni - akkor dolgozik igazán a böngésző, hiszen a teljes kép a rendelkezésére áll. Nálad betöltött a képen 10-20 megát belőle, ami kitömörítve mondjuk 100 mega, attól még nem esik hanyatt :)

twollah / bRoKEn hOPe, sUppLeX · http://freewaresoftwarenews.blogspot.com/ 2012.04.17. 21:44:32

@penge™: a Win 7 nem hinném, hogy dolgodik.
Ket gepemen is hasonlo a problemam es a szoftver, hardver kornyezet viszonylag eltero.
Az Operat csak chatelesre hasznalom.
(Chat.hu, Gyaloglo chat)
Erdekes, hogy ez a beragado opera_plugin_wrapper_32.exe hiba az Opera 12.00 Build 1351 Snapshot verzioktol jott elo.
Szoval nem hinnem, hogy a Win7-tel van a hiba, mert amint visszarakom az Opera 12.00 Build 1328 Snapshot-ot a hiba azonnal megszunik es nem tudom reprodulkalni.

Ha jo angolos vagy akkor megkerlek ra, hogy jelentsd az Opera fele a problemat.

penge™ · http://www.thevenusproject.com/ 2012.04.17. 21:57:44

@MosoMasa: Már hogyne lenne lényeg? A felhasználó közreműködéséhez nem kell Opera. Bőven elég egy MSN vagy Skype és a hozzátartozó vírus.

@Dzsini: Hát igen, általában ez történik, amikor elfogy a memória egy olyan operációs rendszerben, amely annyira felhasználóbarát(!), hogy önmagát háttérbe szorítva öngyilkosmerénylőként végrehajtja a rá bízott feladatot. :D

De ugyanez akkor is adott lenne, ha egyszerre nyitnál meg középsőklikkes könyvjelzőmappaként mondjuk 300 db Facebook oldalt. Egy átlagos gép összefosná magát bármilyen böngészővel (az Opera állná legjobban a sarat), egy 16 gigás rammal és SSD-vel felszerelt brutál gép habár a szimultán kérések hada valószínűleg kidúcolná a szűk keresztmetszeteket, de maga a gép nem állna be, mert a hálózat (még ha 100/100-as netről és a Facebook vagy a Google DDoS-olhatatlan szervereiről beszélünk, akkor is) lenne a szűk keresztmetszet.

Azt meg továbbra is a Windows rovására írom, hogy miközben az egyik oldalon okosabb akar lenni, mint a felhasználó, addig a másik oldalon egy egyszerű művelet, mikor véletlenül Word-ben/Wordpad-ben nyitunk meg egy 4 gigás ISO-t (mert eggyel túlszaladt az egér a megnyitás mással-nál) szintén percekre megbénulhat és kilapozza magát az OS.

A slusszpoén, hogy minden ilyen véletlen félrekattintásnál az adott program bekerül a Shell-be, ahonnan csak Registry ismerete esetén lehet kitörölni a fájkiterjesztéshez való társítást.

A másik meg ez, igen. De ez még mind semmi. Egyetlen olyan szoftver nem létezik (a Process Lasso-t leszámítva, de az se erre van kiélezve), amiben beállíthatnám azon egyszerű dolgot, hogy adott elérési útvonalon lévő opera.exe esetén, ha mondjuk 5 másodperc alatt 300% (vagy magasabb) lesz a korábbi x időintervallum alatt felzabált memória abban az esetben dobjon fel egy prompt-ot visszaszámlálóval vagy azonnal lője ki (opcionálisan).

És mindezt processz-specifikusan beállíthatóvá tenni. Tehát ha mondjuk PhotoShopban mászik fel a memóriahasználat, akkor (mivel ott vagy a gép előtt) leokézod a visszaszámlálót, így nem fut le pár másodperc alatt a psKill. Viszont ha lemész sörért, miközben automatikus frissítés van beállítva x oldalon, akkor egy bug/memóriaszivárgás miatt nem térsz vissza, hogy minden kattintásodat 10 másodperces fáziskésés követ, mert épp készül visszalapozni önmagát a Windows, miután a Ctrl+Shift+Esc lenyomására megittál egy sört és az addigra puzzleszerűen kirajzolódó Task Managerben kilőtted az Operát.

penge™ · http://www.thevenusproject.com/ 2012.04.17. 22:01:38

@twollah / bRoKEn hOPe, sUppLeX: A chat.hu Java-t használ, a gyaloglót nem ismerem. A 1328-al valószínűleg azért nincs probléma, mert abban nincs plugin-wrapper. Próbáltad már a 64 bites Java-t telepíteni? Egyáltalán milyen verziójú Java Runtime Environment van fent? Ugye nem a Microsoft-féle JVM vagy valami régebbi verziós JRE?

Dzsini 2012.04.17. 22:16:39

@penge™: Az IE ilyen szempontból sokkal jobban vizsgázott - meg se próbálta megjeleníteni ahelyett, hogy valami érthetetlen okból több, mint 2 plusz gigabájtot megevett volna egy 100 megás kép megnyitásával - még 24 bites bmp-vé visszafejtve is "csak" 900 mega, amennyibe az Irfanviewnak fájt a dolog, valamilyen okból ennek a háromszorosára van szüksége az Operának. A képmegjelenítés nem az erőssége a böngészőnek :)

(amúgy Twollah leírta, hogy JRE 7 u3 van fent neki, tehát "ugye nem")

penge™ · http://www.thevenusproject.com/ 2012.04.17. 22:41:27

@Dzsini: Szóval az a jó böngésző (ami egy program), ami a user helyett gondolkodik?

Az Opera nem képnéző. Durva lenne, ha a dedikált képnéző zabálna többet.

Azt meg hadd ne mondjam, hogy ha minden művelet előtt lecsekkolná a böngésző a rendelkezésre álló rendszermemóriát és ez alapján szólna, hogy kevés, az mennyi plusz terhet jelentene.

Ahhoz meg minden 16 giga rammal rendelkező embernek joga van, hogy 160 megás több gigapixeles JPG képet nézegessen böngészőben.

Ilyen alapon tiltsuk be a www.whatwg.org/specs/web-apps/current-work/ oldalát is, de minimum szóljon a böngésző (egy előzetes URL adatbázis alapján), hogy túl nagy a DOM fa és a Linkifier nevű userJS-sel (ami RegExp kéréseket futtat le az egész dokumentumban http, https, ftp vagy www után kutatva) halálos párosítás.

Főleg, hogy ez eredetileg az OPERÁCIÓS RENDSZER dolga lenne, ahogy az is a óvónéni dolga, hogy a gyerekek ne fulladjanak bele a homokozóba, az meg főleg, hogy az óvónénit ne fojtsa bele valamelyik gyerek.

ps: Amúgy nézte már valaki linkifier userJS-sel (www.puzzleclub.ru/files/linkifier.js ) az Ipon oldalát? :)

twollah / bRoKEn hOPe, sUppLeX · http://freewaresoftwarenews.blogspot.com/ 2012.04.17. 22:55:06

@penge™: A rendszer:
- Win 7 Ultimate 64 bit 4GB RAM, Q6660, Java SE Runtime Environment 7.0 Update 3.

Most visszaraktam a Java SE Runtime Environment 6.0 Update 31-et es azzal kiserletezek.

twollah / bRoKEn hOPe, sUppLeX · http://freewaresoftwarenews.blogspot.com/ 2012.04.17. 23:57:35

Java SE Runtime Environment 6.0 Update 31-el is ugyan ugy elojott a problema.

Visszaterek a Opera 12.00 Build 1328 Snapshot-hoz.

Hol lehet a problema?
Azt nem allitom, hogy megorulok, mindenesetre eleg zavaro a problema.

Dzsini 2012.04.18. 06:41:27

@penge™: Tehát szerinted az Operánál helyes működés az, hogy egy bármilyen képet betöltve annak a háromszorosát fogyasztja memóriából? Kipróbáltam kisebb képekkel is (amit az IE is betölt), és az IE a normál méret mennyiségét foglalja el betöltéskor (nagyjából annyit, mint az Irfanview), az Opera pedig 2-3x annyit. Tehát egy képekkel teli weboldalon (galéria), ha van rajta 50 megapixelnyi kép, akkor 150 helyett 400 megát eszik (vajon a mobil változat is?).
Az Opera dolga (szerintem) az lenne, hogy a képmegjelenítő rendszere ne fogyasszon háromszor annyi memóriát, mint amennyit pl. az IE. Más dolgokban meglepően spórolós tud lenni, akkor a képmegjelenítésben mi ez a slendriánság?

És az első kérdésre válaszolva: igen, az a jó böngésző (és bármilyen program és operációs rendszer), ami a user helyett gondolkodik, és előre elkerül minden olyan problémaforrást, ami gondot okozhat - erről szól az adathalász védelem minden böngészőben, a keresési ajánlatok feldobálása, és az is, hogy nem is kezd neki egy olyan műveletnek, amiről esetleg tudja, hogy összeomlást, rendszerzavart okozhat. Tteszem azt jelen esetben le lehet kérni, hogy mekkora a betöltésre kerülő file, a headerben ott vannak a pixelszintű méretek is (színmélységgel együtt), és egy villanás alatt kiderülne, hogy ez meghaladhatja a böngésző képességeit ezen a gépen - a böngésző pontosan tudja, hogy mennyi a szabad memória, hiszen alkalmazkodik hozzá normál használat mellett, miért ne tehetné ugyanezt egy kép betöltésekor? Inkább jelenjen meg egy üres [kép] keret, mint fagyjon össze a rendszer / várjak 10 percet arra, hogy egyáltalán be tudjam csukni az adott fület.

aronvirginas 2012.04.18. 12:55:20

Nálam ebben a buildben a hardvergyorsítás olyan csúnya dolgokat művelt, hogy muszáj volt kikapcsoljam. Fagyott és furcsa objektumokat rajzolt. A korábbi snapshotokkal nem volt ilyen gondom. Szóval van még mit dolgozni a hardvergyorsításon. Inkább lassna haladjanak, mintsem elsiessék mint a Mac App Store build esetében a homokozót, ami miatt nem kevésszer omlott a 11.62. Becsületükre váljék, hogy gyorsan reagáltak, tegnap óta a Mac App Store-ban a 11.63-mas verzió, ami javítja a sandboxinggal kapcsolatos bugokat.

penge™ · http://www.thevenusproject.com/ 2012.04.18. 13:20:12

@Dzsini: 1. Akkor szépen nyomd le a Ctrl billentyűt, majd tekerd a scrollt fel-le egy sokmegapixeles képnél.

Vagy például nyiss meg szintén egy galériában középsőklikkel egy rakás képet, mondjuk 30-40-et, aztán (mivel mondjuk háttérképet szeretnél magadnak választani, nem mindenféle felesleges navigációval bajlódni) 1-es és 2-es billentyűkkel végigpörögsz rajtuk.

Na tedd meg ugyanezt máshol. Firefox maximum előtölt 1-2 tabot (vagy benne marad a memóriában, ha elég gyorsan csinálod), de van, hogy 1-2 másodpercet is matekozik a fehér háttér fölött, mire megjelenik. A Chrome ugyanezt csinálta régebben, most már zabálósabb lett. Az IE meg mind közül a leglassabb ezen a téren.

1. Az adathalász védelem más, de oda sem fog felkerülni a pistike.atw.hu legalább holnapig, ha én most létrehozom és csúnya kódokkal töltöm meg.

2. Nem, NEM tudja. Azt tudja, hogy a rendszerben mennyi a memória. Ha folyamatosan ahhoz alkalmazkodna, akkor nem jönnének a nyivákoló kérdések, hogy "sok a memóriám, mégis sokat eszik, pedig én nem CSAK az Operának tartom fenn".

Persze lekérheti folyamatosan, ezzel újabb felesleges ciklusokat generálva, aztán ugyanúgy benézheti, ha a következő pillanatban elindít a user egy memóriaigényes folyamatot. Vagy várj! Még az se kell hozzá. Bőven elég, ha az ütemezett víruskereső/töredezettségmentesítő/windows update elindul. Ha nem hiszed el, végy egy erre a célra kiélezett szoftvert (pl: AIDA64) és nézd meg, hogy tud azért zabálni a folyamatos rendszerdiagnosztika. Egy komolyabb procin talán nem számottevő, de sok kicsi összeadódik.

Azaz alkalmazkodhatna éppen ehhez is (programozás szempontjából megoldható), csak akkor (cserébe konstans 1-5%-os CPU usage többletért) meg azért menne a nyivákolás, mint a SuperFetch miatt, vagyis "Nehogy az a rohadt program döntse már el, hogy én most ha elindítok egy PhotoShopot vagy egy tömörítést és marad 100-200 mega szabad RAM (kiszámoltam), akkor az a rohadt böngésző ne kezdje már el kivágni önmagát a memóriából, ahogy tette anno a Firefox 3.x amikor rinyáltak a memóriahasználatért (pedig önmagában nem zabált az sokat, amíg tele nem pakolták kiegészítőkkel, általánosan lomha meg nem attól volt), aztán végül ők is belátták, hogy ez már így túlzás.

Azt meg továbbra is tartom, hogy a böngésző (nem csak az Opera, hanem bármi, főleg ha Linkifier kiegészítő is van, vagy bármilyen más masszív RegExp) képességeit egy szimpla hatalmas méretű HTML fájl vagy FTP lista (lásd: commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?path=Win/&sort=desc ) is meghaladja.

Mégis megnyitja azt is, mindenféle ellenőrzés nélkül.

Dzsini 2012.04.18. 13:34:56

Teljesen más dolgokról beszélsz, de mindegy is, így szoktad, ezt vártam :)

penge™ · http://www.thevenusproject.com/ 2012.04.18. 13:53:00

@Dzsini: Nem beszélek másról. Elhiszem, hogy jó lenne, ha nem zabálná 3x-osát, mint más böngésző, meg az is, ha megoldható lenne (kompromisszumok nélkül), hogy a rendelkezésre álló memória alapján jelezzen, hogy biztos meg akarod-e nyitni, fagyást okozhat, de nem értek veled egyet.

Még ha lehetséges is lenne EBBEN A FORMÁBAN, akkor sem ez lenne az első számú prioritás. A webkettő korában különben sem lesznek ekkora méretű JPG-k elterjedve, ez is csak demonstrációs célokat szolgál, mivel ilyeneket már minden normális helyen vektorgrafikusan ábrázolnak.

Egyébként meg te szoktál pillanatnyi hangulatodtól függően érvelni. Emlékszel még, mikor linkelgettem azt a 21 soros HTML(!) tesztoldalt, ami megfagyasztotta az Opera 10.5x-et? Te meg leoltottál, hogy az nem fordul elő normál környezetben.

Egy ekkora JPG meg pláne. Szóval az, hogy lehetne faragni a memóriahasználaton képek megnyitása esetén nem függ össze azzal, hogy hülyebiztos algoritmusok ezreit implementálják extrém esetekre.

Az nyilván axióma, hogy ha kompromisszumok nélkül (vagy vállalható kompromisszumokkal) megoldható a memóriacsökkentés, CPU igény csökkentés, foglalt terület csökkentés, ezek mindegyike egy nagyszerű dolog. De csak addig a pontig, amíg a használhatóság rovására nem megy, innentől minden ember egyéni preferencia alapján ítéli meg, hogy neki mikor merre billen a mérleg.

Dzsini 2012.04.18. 14:20:45

Nem prioritás, szó sincs róla - csak én is meglepődtem, hogy IE-hez képest egy ugyanolyan (bármekkora) kép betöltése legalább kétszeres memórialábnyommal jár (meg kellene nézni a többi böngészőt is, emiatt nem telepítettem fel másikat). És van bőven olyan weboldal, ahol 5-10 megányi kép egyszerre jelenik meg, az pedig több száz megabájtot jelenthet azonos környezetben, és ha a mobil változat hasonlóan pazarlóan viselkedik, akkor ott könnyedén kényelmetlen is lehet a dolog, ezen pedig nem segít a Turbo, itt a dekódolt méret számít.

Egy ilyen nagy kép annyiban nem hasonló ahhoz a HTML-es esethez, hogy képek minden oldalon vannak, és akár 5 megapixelnyi képnél 30-40 megabájtnyi különbség lehet foglalt memóriában, sok kicsi pedig nagyon sokra megy (és rengeteg eset van, hogy nincs thumbnail, hanem az eredeti képek vannak átméretezve).

A gyors és egyszerű megoldás pedig pl. az IE esetén (és ahogy olvasgattam a mobil Safari esetén) annyi, hogy bizonyos pixelszám felett egyszerűen nem jeleníti meg az állományt, feldobja letöltésre - iOS-es Safari alatt ez 1024 pixel bármilyen irányban GIF, TIFF és PNG formátumban, és 32 megapixel JPG formátumban (ez kb. 8000x4000 pixel, kb. 100 mega nyers képi adat), és bármilyen elem maximális mérete 10 MB. Ehhez hasonló korlátok beépítése szerintem egyszerű, racionális lenne, nem járna sok munkával, és rengeteg problémalehetőséget elkerül.
Persze ezt is át lehet verni pl. 500x500 pixeles téglák használatával.

penge™ · http://www.thevenusproject.com/ 2012.04.18. 15:08:35

@Dzsini: Igen, egy ilyen bekerülhetne. Egyébként a thumbnailek helyett beágyazott teljes méretű képek esetén ez se sokat segítene, mert bőven elég, amikor 2000x3000-es képekkel van tele (mondjuk 30-40 db) egy oldal.

De írd meg wishlistre, hátha...

Teddy Beer 2012.04.18. 18:35:26

Mobile alatt elég ratyi a kamera, meg csak úgy nem indul egy. Draganddrop meg hol olyan fontos?

franatixx 2012.04.19. 01:21:54

@penge™:
>mondjuk 300 db Facebook oldalt. Egy átlagos gép összefosná magát bármilyen böngészővel (az Opera állná legjobban a sarat)

Ez elég rossz példa volt, szegény operának a position:fixed bug miatt még egy FB oldallal is komoly problémái tudnak lenni.

MosoMasa 2012.04.19. 12:36:03

@penge™: Szóval k_ra nem a vírusokon volt a lényeg.

Med1on 2012.04.20. 14:53:59

Megérkezett a talán legkomolyabb Opera 12 előzetes, az utolsó (remélhetőleg) a béta előtt.

Dzsini 2012.04.20. 15:14:50

@Med1on: Le is fagy azonnal induláskor, ha bekapcsolom a gyorsítást.

Mr. Moody (törölt) 2012.04.20. 15:37:09

@Med1on: Kihagytam a legutóbbi 4-5 buildet.

Tiszta telepítés és kb. 23 mp elteltével rögtön Pure Virtual Function Call 6025

Gyakran Ismételt Kérdések

Hozzászólások

Keresés

Címkék

10.5 (32) 10.6 (28) 10.7 (17) 11 (23) 11.10 (21) 15 (8) 17 (8) ajánló (8) android (11) apple (10) beépülő (25) bejelentés (13) bemutató (32) beta (11) béta (10) bittorrent (13) biztonság (75) blog (36) carakan (16) chrome (13) cikk (75) css (11) design (8) Developer (41) dragonfly (25) előzetes (336) énoperám (27) eums (9) evenes (8) explorer (59) fejlesztés (10) firefox (62) flash (10) fordítás (79) frissítés (11) fun (15) funkció (177) gmail (12) gomb (22) google (26) gyorshívó (18) hiba (24) hír (8) hírek (15) hordozható (10) html5 (23) ingyen (14) interjú (13) iphone (9) irc (8) játék (51) javascript (8) javítás (274) karácsony (9) keresés (8) kestrel (75) kiadás (128) kiegészítő (31) közösség (9) labs (9) levelező (39) mac (10) menü (12) microsoft (11) mini (108) minialkalmazás (43) mobil (48) mobile (45) myopera (62) Next (11) opera (26) operasoftware (35) operawatch (17) opera software (20) peregrine (8) poén (11) portable (9) presto (10) rc (12) reklám (28) reklámtiltás (12) rss (9) safari (19) sdk (11) sebesség (11) segítség (10) stabil (12) stabilitás (19) statisztika (36) szabvány (30) szavazás (10) születésnap (10) tanfolyam (8) téma (12) teszt (17) tetzchner (9) tipp (211) újdonság (9) unite (38) unix (9) usb (15) userjs (29) v18 (11) verzió (10) video (20) webfejlesztés (15) Címkefelhő

Kapcsolat

Iratkozz fel a blog hírcsatornájára!

RSS icon

Olvastál valami érdekeset az Operáról? Küldd el nekünk!

Írhatsz nekünk e-mailt:
magyaropera@gmail.com

Hivatalos Opera rajongói blog

Szerzők

Alapító

Aktív szerkesztők

Korábbi szerkesztők