On Mon, 16 Jul 2007 14:45:43 +0200 Cedric BAIL <[EMAIL PROTECTED]> babbled:
> Hi, > > During my development of the SDL engine I did notice that always > seems a little bit faster than software x11. I think it was only an artefact, > or something strange with my config, but as Caro also notice this. We did > find something that could be the source of the slow down. > > In the software_x11 implementation, we create a new RGBA_Image for > each region to be update (in evas_engine.c:eng_output_redraws_next_update_get > with evas_outbuf.c:evas_software_x11_outbuf_new_region_for_update). Then they > are flushed on the final surface and destroyed. > In software_sdl, I just copy to the final destination without > creating new surface (I need to reset the background to start from a fresh > copy). > > The software_x11 is also more complex than software_sdl as it handle > rotation and I don't know it's internal enough to see how and if it's > possible to change it to not allocate an RGBA_Image for each region. So if > someone as a little more time to look at this issue and see if it's possible > to improve thing :) we pay a performance price for: 1. allocing memory - and if its "fresh" memory from sbrk() or mmap() as malloc will provide, it will be filled with 0's by the kernel. this is a cost we pay for "unix security" on getting more memory. we don't need or want it filled with 0's - we want it just garbage memory. we will fill it later anyway. 2. shm segments - creating and destroying them, round-trips to x to do this AND also filling them with 0's like the RGBA_Image buffers. same story - but a little worse even. in 32bpp evas is a little smart - it actually will use the shm buffer AS the image data for the RGBA_Image so we only pay this price once in shm buffer creation and 0 filling. software_x11 can be faster by adopting the same caching idea as software_16. api is there - just needs to be used :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel