Re: [E-devel] Software X11 and Software SDL
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/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Software X11 and Software SDL
On 7/16/07, Cedric BAIL <[EMAIL PROTECTED]> wrote: > 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). Raster is aware of this, while writing 16bpp I opted to do this differently and this was the motivation behind idle_flush() call, so I'm now able to create my X pixmap, operate on it and destroy after some time it's unused. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Software X11 and Software SDL
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 :) Cedric - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
