Hi, in the process of porting webkitgtk+ to wayland and following advise provided here, I implemented a nested compositor to share surfaces between the two processes that do the rendering. This works fine with a single widget/surface, but things get a bit more complicated when dealing with various widgets (browser tabs, windows).
I am trying to understand if I can solve my problem, which is basically a problem of matching wayland surfaces created in the nested compositor with their corresponding widgets in the UI, within the scope of the wayland protocol or if I need to resort to ad-hoc communications between the two processes outside the protocol. Below I describe the problem in more detail together with the possible solutions I looked into and my conclusions. I'd appreciate a lot if someone could confirm whether these are correct: As far as I understand the code in the nested client example from Weston, when there is need to repaint the UI it goes through all the surfaces in the compositor and paints them one by one. In our case, when GTK needs to repaint it will go through the widgets in the UI and ask them to repaint as needed. This means that we need to know, for a given widget, which is the surface in the nested compositor that provides the contents for it. However, when the nested compositor receives a request to create a surface it will not know for which widget it is creating it (obviously information on things like UI widgets is outside the scope of the wayland protocol), and as far as I can see, there is no way for the client to provide this info to the compositor either when the surface is created or after it has been created. Assuming that this is not something I can so using available APIs, I looked into adding this API to my nested compositor implementation, so I can have a surface constructor like this: wl_compositor_create_surface_for_widget(struct wl_compositor*, int); where that additional 'int' parameter would be used on the compositor's side to associate the new surface with a specific UI widget. Unfortunately, for this I would really want to reuse existing code and APIs from wayland to do message communication between client and compositor, but a good part of this is private to wayland (the wl_closure stuff for example) so it feels like I would end up having to duplicate quite some code from Wayland in WebKit, which I think is really not a good idea. Also, the fact that these APIs have been kept internal to Wayland means that this is not something that developers are expected to do. If the above is not a good solution either, I understand there would be no solution for my problem within the wayland protocol and I would need to add additional messages between the two processes outside the protocol after the surface is created in order to associate the surface and the widget on the compositor's side. In that case, I would need to communicate the widget ID and the ID of the Wayland object representing the surface (which I understand I'd get by calling wl_proxy_get_id on the client for the surface). Is my analysis of the problem correct or is there some way in which I can achieve my objective within the wayland protocol? Iago _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
