On Fri, 15 Jul 2011 07:40:20 +0200 (CEST) Vincent Torri <vto...@univ-evry.fr> said:
> > > 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. it is possible. it's just hard. for the above example, you COULD deliver all results as events and its the clients job of matching up the events with the data that wanted to store the results. it's hard though. > > 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 yes - thats where doing batch fetch and batch reply helps a lot. u can do 1 round trip instead of 200. > > 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 > > > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
