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

Reply via email to