On Mon, 16 Apr 2007 23:38:36 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]> babbled:
> > > On Mon, 16 Apr 2007, Brian Mattern wrote: > > > On Mon, Apr 16, 2007 at 10:07:37PM +0200, Vincent Torri wrote: > > > > in that case, could you wrap up the _fetch() call into the _get() one, > > and get rid of the global that stores the reply between the two calls? > > no, I can't, because some ecore_x call might need the same reply. For > example ecore_x_drawable_geometry_get and > ecore_x_drawable_border_width_get (iirc the names). If I put the _fetch > into the reply, then there would be one round trip if someone wants to get > the geometry and the reply of the same drawable. > > One solution would be to provide a function that returns all the > properties a reply can give. > > > The problem i see is that for prefetch to really serve any purpose, the > > code has to hit the event loop between prefetch and fetch/get. It will > > be hard to guarantee that no code gets called in between that does a > > full prefetch/fetch/get cycle (which would then be out of order). > > > > I haven't looked at xcb's api, but what are the cookies for if not to > > allow one to fetch in a different order than prefetched? > > XCB just do the minimal thing: it sends data to the X server and gets data > from the X server. It does not store a list of requests/replies. > > I already asked that question (the order of requests/replies) to XCB devs > 2 years ago, btw. X protocol - by definition, guarantees order of operation for 1 client connection. 1 request will get a reply before they next request gets its reply. that is a guarantee in the protocol - no need for xcb to do it. as i said before - the easiest places for xcb to go into ecore_x right now is in adding NEW functions like ecore_x_window_prop_properties_get(Ecore_X_Window win, int count, Ecore_X_Atom *properties, Ecore_X_Atom types, int sizes, unsigned char ***datas, int **nums) that would fetch 'count' properties from a window in 1 round trip instead of 'count' round trips. ecore_x_window_prop_property_get_prefetch() i would simplify to sending the xcb request and then when it arrives produce an ECORE_X_REPLY_WINDOW_PROPERTY event - the event would contain the contents of the reply (when it comes in). the xlib implementation of that cal would do the round-trip property get and then post an event so you pay a round-trip cost anyway, but the reply it just deferred onto the end of the event queue. the above will not break current api, will give benefits in avoiding round-trips, and be simple to maintain and implement. apps would need to use the new calls to get a benefit - but that is to be expected. the point is - that if xcb doesn't exist - they still work just fine using xlib. no #ifdef's in apps. > Vincent > > ------------------------------------------------------------------------- > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- 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
