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: >> On Wed, Apr 4, 2012 at 1:21 PM, Vincent Torri <[email protected]> >> wrote: >>> On Wed, Apr 4, 2012 at 6:02 PM, Vincent Torri <[email protected]> >>> wrote: >>>> On Wed, Apr 4, 2012 at 4:52 PM, Rafael Antognolli >>>> <[email protected]> wrote: >>>>> Hello people, >>>>> >>>>> As some people know, ProFUSION is also working on Evas and making some >>>>> changes that should make it even faster. >>>>> >>>>> Currently we are working on the images cache server, and it should be >>>>> similar to the previous cserve, but with a more asynchronous API. It >>>>> also has some fundamental changes, like having a pool of loaders where >>>>> each of them run on a different process. >>>>> >>>>> The main idea is that the client can request the images needed as soon >>>>> as a file_set is done, but don't block waiting for them to load. Once >>>>> Evas really needs the image data, it will finally block to get this >>>>> data, and should return almost immediately if it was already loaded. >>>>> >>>>> Some tweaks still must be done on the current code, some cleanup, and >>>>> even some documentation, but the core is already there. A new internal >>>>> cache was also done for Evas, very similar to the previous one but >>>>> with some more direct calls to the server and some shorter code paths. >>>>> >>>>> The code can be seen here: >>>>> http://git.profusion.mobi/cgit.cgi/antognolli/evas-cserve2/ (branch >>>>> cserve2) >>>>> >>>>> Any comments are welcome! >>>> >>>> what about Windows ? >>> >>> a small grep finds : >>> >>> shm_open >>> fork + execvp >>> >>> so it will be hard to have someting working well on Windows... >> >> Linux specific code on the server is in >> evas_cserve2_main_loop_linux.c > > are you really serious when you say that ? > > just grep 'shm_open' and 'fork'...
That's what we can do for the main loop, it's to aid porting, not to make it happen now. We can isolate more in future as ports happen. What is in this file is actually linux specific, like using signalfd() that is not even available for FreeBSD or Solaris. Hopefully before we have to worry the projects will be merged and we can use Ecore, as proposed by cedric. Right now that's what we can do in a viable timeframe. That was agreed by raster to have a Linux specific code until then. as for fork()/exec, we asked you what was better to use to help Windows. No idea if you recall, but we did ask you as our initial hope was to go with "fork()" only solution, you said it couldn't be supported on Windows, but the fork-exec pair could. Then we followed that. > btw, if you were doing portable code, you would use eina_file for > shm_open and not shm_open directly http://git.profusion.mobi/cgit.cgi/antognolli/evas-cserve2/tree/src/bin/evas_cserve2_slave.c?h=cserve2#n200 Eina file does not support PROT_WRITE. We hope it can be added later, after the current version is released. Here we also talked to you, you mentioned that you had some ideas to make the shm work for windows. Right? If you check the code, we tried to keep these isolated to aid porting. We're just not doing the port, then it is expected to miss some cases that will be cleared when the first port happens. > Some questions : > > * what about the Coyote and ps3 arch ? Same as cserve, it will not be supported due the lack of multi-process support. > * 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!). If there is no way, we can always try to keep the existing code as fallback, or these projects continue with an older Evas version due their small user base. I have no clear opinion on those, then I can't say anything concrete. Sorry. 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. The point is focus on most common use cases, easing maintenance and reducing code base. If you check the current complexity of cache due the introduced 16bpp (then 8bpp), it hurts. Also having the always-thread render phase and similar will help to simplify the most common cases out there. Don't shoot the messenger (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
