> > It's turning into the fundaments of the UI. There are many reasons for > that, > including the fact that animations are becoming intrinsic parts of the UI. > Also, supporting "eye candy mode" and "non-eye candy mode" means more code, > meaning more tests. It's easier to test less code (think of the > compositor). > > Another very important point is that those devices typically have a high > resolution and relatively slow CPUs. They need help from the GPU to drive > that > many pixels at a reasonable framerate -- that's what the GPU is there for.
Mandatory GL support is appealing and I basically agree with it, however, there are at least 2 scenarios I'd like to see MeeGo UI can run w/o it: 1) Some devices will have simple graphic module which doesn't support GL (for cost reason at least). According to MeeGo goals (so ambitious one :-) ), someone will want MeeGo to run on them sooner or later. If they have to fundamentally change UI framework because of this, they will simply forget about MeeGo. Technically, it wasn't easy to support UI w/ and w/o GL in same UI framework, but the flexible Qt graphic system makes it feasible. (That is one of reasons I love Qt) (I checked kwin code because it can turn on/off GL support but it does GL calls directly instead, which is another approach.) 2) From developer's perspective, the firstly step to port UI to a new Chip/Device is through framebuffer because it is simple (almost out of box) and can give a basic GUI env for others to use/develop while the DRI driver is been developed (and possibly wait for DRI driver from other company). If MeeGo UI framework provides (even limited) GUI w/o GL, it will help device/chip vendor porting MeeGo. Thanks. JD Zheng
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
