Linked by Thom Holwerda on Mon 31st Oct 2011 12:59 UTC, submitted by Martin H Hansen
Permalink for comment 496352
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 06/18/13 22:33 UTC
Linked by Anonymous on 06/18/13 22:26 UTC
Linked by Thom Holwerda on 06/18/13 22:25 UTC
Linked by Thom Holwerda on 06/18/13 17:45 UTC
Linked by Thom Holwerda on 06/18/13 17:32 UTC, submitted by poundsmack
Linked by Thom Holwerda on 06/17/13 17:58 UTC
Linked by Thom Holwerda on 06/17/13 17:52 UTC
Linked by Thom Holwerda on 06/14/13 21:03 UTC
Linked by Thom Holwerda on 06/14/13 20:46 UTC
Linked by Thom Holwerda on 06/14/13 17:32 UTC
More News »
Sponsored Links



Member since:
2005-07-06
When idealized (and towards what present hardware architectures - maybe also R-Pi - converge to, internally), sure.
But, you know, not only 2D / video is something traditionally, for a long time, done by fixed-function, specialised bits of hardware (and libraries, methods, commands oriented for 2D rendering), without any serious possibility to tap those capabilities for 3D.
And not only there are still very clear vestiges of the mentioned separate libraries, methods of accessing 2D vs. 3D.
Even with a HW which doesn't really distinguish internally, and with a compositing WM which directly taps 3D (which Openbox/LXDE doesn't do) - there is still big difference between a stack suitable for "real 3D" (say, the gaming heavyweights mentioned above), and one suitable for desktop (here, OSS drivers are mostly good enough ...even if needlessly requiring more powerful hardware for "good enough" performance; even if, via barely supporting power saving, they waste power - which wouldn't really be a problem for R-Pi, anyway)