Az a 4., hogy az ilyen kis gépecskékbe eléggé kicsi kapacitású akkut tesznek...
Az, hogy viszonylag közel áll egymáshoz a két szám (Blu-ray és 3DMark), éppen azt jelzi, hogy a CPU és az IGP (stream procik) fogyasztása hasonló nagyságrend, mint az UVD+SAMU (+ x% proci). Mondjuk vélhetően az a SAMU benyel egy pár wattot... Vagy az is lehet, hogy most valójában prociból dekódolja a Blu-ray védelmet, mert "nem nagyon" ismerik még a playerek/codecek ezt a SAMU-t... MKV esetén mindenesetre jóval közelebb lesz szerintem a 7 órához (már DXVA [HW-gyors.] komp. anyagoknál, de ma már szinte mindegyik ilyen)...
(#12) FireKeeper: Tudod, összetartanak... Főleg, mióta az AMD-t és főleg a GF-et az arabok pénzelik.
Ha érted, mire gondolok... (Ne mondd ki!) És nem, nem vagyok anti-akármi. Bár mi lennénk ennyire összetartóak... 
(#16) julius666: Úgy tudom, ez a 3x10 bites dolog már most is megy videólejátszáskor, de csak trükkösen. Kérdezd erről janos666-ot! (Win7-en megy, én még bizonyos okokból WinXP-n vagyok, különben magam is utánajártam volna a dolognak.)
(Az már alap, hogy a videokártya LUT-jából kimegy a 3x10 bit DP-n, ill. 3x10+ bit HDMI-n, ha a megjelenítő is támogatja. Sőt, AMD-n [ill. lehet, hogy újabban NV-n is] 3x8 bites kapcsolaton is effektíve 3x10 bit megy ki, 8 bit natív + 2 bit din. dither alakjában. Bár ez azért nem teljesen ugyanaz, mint a natív 10 bit, de így is jobb, mint a sima 8. Nem (lenne) rossz, ha a 3x10 bitesen feldolgozott videó kép akár csak az utóbbi alakban átmehet...)
Persze azokon a ripeken ez nem segít, amik olyanok, mintha a 8 bit/csat. sem "lenne ki"...
[ Szerkesztve ]