On Thu, Apr 5, 2012 at 5:17 AM, Cedric BAIL <[email protected]> wrote: > 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.
As said if people are highly demanding, there could be a fallback to single-processes cases. But as I understand raster's will is to make it the default one, after it's better tested of course. Then we need people to test it ;-) >>> * 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. the code can be changed to work in threads instead of processes. It's not single-flag/one-liner, but interesting peers can work towards that. The choice of multi-process is based on safety it allows, like the crashing loaders. It also remove the need of "generic loaders", as the cserve2 process can be modified to load single-format slave loaders in future. Then the slave is not linked with any GPL/BSD and is safe to be proprietary. (this is possible but not implemented yet). >> 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. Fortunately the customer demand for "iphone like" user interfaces on everything is forcing dynamically programmable GPU such as OpenGL-ES, and this also comes with benefit to process 32bits and convert to 16 really fast. yes, i know some cost-constrained cases may continue in 16bpp with old-fashioned acceleration like set-top boxes with directfb. But there are choices to be made, not by me :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ 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
