On Wed, Dec 5, 2012 at 8:24 AM, Cedric BAIL <[email protected]> wrote:
> Yop,
>
> On Wed, Dec 5, 2012 at 6:58 PM, Gustavo Sverzut Barbieri
> <[email protected]> wrote:
>> Lately having to read more code than I'd like, but some stuff came to my
>> mind as cleanup. Please comment before I execute them tomorrow:
>>
>> - remove directfb
>
> Agreed.
>
>> - remove ifdef related to async pipe and image preload. Always enabled
>
> Agreed.
>
>> - remove cserve1
>
> Agreed.
>
>> - remove Evas pipe (up to discussion, but I rather remove it and the huge
>> amount of code that exist to support it). With the new thread system it
>> wouldn't work as is, we'd need to modify it anyway and I don't think it will
>> bring much gain.
>
> Here I disagree. It is currently on hold waiting for the async work to
> be done, to be improved again. Current issue is that we do trash and
> compete on memory access during all our operations. With the correct
> memory access pattern, less memory bandwith being used (more CPU used)
> we can improve it and I think we can expect some gain here. I do
> seriously expect an improvement as we have some good idea why it is so
> slow actually. So keep the code around even if you don't want to make
> it work yourself with the new pipeline.
ok, will keep it then, but it will just work when doing the
synchronous render, thus from main thread.
my reason to want to remove it is because when we migrate data to the
secondary thread, we already have to simplify RGBA_Draw_Context to
important bits for that drawing primitive, then the pipe code as it's
now will be mostly useless :-/
>> - remove code to clip to an image/mask. Seems to not be working, it's quite
>> complex and nobody seems to be getting it anytime soon. It's better to come
>> to it again in a clean approach than try to fix what's in there now
>
> That's something I have been thinking a lot about. I tend to agree,
> but not strongly. The mask case seems to be fixable, but I am not
> really sure.
problem with mask is not the blending function, which is simple (for
every pixel, modulate color from src and mask before you blend/blit to
dst). It's to properly manage the mask rendered surface. If your
object is a white-transparent image, but it's clipped and possibly
colored with such clipper, you need to generate a new image that is
clipped and colored representing the actual mask data you want.
Whenever the clipper changes, or the mask object changes, you must
invalidate it... which is bit more cumbersome when you send to thread.
It's all doable, RGBA_Image will keep refcount, if you never modify
it, just copy-on-write, it should just work... still it's not working
and nobody will get to that anytime soon.
Also seems that with the proxy/map infrastructure, one can handle
it generically. Not just for image, but for other objects as you'll
have to handle this "clip colored" case that generates a new render
anyways. Then getting to it with a fresh code is better than fixing
what is there. If someone gets to it.
>> - remove code, mostly commented, to handle filters. Nash started but it
>> never worked and there are mountains of code related to that commented or
>> #if 0
>
> Same remark as the previous one, except it seems harder to fix.
yep, way harder :-/
>> - various general cleanups of commented or #if 0/1 in the engines.
>> Particularly in x11. Raster, could you check those? Likely you added most of
>> them.
>
>> On a related note I wonder about xlib x xcb. I tried xcb in the beginning
>> "because it was cool" but our engines did not work properly and I reverted
>> to xlib since then (2007? 2008?). How is it now? Do we really have to
>> maintain xlib if xcb is working? Seems xlib is implemented on top of xcb
>> now. Reducing one engine in Evas and one in Ecore would be helpful.
>
> I think there is still one limitation, we need xlib for OpenGL I think.
discussed in the other thread, Devilhorns sent a link where states we
can rely on xlib-built-with-xcb and just do our stuff in xcb, the GLX
bits in xlib.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: [email protected]
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
