I think this looks very reasonable. Were you able to verify with the
XCB devs that we can poll on the cookies like this?
On Dec 31, 2007 10:25 AM, Vincent Torri <[EMAIL PROTECTED]> wrote:
>
>
>
> On Sun, 30 Dec 2007, Nathan Ingersoll wrote:
>
> >> 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.
>
> Here is a small implementation of your ideas for the GetGeometry request:
>
> [code]
>
> typedef struct Ecore_X_Cookie Ecore_X_Cookie;
>
> typedef struct
> {
> int x, y, w, h, border, depth;
> } Ecore_X_Reply_Get_Geometry;
>
> struct Ecore_X_Cookie
> {
> xcb_get_geometry_cookie_t cookie;
> void (*reply) (Ecore_X_Cookie *cookie);
> };
>
> /* The event */
>
> ECORE_X_REPLY_GET_GEOMETRY
>
> /* the prefetch function */
>
> void
> ecore_x_get_geometry_prefetch (xcb_drawable_t draw)
> {
> Ecore_X_Cookie *cookie;
>
> cookie = calloc (1, sizeof (Ecore_X_Cookie));
> if (!cookie) return;
>
> cookie.cookie = xcb_get_geometry_unchecked (_ecore_xcb_conn, draw);
> cookie.reply = _ecore_xcb_reply_get_geometry;
>
> /* add the cookie to an ecore list */
> ecore_xcb_cookie_cache (cookie);
> }
>
> /* the callback that is called when its reply is available */
>
> void
> _ecore_x_reply_get_deometry (Ecore_X_Cookie *cookie)
> {
> xcb_get_geometry_reply_t *reply;
> Ecore_X_Reply_Get_Geometry *r;
>
> reply = xcb_get_geometry (_ecore_xcb_conn, cookie.cookie, NULL);
> if (!reply) return;
>
> r = calloc (1, sizeof (Ecore_X_Reply_Get_Geometry));
> if (!r)
> {
> free (reply);
> return;
> }
>
> r->x = reply->x;
> r->y = reply->y;
> r->w = reply->w;
> r->h = reply->h;
> r->border = reply->border;
> r->depth = reply->depth;
>
> ecore_event_add (ECORE_X_REPLY_GET_GEOMETRY, r, NULL, NULL);
> ecore_xcb_cookie_remove (cookie);
> }
>
>
> /* like the events (see ecore_x.c or ecore_xcb.c), */
> /* if the fd receives data */
> /* (in _ecore_xcb_fd_handler ?) */
> /* or somewhere else ?? */
>
> Ecore_X_Cookie *cookie;
> void *reply;
>
> ecore_xcb_cookie_begin ();
> while (cookie = ecore_xcb_cookie_next())
> {
> if (xcb_poll_for_reply (_ecore_xcb_conn,
> cookie.cookie,
> &reply,
> NULL))
> cookie.reply (cookie);
> }
>
> [/code]
>
> what do you think of that code ?
>
> Vincent
>
> -------------------------------------------------------------------------
> 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
>
-------------------------------------------------------------------------
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
