[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

--- Comment #5 from Carlos Garcia Campos <cgarcia 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

Thanks!

>>> 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.
> 
> It's been a long time since I wrote any GTK+ widget, so take this with a grain of salt. But the idea is that for widgets there's a natural direction of expansion. In the case of the webview, that would be vertical (as that's how usually the content flow for webpages goes). Horizontal expansion is not necessarily wanted, that depends on what horizontal siblings the widget has and how the application wants to distribute the space between them.
> 
> This can be of course overriden by the application developers, just like with any widget.

I added this here because I was getting always a 0 height in size allocate. But it seems to be because there's no gtk_box_pack APIs in GTK4, that received the expand property. Now we use gtk_container_add() so we need to call set_vexpand to get the same as pack. So, I'll move this to the MiniBrowser instead.

>> 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.

It's just one line and only used here. We could move it to a helper, but here, not in WebCore.

>> 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).

This is fallback code that isn't used in most of the cases. In any case, it's existing code, so any optimization can be done in a separate bug.

-- 
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/20200428/eb2b6e6a/attachment-0001.htm>