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
