On Thu, Apr 5, 2012 at 1:29 AM, Gustavo Sverzut Barbieri <[email protected]> wrote: > On Wed, Apr 4, 2012 at 7:23 PM, Vincent Torri <[email protected]> wrote: >> On Wed, Apr 4, 2012 at 7:34 PM, Rafael Antognolli >> <[email protected]> wrote: >> Some questions : >> * what about the Coyote and ps3 arch ? > > Same as cserve, it will not be supported due the lack of multi-process > support.
There is still many non multi-process system out there. I have been thinking all this night how to make this work. At least they all have some thread support. So maybe we could have a fallback mode that instead of making cserve a standalone process, it will become a thread task. In that case, it does have some implication, how to handle the main loop ? We should make it possible to run multiple ecore main loop or have a light main loop support. I don't know yet. The other question will be, where should we launch this thread task, in evas ? Then we have a build dependency in it. Or in Elementary, but it sounds more like a work around. So I really don't know. This is just throwing idea in the air, just in case someone get a brilliant one and we can fix this use case. If not, that would be sad, but we should have some time to find a proper solution. >> * will cserve2 be optional like cserve ? > > To start, yes. If it proves mature and to work well, Raster plans to > make it the default mode. If it goes well, it may be the only way. As > you can expect, there is a long road to it, including: > - port to other systems (BSD, Windows...) > - figure out what to do for too-different archs such as > single-process native PS3. > > For the last point I have not many details. As far as I understand the > lack of multiprocess in PS3 is an implementation issue, that could be > added later? (KaKaRoTo voice in!). They have no multiprocess, but they do have some kind of thread support. So there is a way to support this feature at least in theory, we just need to think about how. > What Raster already stated, and it may impact other platforms in > future, possibly guiding these points are: > - Evas will hard-depend on threads; > - Evas will revert to 32bpp-only, 16 and 8 will be removed. I have some idea to improve the speed of 32bpp software engine to make it closer to the 16bpp engine. I fully agree, that we should not need the 16bpp engine that much in the future. -- Cedric BAIL ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
