Cyphre redoing the View engine is the same as not wanting to use the current one anymore, isn't it?
Pekr
No, it was just his long term idea, to abstract the engine, so that it can use various backends - AGG, Cairo, etc, and provide platform acceleration, where available. Unfortunatelly, that was just an idea on his side, no real project. There is nothing wrong with View engine itself, apart from some bugs in core, which make it look unfinished. That would not happen with Red, as all sources and hence debugging is possible ...
Kaj
If you port it to Red, you'll only have a drawing engine, no widgets. I already have that in my Enlightenment port to Syllable, or in SDL or DirectFB if you combine it with some drawing library
Pekr
But other engines you name are far from what View engine in fact is - system of gobs, etc. Widgets are VID. I still prefer not so much perfect VID, instead of overbloated stuff ...
Kaj
As I've reported before, Enlightenment is quite like View regarding the architecture
Andreas
How big are the Enlightenment libs? Does E have any peculiar build/runtime dependencies?
Kaj
It's a pretty integrated stack, but modularised into more than ten packages. The dependencies are pretty much the same as the basic dependencies for other toolkits such as GTK, and most of them are optional. Stuff such as FreeType and FontConfig:
Very roughly speaking, when you add up the libraries, Enlightenment is half the size of GTK which is half the size of Qt
Kaj
The shared libraries on my system currently total 5 MB, without dependencies from outside Enlightenment
Andreas
Thanks.
Cyphre
"Cyphre redoing the View engine is the same as not wanting to use the current one anymore, isn't it?" - Well, I actually use the current one with R3 almost everyday ;-) And to make things clear I won't be redoing it...my plan is to update it to 'next generation' also add more features and improve some parts of the current base etc.
Kaj
I thought you found AGG too slow on your phone?
Pekr
Kaj - I do remember View 1.0 alpha with CID (predecessor to VID) on a Pentium 75, 130 - ran "acceptable". Cell phones have limited UI needs imo, I doubt AGG will be slow. Of course some heavy operations might drag some juice from the battery, as it is not accelerated. We now need to find the ways of how to get Cyphre's idea becoming a reality ...
Kaj
The issue is with phones that don't have FPUs. I'm just basing myself on what Cyphre said several months ago
Cyphre
Kaj, yes, but the changes I plan will allow you to relatively easily use different renderer component. Even in current host-kit I would just replace the agg renderer with something more suitable for slow or not sufficiently equipped ARM cpus but the "framework base" of the sytem would remain same.
Pekr, my experiment showed AGG on ARM without FPU was way slower than the native implementation of Android Canvas engine...mainly because the Canvas uses integer based rasterizer etc.
Pekr
well, are there really devices, with no FPU these days?
Cyphre
For example my Smasung Galaxy mini phone :-) AFAIK these low-ends are owned by a lot of people who doesn't have big enough pockets to handle the much bigger, expensive and powerful ones.
Pekr
That might be a history sooner, than R3/View exists for such devices :-)
Cyphre
Yes, but it is always good to have some flexibility and choose which graphics setup is more suitable for your target platform.