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. 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). 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 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
