If I understand correctly, you want to
1) create that api for the XCB backend: _prefetch, _fetch and
_response
2) for the Xlib backend, to add _response, which would in fact be the
current _get function
3) the _get data be for both backend :
***_get (***)
{
***_prefetch(***); /* does nothing with Xlib backend*/
***_fetch(); /* idem */
***_response(***);
}
If so, there is indeed no api break, but you loose the benefits of xcb.
Then, I would say : why using xcb ? Except for the initialisation of
a prog which is a bit faster (~1E-3 vs ~1E-2 s. on my computer), but those
numbers are too small for a real gain. Only the use of a prog over ssh
would show a real gain with xcb.
raster asked me to keep the current api while adding some functions
specifically for xcb. So that you can use xcb benefits by adding some
functions. It's an api break, I agree. But I followed ecore's owner wishes
;)
What you propose is : to really have the benefits of XCB, use another api.
If so, I would have committed a real xcb port of ecore_x, with a
completely different api :)
Remark : there is currently a way to know if xcb is used or not : I added
to the CFLAGS returned by pkg-config -DHAVE_ECORE_X_XCB. With the current
code, to use xcb backend, you actually have to use that macro.
Vincent
On Mon, 16 Apr 2007, Nathan Ingersoll wrote:
Nice work Vincent. As we discussed on IRC, there are a few changes to
the API I would like to propose to reduce the differences between the
two engines (Xlib or XCB) as it becomes more complete.
This change introduces some slightly different calling conventions to
ecore_x, which I would consider an API break. Code that previously
called a _get function must now call a series of functions, ie.
_prefetch, _fetch, _get. While these first two functions are empty
under the Xlib build, any code using the ecore_x API will need them to
be sure that it will work regardless of how the user builds ecore_x.
This is not really an issue now, since the XCB code isn't complete yet
and there will be breaks in certain code portions, but it could cause
confusion later when it is more complete.
To help the discussion, here is a quick example of the differences.
Current calls to retrieve window geometry:
ecore_x_window_geometry_get
XCB supported version:
ecore_x_window_geometry_get_prefetch
ecore_x_window_geometry_get_fetch
ecore_x_window_geometry_get
Because the _prefetch and _fetch calls are empty when the Xlib backend
is built, the Xlib backend works fine when you add the XCB related
calls. Unfortunately, the XCB backend requires them for the _get to
succeed. Since the the calling code has no way to identify which
engine is in use, all of it's code needs to be ported to the new
calling sequence for it's current behavior to be guaranteed to work
still.
The main advantage of the XCB backend is that we have more flexibility
in reducing time spent waiting on round trip requests, and because of
that the API split makes sense the way it has been designed. Since we
have to update apps for XCB API compatibility, I think it would make
sense to split the API even more and maintain consistent behavior
across the two backends. To accomplish this, we could add one more API
call (open to naming suggestions): _get_response
This would essentially take the place of the _get call for the XCB
backend, and for the Xlib backend would involve renaming the _get
calls to be _get_response. With this addition, the _get calls would
then become identical across the two backends, they would simply be a
series like:
ecore_x_window_geometry_get_prefetch
ecore_x_window_geometry_get_fetch
ecore_x_window_geometry_get_response
This would allow us to maintain API compatibility with existing code
as well. Admittedly the old code would not get the benefit from the
XCB ability to schedule requests more efficiently, but until they
update to the new API they wouldn't have any benefit anyway.
Let me know if anything needs clarification.
Thanks,
Nathan
--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.
Message délivré par le serveur de messagerie de l'Université d'Evry.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
