[Webkit-unassigned] [Bug 211021] [GTK4][Wayland] Add support for rendering web view contents

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=211021

Adrian Perez <aperez at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aperez at igalia.com
 Attachment #397563|review?                     |review+
              Flags|                            |

--- Comment #3 from Adrian Perez <aperez at igalia.com> ---
Comment on attachment 397563
  --> https://bugs.webkit.org/attachment.cgi?id=397563
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=397563&action=review

Looks good overall, I have left a few comments but nothing that should prevent landing.

> Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp:606
> +    gtk_widget_set_vexpand(viewWidget, TRUE);

Wouldn't we also want a call to gtk_widget_set_hexpand(viewWidget, TRUE) here?
In general we want the web view to take as much space as possible inside its
continer, in both directions, unless I am missing something.

> Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp:754
> +    *minimumSize = 0;

Is it really useful to have zero as the minimum size? I know that using zero as
minimum is the current behaviour for GTK3 as well, but it strikes me as odd because
that can lead to situations like having a simple window without window controls
and only a web view inside having a 0×0 size if gtk_window_set_default_size() was
not called on the window—and that seems… bad?

This is more of a doubt I have than a request to change the minimum size, so feel
free to ignore this comment :]

> Source/WebKit/UIProcess/gtk/AcceleratedBackingStoreWayland.cpp:222
> +#endif

We could have a WebCore::gtkCreateGLContext() helper function in GtkUtilities.{h,cpp}
to avoid the #ifdefs here.

> Source/WebKit/UIProcess/gtk/AcceleratedBackingStoreWayland.cpp:362
>      glDeleteFramebuffers(1, &fb);

Unrelated to this patch, but maybe worth mentioning: There is no need to create
and delete the FBO every time this function is called, it could be created the
first time it's needed and reused aftwerwards (binding-unbinding is still neded,
of course).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200427/02e115ab/attachment.htm>