On Thu, 5 Apr 2012 10:17:42 +0200 Cedric BAIL <[email protected]> said:
> 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 seriously though. shall we hobble then 99.9% in favor of the 0.1% that can't do 1 process (somehow)? :) we can't remain stuck in such a world forever. we already have a fairly conservative and old architecture. technically you can implement a multi-process model as threads within 1 process, as long as the system has threading. almost anything worth talking about does, and if it doesn't its able to be implemented using timer and stack switch hacks. > 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 yes. i'd worry about this later though. as long as its possible. > 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 it's evas - no ecore here. :) > 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. evas. if its a thread fallback. if its a process evas can also launch it, if not already there, but i'd have the desktop env launch it first so its there already for everyone. evas's own launching of the daemon is a compat fallback :) > 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. they do - but no "full/complete" pthread support -s o eventually there may need to either need to be an adaption or port on our part, but we can't avoid threads any longer. we can't hamstring the whole codebase because of platforms unable to do simple things like threading. :) > > 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. yeah. improve where possible so its less of a difference, but reality is that the world of 16bpp displays is slowly going away. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
