[wpe-webkit] AArch64 builds in AUR

[Andrea Giammarchi]

Quick update.

I've killed the crickets myself and moved forward
https://archlinuxarm.org/forum/viewtopic.php?f=65&t=13469#p60732

I have 16GB DDR4 through 6 cores + HT AMD Ryzen taking care of building
aarch64 via qemu-aarch-static and it seems like it's almost done (2428 out
of 2698)

It's taking a couple of hours so that's OK, but honestly I think it's
impossible to build this on an RPi3.

However, since I'm emulating aarch64 right away, it'd be great if you could
flag wpewebkit target architecture for aarch64 too, so I can simply use AUR
for everything.

The gotcha with arch-chrooting into aarch64 from x86_64 is that `sudo`,
which is kinda mandatory for any package operation, doesn't work due
numerous issues, so that I have to build Yaourt from scratch manually and
hope it'll manage to handle all packages (as it usually does even if not
maintained anymore).

*TL;DR* with my PC simulating aarch64 on a Raspberry Pi 3 image, I'm
confident we can deliver a pre-built wpewebkit to ArchLinuxARM via AUR 🎉

Now, back to the issues I've faced already:

   1. I cannot enable canvas indeed, 'cause cairo-gl is missing. By any
   chance we understand how Sam Decrock managed to enabled that
   <https://medium.com/@decrocksam/building-wpe-webkit-for-raspberry-pi-3-cdbd7b5cb362>
   ?
   2. is it OK for Igalia if I publish in AUR a pre built binary and
   maintain it? It means I need some ping, from time to time, when things
   change
   3. why wpebackend-fdo-git needs wpebackend-git,  but wpebackend-fdo doesn't
   ? anything special I should consider if I ever land such package in AUR?

Thanks for your help, patience, and possible outcome 👋




On Wed, Mar 6, 2019 at 1:44 PM Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> Unless the direct backend is notably faster, I think I'm fine with
> Wayland, also because I believe you need some compositor when you open, as
> example, the files explorer, so GTK on Weston would be just fine, right?
>
> Last question about the canvas:
>
> > Note that even with ENABLE_ACCELERATED_2D_CANVAS disabled, WebGL is
> always rendered by the GPU.
>
> One of the demo used in the WPE on Pi post benchmarks the canvas
> https://smashcat.org/av/canvas_test/ and I've seen it with my eyes it's
> indeed blazing fast compared to the regular canvas. I don't think it uses
> WebGL though, so I wonder if I am missing anything.
>
> So, how would I force-enable that ?
>
>
>
> On Wed, Mar 6, 2019 at 1:30 PM Adrian Perez de Castro <aperez at igalia.com>
> wrote:
>
>> Hello Andrea,
>>
>> On Wed, 6 Mar 2019 12:38:54 +0100, Andrea Giammarchi <
>> andrea.giammarchi at gmail.com> wrote:
>>
>> > Crickets so far ... btw, I'm going skiing for the Weekend so I'll try to
>> > build WPE directly on the Pi.
>> >
>> > Everything seems to work fine except ENABLE_ACCELERATED_2D_CANVAS AND
>> > ENABLE_ENCRYPTED_MEDIA are both OFF, while all others are ON.
>> >
>> > I am interested specially in the ENABLE_ACCELERATED_2D_CANVAS, why
>> wouldn't
>> > that work?
>>
>> ENABLE_ACCELERATED_2D_CANVAS is disabled by default because it uses
>> Cairo-GL,
>> which does not really work as well as you may imagine, and can be slower
>> in
>> some cases depending on many factors (including, but not limited to, the
>> GPU
>> being used). YMMV.
>>
>> Note that even with ENABLE_ACCELERATED_2D_CANVAS disabled, WebGL is always
>> rendered by the GPU.
>>
>> > Also I have another question: is wpebackend preferred over
>> wpebackend-fdo ?
>> > Latter seems for Wayland, which I'm OK with, but not sure it performs
>> any
>> > better than the former.
>>
>> The “wpebackend” package is deprecated and has been replaced by “libwpe”
>> (the name was confusing, because “wpebackend” was not a backend: it was
>> just a library used to implement and use backends).
>>
>> An alternative WPE backend that works for the Raspberry Pi is the RDK
>> backend
>> [1] when built passing “-DUSE_BACKEND_BCM_RPI=ON” to CMake.
>>
>> Note that I have not been using the RDK backend myself so I cannot
>> comment on
>> its status, and that's the reason why I have not submitted an AUR package
>> for
>> it — but should work, with the advantage that a Wayland compositor is not
>> needed, but with the limitations that only one Web view can be created,
>> and
>> that it uses the 32-bit Raspberry Pi userland libraries (which cannot be
>> built
>> in 64-bit mode [2]).
>>
>> > Thanks again for extra clarifications.
>>
>> Happy to help :)
>>
>> -Adrián
>>
>> ---
>> [1] https://github.com/WebPlatformForEmbedded/WPEBackend-rdk
>> [2] https://github.com/raspberrypi/userland/issues/314
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-wpe/attachments/20190306/b95e09f4/attachment.html>