On 05/12/12 11:00, Gustavo Sverzut Barbieri wrote: > On Wednesday, December 5, 2012, Christopher Michael wrote: > >> On 05/12/12 10:05, Michael Blumenkrantz wrote: >>> there's at least one reason to keep xlib: xcb doesn't support custom >> mouse >>> cursors. unless we add loaders and workarounds for this, it's definitely >>> worth keeping xlib. >>> >> >> Yes. XCB does not have xcursor library support (ie: there is no >> xcb-xcursor to read the xcursor files). We could implement some code to >> read those tho, and it is on my (overgrown) TODO list...just have to >> find time. > > > Is that the only blocker? Seems feasible to work on that instead of > maintaining 2 Evas and Ecore_X engines. > > Anything else? Cedric mentioned about GL, could someone confirm? Is it > possible to do it in xcb and the guy uses xlib on top, if xlib is built > with xcb it should work. >
Yea, GL is an issue also: "XCB-GLX only communicates with the X server, it does not perform any hardware initialization or touch the OpenGL client-side state. Because of this XCB-GLX cannot be used as a replacement for the GLX API. To use OpenGL in the X Windowing system, one must use the GLX API, and the GLX API is closely coupled with Xlib. As a result, an OpenGL application on the X Windows must use Xlib and thus can’t be done using only XCB." "Although writing a OpenGL application on X Windows using pure XCB is not possible, it is possible to use a XCB-based Xlib implementation to configure a rendering context in a hybrid XCB/Xlib application. Xlib is used with the GLX functions while XCB can be used for everything else. You do get all the advantages of using XCB, but you can’t get entirely rid of Xlib." Hope that clears things up a little ;) dh > > > >> >> dh >> >>> also we really do need a server profile build for the efl tree. having to >>> build all of evas and ecore-evas stuff when you just want ecore-con is a >>> pain. >>> >>> On Wed, Dec 5, 2012 at 9:58 AM, Gustavo Sverzut Barbieri < >>> [email protected] <javascript:;>> wrote: >>> >>>> Hi all, >>>> >>>> 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 >>>> >>>> - remove ifdef related to async pipe and image preload. Always enabled >>>> >>>> - remove cserve1 >>>> >>>> - 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. >>>> >>>> - 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 >>>> >>>> - 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 >>>> >>>> - 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. >>>> >>>> --Gustavo >>>> >>>> Sent from my iPhone >>>> >> >> >> >> ------------------------------------------------------------------------------ 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
