https://bugzilla.gnome.org/show_bug.cgi?id=774534
Emmanuele Bassi (:ebassi) <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #6 from Emmanuele Bassi (:ebassi) <[email protected]> ---
(In reply to Olivier Fourdan from comment #4)
> (In reply to Matthias Clasen from comment #3)
> > I know there was irc discussion of this issue. What was the outcome ?
>
> Emmanuele pointed out we want people to use begin_paint()/end_paint(), but
> Clutter doesn't and this is precisely for clutter and its subsurface on
> Wayland.
Indeed, Clutter is "special" in that it assumes complete control over the
windowing system surface.
The main issue is that begin_draw_frame()/end_draw_frame() redirect rendering
to a Pixmap on X11, which is not a valid target for a GLX context, since we
cannot call glXSwapBuffers() on that intermediate buffer; for Wayland it's less
of a problem because the target is still going to be an EGL surface, and it's
assumed that all rendering is client-side. It may be interesting to just add
the begin_draw_frame()/end_draw_frame() calls when using the GDK backend on
Wayland, and see if that breaks everything or not.
The only other option would be to port Cogl and Clutter to use GdkGLContext,
and do their rendering on a separate FBO, but it would be a massive rework of
their internals, and it's something I'm not going to commit myself doing —
especially since applications are porting away from the whole Clutter API.
The path of least resistance is to update the input and opaque regions
immediately after changing them, but I'm not familiar enough with Wayland to
determine whether or not it's a good approach.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
wayland-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
