On Wed, 2 Jan 2008, Nathan Ingersoll wrote:
> I think this looks very reasonable. Were you able to verify with the
> XCB devs that we can poll on the cookies like this?
They didn't answer me yet. Maybe they are on holydays :)
Vincent
> 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
