On Jul 14, 2007 11:27 AM, Vincent Torri <[EMAIL PROTECTED]> wrote: > > Hey > > On Thu, 21 Jun 2007, Vincent Torri wrote: > > Proposal #2: > > If XCB is found: > > * If a request does not need a reply, the function is just a translation > of the Xlib code. Nothing much to say.
Agreed so far. > * If a request needs a reply, there will be 2 implementations: > > - a function with the same name than the Xlib code, which is a > translation of the Xlib code. No possibility to remove round trips. This > is in order to keep current code working when XCB is found. Also agreed, but some related comments below. > - 2 functions, one that sends the request, the other one that get the > reply. For example, let's take the GetGeometry request: > > ecore_x_drawable_geometry_get_prefetch : will just call > xcb_get_geometry_unchecked and will cache the cookie, like the current > implementation. That function is non blocking. > > ecore_x_drawable_geometry_get_async : will ask for the reply by calling > xcb_get_geometry_reply. As raster wants an event driven api, that function > can have that prototype (idea from rephorm, if I'm not mistaken): > > void ecore_x_drawable_geometry_get_async(Ecore_X_Drawable drawable (unused), > void (*reply_cb) (void *reply, void > *data), > void *data) > Some remarks: > * the async prefix is added to avoid having the same name than a current > Xlib function. > > * with the current implementation of the cache of the cookies, the _async > functions must be called in the same order that the _prefetch functions. I > guess that it must be changed. > > * I don't really know if the 'drawable' parameter is needed. I mean, it's > unused with the current implementation of the cache, but can be needed if > we want to the _async functions to be called in any order. > > * when xcb_get_geometry_reply has returned, the callback 'reply_cb' is > called with a pointer to a structure containing all the data the reply > provides. With that example: > > struct Ecore_X_Geometry > { > int x; > int y; > int width; > int height; > int border; > int depth; > } > > * that function is blocking (as xcb_get_geometry_reply is) While I understand this is part of the design for XCB, I'm not a fan of the required blocking points. Ideally, we would like to receive notifications of events as the server completes them, rather than in the order we request them. For instance, if you request the copy of pixels from a drawable to an ximage, followed by requesting the values for some properties on a window, a multi-threaded server could very easily respond with the properties before completing the copy operation. Since these are unrelated operations, you would like the completion notifications as they come in, not in the order you ask for their replies. Also, you very well could continue to do other work while waiting for the result from that ximage transfer (performing local computation, pushing UI updates, etc) so blocking on that async reply is not ideal. > Another possibility (raster's idea) for > ecore_x_drawable_geometry_get_async is to sent an event > ECORE_X_REPLY_GEOMETRY_GET just when the xcb_get_geometry_reply call has > returned. The event would contain (actually, would be) the structure > above. Then, the prototype would just be: > > void ecore_x_drawable_geometry_get_async(Ecore_X_Drawable drawable (unused)) > > raster: in that case, should we also add those events in the Xlib > implementation ? My preference would be a resounding YES! :-) I also tend to agree with raster's API choice of using the existing event model. I would like to see the removal of the _async calls entirely and get this to the point where we have essentially 2 exposed calls. The first is the traditional blocking call, while the second is a _request or _prefetch call. Below are my ideas of how this could work, but you are far more familiar with the XCB specifics so please let me know if a part of this is not feasible. There is also the possibility that extensions could be made to XCB to support some of this behavior. For the traditional blocking call the XCB backend would use the request call, but would immediately request the response value and cause the app to block. In the Xlib implementation, it would simply make the blocking call, and return the values as they currently do. The request or prefetch call would submit the request and add the cookie to a queue along with a reply specific callback (similar to the API rephorm mentioned). This queue would then be processed as part of the idle loop when the fd for the XCB connection has data available. Each cookie on the queue would be checked to see if a reply has been received, or better yet, XCB provides a list of available replies. For each cookie with a pending reply, it is processed with the reply specific callback. The callback is responsible for requesting the data, which we know is available and therefore should not block, and emitting the ecore event. The Xlib backend would have a blocking call occur and emit the same event immediately after the blocking call returns. This seems very similar to your proposal but I think it's more explicit about the expectations the end-user should have for requests. It should make them realize that the responses are asynchronous events and that they are potentially slow round trips that will return at some arbitrary time in the future. Thoughts? Nathan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel