[wpe-webkit] AArch64 builds in AUR

Andrea Giammarchi andrea.giammarchi at gmail.com
Thu Mar 21 12:23:20 PDT 2019 

Diego, `cog` looks fine now, and I've realized my wpewebkit-gl package
wasn't providing wpewebkit so, in case you tried above, please try again đź‘‹

On Thu, Mar 21, 2019 at 4:45 PM Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> Hi Diego, everything starts with (I guess) this:
>
> https://archlinuxarm.org/forum/viewtopic.php?f=65&t=13472&p=60754&hilit=S905x#p60754
>
> I don't have that board (although I have a C2 somewhere...) but basically,
> once you have ArchLinuxARM up and running, it's easy.
>
> I give you the TL;DR version of what to do, once ArchLinux boots (I am
> assuming you'll be using default `alarm` user).
>
> # from alarm user, go root (default pass is root)
> su
>
> # update all the things
> pacman-key --init
> pacman-key --populate archlinuxarm
> pacman -Syu
>
> # get out from root
> exit
>
> # install sudo if you don't have already
> bash <(curl -s archibold.io/install/sudo)
>
> # install utility to deal with AUR
> bash <(curl -s archibold.io/install/yay)
>
> # install my pre-built packages
> yay -S --needed --noconfirm cairo-glesv2-aarch64 wpewebkit-gl-aarch64
>
> # install other stuff
> yay -S --needed --noconfirm wpebackend-fdo weston
>
> # install codecs for videos and stuff (note, there's also non FOSS in this
> list)
> yay -S --needed
> --noconfirm gst-plugins-base gst-plugins-good gst-plugins-ugly gst-plugins-bad
> gstreamer-vaapi gst-libav
>
> # try to build cog (avoid no confirm flag in case it asks to import keys)
> yay -S --needed cog
>
> # if above fails, deal with cog
> yay -S --needed --noconfirm git
> git clone https://aur.archlinux.org/cog
> cd cog-git
>
> # edit the PKGBUILD file and remove the following:
> validpgpkeys=('5AA3BC334FD7E3369E7C77B291C559DBE4C9123B')
>
> # build the package
> makepkg -Asfc --needed --noconfirm
>
> # install it (needs whole name, press tab, instead of *, to have it)
> yay -U cog-git*
>
> # create a launcher
> echo '#!/usr/bin/env bash
> WEB_PAGE=https://duckduckgo.com
> WAYLAND_DISPLAY=wpe COG_PLATFORM_FDO_VIEW_FULLSCREEN=1 cog -P fdo $WEB_PAGE
> '>~/wpe
>
> # make it executable
> chmod a+x ~/wpe
>
> # prepare Weston
> mkdir -p ~/.config
> echo '[core]
> idle-time=0
>
> [shell]
> client=/home/alarm/wpe
> animation=none
> locking=false
> '>~/.config/weston.ini
>
> # that's it
>
> Now you can launch `weston --socket=wpe --width=1280 --height=720`, as
> example.
>
> If you want to force another full-screen resolution, I've used XWayland
> for that ... and here the extra instructions:
>
> # install stuff
> yay -S --needed --noconfirm xorg-server xorg-xinit xorg-xset xorg-xrandr
>
> # prepare Xorg
> echo 'xset s off -dpms
> xrandr -s 1280x720
> weston --socket=wpe --width=1280 --height=720'>~/.xinitrc
>
> You also need to add `xwayland=true` inside `~/.config/weston.ini` file,
> under `[core]` or after `idle-time=0`, or you can try passing the flag
> directly when you launch Weston in `.xinitrc` as in `weston --socket=wpe
> --xwayland --width=1280 --height=720`
>
> I haven't tried last but IIRC it should be the same.
>
> Try XWayland typing `startx`, and that's it.
>
> I hope it worked, I hope it helped. If it did, you just need to either
> create a systemd entry to start Weston or `/usr/bin/startx` automatically,
> or you can have automatic login and an entry in the ~/.bashrc file to
> startx right away on login.
>
> Regards.
>
>
> On Thu, Mar 21, 2019 at 3:32 PM Diego Moore <diego.moore at gmail.com> wrote:
>
>> Great news Andrea! I’ve been watching this closely…
>>
>> I have an interest in getting this tested on a S905x TV Box although I’m
>> new to both WPE and ArchLinux
>>
>> But if you can provide detailed instructions on how you got it up and
>> running on the RPi then maybe I can take it from there?
>>
>> Diego
>>
>> On 21 Mar 2019, at 13:27, Andrea Giammarchi <andrea.giammarchi at gmail.com>
>> wrote:
>>
>> *Finally 🎉*
>>
>> So, even if while building wpewebkit with canvas enabled it says that
>> cairo-gl cannot be found, enabling the canvas flag produced the expected
>> result, but only after building cairo-git package with --enable-glesv2
>>
>> yay -S cairo-glesv2-aarch64 wpewebkit-gl
>>
>> That's it, the canvas demo <https://smashcat.org/av/canvas_test/>
>> previously going between 5 and 8 FPS now reaches 35 FPS !!!
>>
>> Youtube also works like a charm, with video playing super smooth and *audio
>> over HDMI* (incredible, isn't it?)
>>
>> So, at the end of the day, this is the best kiosk experience ever for
>> Raspberry Pi 3
>>
>> *Still Missing ?*
>>
>>    - *cog* pgp key is still invalid. I might just end up publishing yet
>>    another pre-built package but I think that'd be superfluous since
>>    wpebackend-fdo, libwpe, and cog, builds in a couple of minutes
>>    - apparently to enable the touch screen I need some special kernel
>>    ... will eventually let you know how that went. However, it'd still be
>>    awesome if a mouse could be enabled (for debugging sake)
>>    - I'd like to be notified when wpewebkit gets updated in AUR. I'm not
>>    sure I could just follow the package, but any ping would be appreciated.
>>
>>
>> Thanks for your patience !!! It's been bumpy, but overall nice
>> experience, and I'm excited by how well this kiosk mode performs at 720p !
>>
>>
>>
>> On Thu, Mar 21, 2019 at 12:35 PM Andrea Giammarchi <
>> andrea.giammarchi at gmail.com> wrote:
>>
>>> Sorry for keep bothering Adrian, but I'm in a loop.
>>>
>>> I've realized that WPE doesn't find cairo-gl even if I build, and
>>> install, cairo with either -gl or -gles enabled.
>>>
>>> Moreover, if I pass -DENABLE_GLES2 via WPE package build it ignores the
>>> flag.
>>>
>>> In few words, it looks like I'm incapable of accelerating the 2D canvas,
>>> which is a bummer.
>>>
>>> Any help appreciated, thanks.
>>>
>>>
>>>
>>> On Thu, Mar 21, 2019 at 10:58 AM Andrea Giammarchi <
>>> andrea.giammarchi at gmail.com> wrote:
>>>
>>>> In case anyone would like to try, `pacman -U xxx` would install either
>>>> cairo-gl or wpewebkit-gl, however the canvas demo has zero performance
>>>> improvement over regular wpewebkit, so I am going to try build all the
>>>> things via glesv2 instead.
>>>>
>>>> archibold.io/releases/cairo-gl-aarch64-1.17.2.pkg.tar.xz
>>>> archibold.io/releases/wpewebkit-gl-aarch64-2.22.5.pkg.tar.xz
>>>>
>>>> Regards
>>>>
>>>> On Thu, Mar 21, 2019 at 6:29 AM Andrea Giammarchi <
>>>> andrea.giammarchi at gmail.com> wrote:
>>>>
>>>>> Yet another update.
>>>>>
>>>>> I am using XWayland so that I can use xrandr and force/set 1280x720
>>>>> resolution.
>>>>>
>>>>> Using COG_VIEW_FULLSCREEN=1 (can't remember the whole name) does the
>>>>> trick, however some demo still reports 1024x1024 resolution, even if I'm
>>>>> pretty sure it is actually 1280x720 (no borders, everything centered ...
>>>>> must be!)
>>>>>
>>>>> I believe things are working fine, 'cause I can see this demo at 25fps
>>>>> on the Pi3
>>>>> https://webglsamples.org/dynamic-cubemap/dynamic-cubemap.html
>>>>>
>>>>> However, the canvas 2D demo goes 8fps, so now I'm building
>>>>> cairo-gl-aarch64 and will build wpewebkit-gl-aarch64 too, but I still
>>>>> wonder if instead I should use GLESV2 for both builds instead.
>>>>>
>>>>> In that case I'd go packaging cairo-glesv2-aarch64 and
>>>>> wpewebkit-glesvs-aarch64 but I'd like to be sure that's needed.
>>>>>
>>>>> Youtube doesn't show much ... every video I've tried so far seems to
>>>>> be not supported. This might be some missing codec in my ArchLinux thuogh.
>>>>>
>>>>> Last, but not least, the official LCD touch screen doesn't seem to
>>>>> work at all in aarch64 so, since there is no mouse whatsoever in WPE, I'm
>>>>> basically incapable of interacting at all with anything shown on the
>>>>> screen: bummer.
>>>>>
>>>>> Thanks in advance for any sort of help/hint/thoughts.
>>>>>
>>>>> Best Regards.
>>>>>
>>>>> On Wed, Mar 20, 2019 at 1:59 PM Andrea Giammarchi <
>>>>> andrea.giammarchi at gmail.com> wrote:
>>>>>
>>>>>> wpewebkit-aarch64 landed on AUR
>>>>>> https://aur.archlinux.org/packages/wpewebkit-aarch64/
>>>>>>
>>>>>> last doubts in the forum, but basically I have all the pisces to keep
>>>>>> updating/maintaining this module.
>>>>>>
>>>>>> My previous questions stands, but I think the current status is
>>>>>> definitively great, compared to not having any pre built wpewbekit at all.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 18, 2019 at 1:59 PM Andrea Giammarchi <
>>>>>> andrea.giammarchi at gmail.com> wrote:
>>>>>>
>>>>>>> P.S. the pop key used in current cog is not valid anymore or it
>>>>>>> cannot be imported:
>>>>>>> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=cog
>>>>>>>
>>>>>>> I've also tried to build from cog-git but it cannot find wpe.h ...
>>>>>>> checking out cog-2.0 branch works without issues.
>>>>>>>
>>>>>>> I've also made some progress with the package, I just need to
>>>>>>> re-package it and see how it works.
>>>>>>>
>>>>>>>
>>>>>>> https://archlinuxarm.org/forum/viewtopic.php?f=65&t=13469&p=60812#p60812
>>>>>>>
>>>>>>> If you already have libwpe installed, do this in your RPi3:
>>>>>>>
>>>>>>> curl -LO archibold.io/releases/wpewebkit-aarch64-2.22.5.pkg.tar.xz
>>>>>>> $ sudo pacman -U wpewebkit-aarch64-2.22.5.pkg.tar.xz
>>>>>>>
>>>>>>> Best Regards
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Mar 17, 2019 at 2:29 PM Andrea Giammarchi <
>>>>>>> andrea.giammarchi at gmail.com> wrote:
>>>>>>>
>>>>>>>> Sorry for the late reply (I was without my PC/RPi3 this week)
>>>>>>>>
>>>>>>>> The good news is that somehow I managed to see something ...
>>>>>>>> however, if I start Weston fullscreen it crashes, every single time.
>>>>>>>> If I specify width, height of 1280x720 it crashes.
>>>>>>>> If I say nothing but --socket=wpe and then I cog duckduckgo it
>>>>>>>> shows a 1024x1024 duckduckgo experience, with no mouse showing up
>>>>>>>> whatsoever, but promising 10FPS on WebGL Aquarium at that resolution and
>>>>>>>> 500 fishes.
>>>>>>>>
>>>>>>>> The list of ugly bits I've not mentioned yet is here:
>>>>>>>>
>>>>>>>>    1. cog and cog-git requires wpewebkit ... building that package
>>>>>>>>    is a lottery. I'd be awesome to have a cog that doesn't strictly need
>>>>>>>>    wpewebkit and assumes it's already installed
>>>>>>>>    2. TinyWL builds and shows nothing. A grayish full screen
>>>>>>>>    (1080p) without duckduckgo in it. I am running from the terminal without
>>>>>>>>    any Weston session ever started. Not sure how to help debugging this
>>>>>>>>    3. however, since TinyWL is nowhere in AUR, I prefer using
>>>>>>>>    ArchLinux bricks so ... Weston is just fine. I'm using a weston.ini and
>>>>>>>>    beside the resolution gotcha, everything seems to work OK
>>>>>>>>    4. for some reason, my PC cannot build WPEWebKit anymore. It
>>>>>>>>    always fails at the last 111 files. I might have messed up something but
>>>>>>>>    ... bummer.
>>>>>>>>    5. there is a cairo-git that --enable-gl already, and I might
>>>>>>>>    use that one, but I believe it should also --enable-glesv2 ... is that
>>>>>>>>    correct?
>>>>>>>>
>>>>>>>> Best Regards
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Mar 12, 2019 at 10:52 AM Adrian Perez de Castro <
>>>>>>>> aperez at igalia.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On Thu, 7 Mar 2019 08:55:46 +0100, Andrea Giammarchi <
>>>>>>>>> andrea.giammarchi at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> > So, it built without issues. I've installed in a folder that I
>>>>>>>>> then copied
>>>>>>>>> > over the RPi3 and I can `weston --socket=wpe` but then I've no
>>>>>>>>> idea how to
>>>>>>>>> > test this.
>>>>>>>>> >
>>>>>>>>> > The build produces only a WPEWebDriver binary, but there's no
>>>>>>>>> trace of the
>>>>>>>>> > `run-minibrowser` as explained in the GitHub page:
>>>>>>>>> > https://github.com/WebPlatformForEmbedded/WPEWebKit#running
>>>>>>>>> >
>>>>>>>>> > I've followed these instructions:
>>>>>>>>> > https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=wpewebkit
>>>>>>>>>
>>>>>>>>> The MiniBrowser is only built by default for developer builds, and
>>>>>>>>> if
>>>>>>>>> you want to compile it as part of a normal build you will need to
>>>>>>>>> pass
>>>>>>>>> “-DENABLE_MINIBROWSER=ON” to CMake.
>>>>>>>>>
>>>>>>>>> For general use I would recommended a WPE “launcher”, which is how
>>>>>>>>> we call
>>>>>>>>> minimal browsers with (almost) no UI. A good option is using Cog,
>>>>>>>>> because it
>>>>>>>>> is maintained and some people are already using it in their
>>>>>>>>> solutions. There
>>>>>>>>> are PKGBUILDs for it available:
>>>>>>>>>
>>>>>>>>>    https://aur.archlinux.org/packages/cog/
>>>>>>>>>    https://aur.archlinux.org/packages/cog-git/
>>>>>>>>>
>>>>>>>>> I have pushed updates to mark these two as buildable on AArch64 as
>>>>>>>>> well.
>>>>>>>>>
>>>>>>>>> > Anyway, since it builds without issues, do you mind flagging AUR
>>>>>>>>> wpewebkit
>>>>>>>>> > compatible with aarch64 too, so that when I chroot with my PC I
>>>>>>>>> can just
>>>>>>>>> > use yaourt (or others) to build it without needing any manual
>>>>>>>>> step?
>>>>>>>>>
>>>>>>>>> Done, I think all the needed parts (libwpe, wpebackend-fdo,
>>>>>>>>> wpewebkit, and
>>>>>>>>> cog) are now marked as available on aarch64.
>>>>>>>>>
>>>>>>>>> > If you have any hint/idea on how to test/use the build, once
>>>>>>>>> succeeded,
>>>>>>>>> > please share, thank you.
>>>>>>>>>
>>>>>>>>> Once you have Cog built and installed, and a compositor (like
>>>>>>>>> Weston)
>>>>>>>>> running, the following should work:
>>>>>>>>>
>>>>>>>>>    % WAYLAND_DISPLAY=wpe cog -P fdo https://duckduckgo.com
>>>>>>>>>
>>>>>>>>> (Of course, change the value of “WAYLAND_DISPLAY” to the socket
>>>>>>>>> name you
>>>>>>>>> have passed to Weston when starting it). If you want a compositor
>>>>>>>>> which is
>>>>>>>>> smaller than Weston, a good starting point to build upon would be
>>>>>>>>> TinyWL
>>>>>>>>> (which is part of wlroots):
>>>>>>>>>
>>>>>>>>>    https://github.com/swaywm/wlroots/tree/master/tinywl
>>>>>>>>>
>>>>>>>>> I have successfully used TinyWL with the Cog window in fullscreen
>>>>>>>>> mode, with
>>>>>>>>> a command like the following (make sure you are NOT running Weston
>>>>>>>>> at the
>>>>>>>>> same time):
>>>>>>>>>
>>>>>>>>>    COG_PLATFORM_FDO_VIEW_FULLSCREEN=1 \
>>>>>>>>>        tinywl -s 'cog -P fdo https://duckduckgo.com'
>>>>>>>>>
>>>>>>>>> (In this case you don't need to define the “WAYLAND_DISPLAY”
>>>>>>>>> environment
>>>>>>>>> variable, because TinyWL already takes care of that.)
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -Adrián
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> > On Wed, Mar 6, 2019 at 11:33 PM Andrea Giammarchi <
>>>>>>>>> > andrea.giammarchi at gmail.com> wrote:
>>>>>>>>> >
>>>>>>>>> > > 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
>>>>>>>>> > >>>
>>>>>>>>> > >>
>>>>>>>>> Non-text part: text/html
>>>>>>>>>
>>>>>>>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> webkit-wpe mailing list      (webkit-wpe at lists.webkit.org)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.webkit.org/mailman//listinfo/webkit-wpe
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-wpe/attachments/20190321/1ac7ea1f/attachment-0001.html>

More information about the webkit-wpe mailing list