[Xcb] ecore and xcb: looking for advices.

[Ian Osgood]

On Mar 4, 2007, at 1:12 AM, Vincent Torri wrote:

>
> Hey,
>
> I would like some advices on what I should do about the xcb port of  
> ecore.
>
> * ecore_x:
>
> Raster wrote a wrapping of Xlib using ecore (a library similar to  
> glib). You can see the api here:
>
> http://e.kevb.net/cgi-bin/viewvc.cgi/e17/libs/ecore/src/lib/ecore_x/ 
> Ecore_X.h?revision=1.182&view=markup
>
> it has been written before raster was aware of xcb, and it follows  
> mainly Xlib api.
>
> * ecore_xcb:
>
> I've written an xcb port of ecore_x, and it mainly wraps xcb.  
> Problem: its api is quite different from the one of ecore_x, and  
> raster would prefer to keep ecore_x api. His point is: we add some  
> functions specific to xcb (the methods that send the requests, and  
> maybe some functions to get/free the replies). The advantage:  
> modifying programs (mainly e17 and toolkits like etk or ewl) would  
> be a minor tasks: we send all the needed requests (with the added  
> methods), we use the current ecore_x methods (with the modified  
> ecore_x methods, which would get the replies), and we free the  
> replies with the added methods.

It sounds like raster wants to ensure current code still works. In  
other words, ecore_xcb would support the xlib synchronous API as well  
as extra xcb asynchronous methods.  I think that is a worthwhile goal.

>
> Simple example with current code:
>    ecore_x_pointer_xy_get(win, &x1, &y1);
>    atom = ecore_x_atom_get("toto");
>
> Wanted code:
>    /* added functions: we send all the needed requests */
>    ecore_x_pointer_xy_get_request(win);
>    ecore_x_atom_get_request("toto");
>
>    /* existing but modified functions: we get the replies */
>    ecore_x_pointer_xy_get(win, &x1, &y1);
>    atom = ecore_x_atom_get("toto");

Seems good so far.  (XCB uses the word "prefetch" for the first call  
for similar cases, such as extension data.)

>
>    /* added functions: we free the replies */
>    ecore_x_pointer_xy_get_free(win);
>    ecore_x_atom_get_free(atom);

I don't think these would be necessary. Request cleanup would happen  
when you get the results.  It might mean a little extra copying if  
you return pointers directly into replys.

>
> I've not really thought about what the api could be. So the added  
> functions in the example might not be correct.
>
> I've never looked in details at Xlib/XCB, and I don't know if it  
> can help me for that kind of stuff.
>
> I already have an idea:
>
> * ecore_x_pointer_xy_get_request and ecore_x_atom_get_request would  
> store the cookie and a pointer to the corresponding reply function,  
> in an array. The size of the array is not huge. Except the  
> initialization of ecore_x(cb), I think that sending more than 16  
> requests is quite rare. If so, I will set the size of the array to  
> 16. If more than 16 requests are sent, I will resize the array.
>
> * ecore_x_pointer_xy_get and ecore_x_atom_get would call the reply  
> of each requests in the above array. Hence some of their arguments  
> would be useless. Of course, in that design, the order of the calls  
> is important.
>
> * the *_free functions would just be one function, actually. It  
> would just free all the replies available in the array.

I don't think storing the reply function pointer will be good enough,  
because you also need all the type information and request parameters  
that go along with it. I'm guessing what you really need to use is  
your own cache key based on both the request and the parameters (not  
so simple). What if the caller wants to get a bunch of atoms at once?  
There will be several atom_get cookies in your cache, each with  
different parameters.

So your reply cache interface would have to look something like this  
pseudocode:

ecore_x_pointer_xy_get_request(win)
{
	key = { ECORE_XCB_GET_XY, win }
	cookie = xcb_get_xy(conn, win)
	_cache_cookie(key, cookie)
}

ecore_x_pointer_xy_get(win, *x, *y)
{
	key = { ECORE_XCB_GET_XY, win }
	cookie = _uncache_cookie(key)
	if (!cookie)
		cookie = xcb_get_xy(conn, win)	// synchronous: old Xlib behaviour

	reply = xcb_get_xy_reply(cookie)
	*x = reply->x
	*y = reply->y
	free(reply)
}

This shows that the parameters you thought were useless actually  
*are* used to distinguish between the cookies from multiple requests.

The hard part is figuring out an efficient way to construct and use  
these cache keys, since the parameters to each request are different.

Another corner case: what if the user calls *_request and doesn't  
actually get the reply? Need some way to expire stuff out of the cache.

Ian

>
> Is that plan a good one ? Is there a better solution ? Remark that  
> I don't want to use the reply code in xcb-util, as it's not really  
> adapted to ecore_x design (it would waste some memory).
>
> thank you
>
> Vincent
>
> PS: nevertheless, I'll add my xcb port of ecore. It will be  
> separate from ecore_x, this one having or not the xcb support  
> described above.
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb
>