Hi Jason, we have a single process managing all the tabs so this is not
an option in this case. Thanks for the suggestion though.
Regards,
Iago
On Thu, 2014-01-30 at 05:39 -0600, Jason Ekstrand wrote:
> Yeah, Pekka pretty much covered it. I've just got one more
> observation to add. Are you doin
On Thu, 2014-01-30 at 13:34 +0200, Pekka Paalanen wrote:
> On Thu, 30 Jan 2014 10:32:03 +0100
> Iago Toral wrote:
>
> > 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 proc
Yeah, Pekka pretty much covered it. I've just got one more observation to
add. Are you doing one process per tab? Or do you have one process
handling multiple tabs? If you have one process per tab, then you can
easily differentiate by which wl_client the surface is attached to. You
can know whi
On Thu, 30 Jan 2014 10:32:03 +0100
Iago Toral wrote:
> 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/surfa
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
