On Fri, 15 Jul 2011, Carsten Haitzler (The Rasterman) wrote:
> On Thu, 14 Jul 2011 12:14:05 -0400 Christopher Michael > <cpmicha...@comcast.net> > said: > >> On 07/14/11 12:10, Vincent Torri wrote: >>> >>> >>> On Thu, 14 Jul 2011, Christopher Michael wrote: >>> >>>> On 07/14/11 11:58, Vincent Torri wrote: >>>>> >>>>> >>>>> On Thu, 14 Jul 2011, Christopher Michael wrote: >>>>> >>>>>> On 07/14/11 11:46, Vincent Torri wrote: >>>>>>> >>>>>>> Hey >>>>>>> >>>>>>> what about killing completely xlib, now ? >>>>>>> >>>>>>> Vincent >>>>>>> >>>>>> Soon ;) XCB stuff still needs more work before that can happen tho. >>>>>> Granted, I do have E fully working here (locally) with the new XCB >>>>>> stuff, but there are still so things/issues to iron out (opengl, intl >>>>>> support, etc). >>>>> >>>>> i'm still a bit surprised that you made ecore_xcb completely async and >>>>> event-driven (you told me that on IRC), as I know that there could be >>>>> some problems if you keep the API that is in Ecore_X.h >>>>> >>>>> Vincent >>>>> >>>> Well, the event-driven part was fairly easy. By it's nature, xcb >>>> itself is async (to an extent). Now, having said that, the ecore_x >>>> (xcb) stuff could be a bit 'more' async wrt some things. We could do >>>> caching of cookies/requests/replies, etc, etc and improve things in >>>> some areas. >>> >>> ok, so *ecore_xcb* is not async. That is, you didn't suppress the round >>> trips. >>> >>> Vincent >>> >> Not yet. I focused first on just getting everything working correctly ;) >> When all the major issues are flushed out, then we can move on to adding >> more 'async' behavior (round-trips, caching, etc). > > i smell a misunderstanding of xcb here.. and xlib. xlib *IS* async. x PROTOCOL > is async. in that there are a LOT of calls to xlib do NOT send a request and > WAIt for a reply. xcreatewindow doesnt. xsetwindowattributes doesnt. > xconfigurewindow doesnt, xputimage doesnt... but other calls do - > xgetwindowattributes, xinternatom, etc. - they REQUIRE a reply from x in order > to return. xcb simply exposes the lower level x protocol more > than xlib does so it ALLOWS you to make these sync calls become async.. *IF* > you use the calls very differently to how you did before. basically an xcb > based > ecore_x vs xlib has basically no benefits compared to xlib with regards to > async except in a few rare internal places (eg on init). what needs to change > is the ecore_x calls need to allow more async behavior. that means making sync > calls that batch a lot of requests and replies into a single round trip, or > that allow for completely event-driven replies (eg you > xgetwindowproperty AND the property reply comes in some time later as an > event). event driven means major changes in code that uses ecore_x as the code > cannot get the data then do its thing. it has to start a get and queue it > deferring the "do its thing" until the reply comes in. this has a knock on > effect to all other code logic that was dependant on the reply. > > total async execution is the holy grail and "best possible result". it is also > the hardest. And i'm convinced that it is not possible, without memory (maybe big) loss, with the Ecore_X API. To have ecore_x really async and event driven, you have to poll each replies on the fd. So, if e17 queries, at different time and place, in that order: GetWindowAttributes of window1 GetAtomName of atom a GetWindowAttributes of window2 The fd is awaken, xcb_poll_for_reply is called, replies are sent in that order (X assures that) but it's not necessarly the case for the events. If you just use the cookie, then event won't be able to know which window (window1 or window2) correspond to the event. So you have to allocate / free memory to store more informations + a lot of code to detect which object (window1 or window2) is associated to the event you have. And then, you lose a big interest of xcb. I'm not even sure it's possible, btw. > the middle ground is a "much less round trips" world where, for > example, when e has to manage a new window, it queues every property fetch and > then does a single round-trip wait for al the replies, as opposed to a round > trip per property (it may have to fetch between 0 and 100 properties for a new > window). just init is almost 200 properties. On my computer, ecore_x_init xlib was 6 times slower than ecore_x_init xcb > this requires ecore_x to expose enough handles/functionality to do > this and then something like e17 to actually make use of it before you see the > real benefits. benefits are also big speed up compared to xlib when an app is launched over an ssh pipe. That's something I do every day at work and xlib is so frustrating for me. Vincent > benefits xcb can help with other than async tho are memory footprint. xlib > allocates quite a lot of memory for storing information that may be needed by > clients and this data is in malloc()ed segments private to each process. we > can > do this ourselves and instead use shared mmaped files thus having the memory > only allocated once and shared between all ecore_x using processes. we can > probably also just avoid storing data we dont need or allocate it "on demand" > as opposed to it being a fixed overhead, regardless how little or much is > needed. > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
