If it's about WebKitGTK+ performance I agree but if it's about GJS, running same exact code via Python GTK+ works without core dumps.
GJS: https://github.com/WebReflection/benja/blob/gh-pages/os/gjs/browse Python: https://github.com/WebReflection/benja/blob/gh-pages/os/gjs/browse.py Best Regards On Mon, Aug 14, 2017 at 12:28 AM, <philip.chime...@gmail.com> wrote: > Hi Andrea, > > I'd recommend asking about the problems with webkitgtk on their mailing > list. They might be able to help figure out what's missing. > > Regards, > Philip C > > On Thu, Aug 3, 2017 at 10:59 AM Andrea Giammarchi < > andrea.giammar...@gmail.com> wrote: > >> So, it looks like on ArchLinux aarch64 (ARMv8 64bit) there's a `js38` >> package but it's not directly usable, it's just a gjs dependency: >> https://archlinuxarm.org/packages/aarch64/gjs >> >> However, it looks like pretty much everything I've tried on aarch64 >> platform is broken, everything but Weston/Wayland, beside the fact that as >> soon as I reach the top left corner the Raspberry Pi crashes ... and I have >> similar Shenanigans with GNOME on an Asrock D1800M with an embedde Celeron. >> >> Regardless, I've meanwhile betrayed GTK+ with QtWebEngine and realized Qt >> also doesn't work on aarch64 >> >> TL;DR it looks like aarch64 is in a very unstable stage and bugs to >> report everywhere would be so many I'd ask vacations just to file them. >> >> Not what I am meant to spend my time right now, apologies. >> >> However, if this is of any interest to anyone: >> >> 1. WebKitGTK+ is very slow to bootstrap compared to both Electron and >> WtEbEngine (Chromium based) >> 2. even enabling all the settings via GJS it doesn't provide Hardware >> acceleration like Chromium based alternative do >> 3. I can watch Full HD Youtube videos on a Raspberry Pi 2 via >> QtWebEngine, **no way** I can do the same with WebKitGTK+ >> >> The current state of WebKitGTK+ on platforms where it's most compatible >> is very sad, if it's extremely inferior in terms of performance in the most >> common SBC such Raspberry Pi, I wonder how come it's deployed so much even >> on ARMv6 (ARMv11) 'cause it's very greedy on RAM too. >> >> Apologies for the rant, it's just 3 days I'm trying to watch a bloody Web >> video through an SBC that is fully HW accelerated by Mesa and OSS. >> >> Best Regards >> >> On Thu, Aug 3, 2017 at 12:41 AM, <philip.chime...@gmail.com> wrote: >> >>> Hi Andrea, >>> >>> Thanks for reporting this in any case! Would you mind opening a bug on >>> bugzilla.gnome.org too so others can subscribe and/or suggest patches >>> there? >>> >>> I don't really have an aarch64 system to test anything on, so it's good >>> that you found this. Did you build mozjs38 yourself or use some >>> distribution's packaged version? What happens if you run mozjs's built-in >>> shell, does that work at all? (It's called "js38" and might be found in the >>> devel package) >>> >>> Regards, >>> Philip >>> >>> On Wed, Aug 2, 2017 at 5:16 PM Andrea Giammarchi < >>> andrea.giammar...@gmail.com> wrote: >>> >>>> Trying WebKitGTK+ bootstrapped by GJS on ArchLinux for ARM and >>>> everything is fine in both Raspberry Pi 0, 1, 2, and 3 ... but the 3 only >>>> if I run the ARMv7 (32bit) architecture. >>>> >>>> On ARMv8 (64bit) as soon as I type GJS I have a core-dumped with no >>>> other message whatsoever. >>>> >>>> Is this a known issue? >>>> >>>> $ gjs --version >>>> gjs 1.48.6 >>>> >>>> $ uname -a >>>> Linux alarm 4.12.4-1-ARCH #1 SMP Thu Jul 27 21:54:16 MDT 2017 aarch64 >>>> GNU/Linux >>>> >>>> >>>> $ gjs --verbose >>>> (gjs:425): Gjs-ERROR **: option parsing failed: Unknown option --verbose >>>> Trace/breakpoint trap (core dumped) >>>> >>>> $ gjs >>>> Segmentation fault (core dumped) >>>> >>>> >>>> >>>> journalctl -xe shows these errors: >>>> >>>> Process 425 (gjs) of user 1000 dumped core. >>>> >>>> Stack trace of thread 425: >>>> #0 0x0000fffbe0f01950 >>>> raise (libc.so.6) >>>> #1 0x0000fffbe0f018dc >>>> raise (libc.so.6) >>>> #2 0x0000fffbe1224e20 >>>> g_log_default_handler (libglib-2.0.so.0) >>>> #3 0x0000fffbe1225020 >>>> g_logv (libglib-2.0.so.0) >>>> #4 0x0000fffbe122523c >>>> g_log (libglib-2.0.so.0) >>>> #5 0x000000000040187c >>>> main (gjs-console) >>>> #6 0x0000000000401df8 >>>> _start (gjs-console) >>>> #7 0x0000000000401df8 >>>> _start (gjs-console) >>>> -- Subject: Process 425 (gjs) dumped core >>>> >>>> >>>> >>>> Process 433 (gjs) of user 1000 dumped core. >>>> >>>> Stack trace of thread 433: >>>> #0 0x0000ffff753771f8 n/a >>>> (libmozjs-38.so) >>>> #1 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #2 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #3 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #4 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #5 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #6 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #7 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #8 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #9 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #10 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #11 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #12 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #13 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #14 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #15 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #16 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #17 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #18 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #19 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #20 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #21 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #22 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #23 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #24 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #25 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #26 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> #27 0x0000ffff765c06c0 n/a >>>> (linux-vdso.so.1) >>>> >>>> Stack trace of thread 434: >>>> #0 0x0000ffff74f8d3a0 >>>> pthread_cond_wait@@GLIBC_2.17 (libpthread.so.0) >>>> #1 0x0000ffff741443ac >>>> PR_WaitCondVar (libnspr4.so) >>>> #2 0x0000ffff741443ac >>>> PR_WaitCondVar (libnspr4.so) >>>> #3 0x0000ffff756778d4 n/a >>>> (libmozjs-38.so) >>>> #4 0x0000ffff7414a708 n/a >>>> (libnspr4.so) >>>> #5 0x0000ffff74f86ffc >>>> start_thread (libpthread.so.0) >>>> #6 0x0000ffff75f8f9ec >>>> thread_start (libc.so.6) >>>> >>>> Stack trace of thread 435: >>>> #0 0x0000ffff74f8d3a0 >>>> pthread_cond_wait@@GLIBC_2.17 (libpthread.so.0) >>>> #1 0x0000ffff741443ac >>>> PR_WaitCondVar (libnspr4.so) >>>> #2 0x0000ffff741443ac >>>> PR_WaitCondVar (libnspr4.so) >>>> #3 0x0000ffff756778d4 n/a >>>> (libmozjs-38.so) >>>> #4 0x0000ffff7414a708 n/a >>>> (libnspr4.so) >>>> #5 0x0000ffff74f86ffc >>>> start_thread (libpthread.so.0) >>>> #6 0x0000ffff75f8f9ec >>>> thread_start (libc.so.6) >>>> >>>> Stack trace of thread 437: >>>> #0 0x0000ffff74f8d3a0 >>>> pthread_cond_wait@@GLIBC_2.17 (libpthread.so.0) >>>> #1 0x0000ffff741443ac >>>> PR_WaitCondVar (libnspr4.so) >>>> #2 0x0000ffff741443ac >>>> PR_WaitCondVar (libnspr4.so) >>>> #3 0x0000ffff756778d4 n/a >>>> (libmozjs-38.so) >>>> #4 0x0000ffff7414a708 n/a >>>> (libnspr4.so) >>>> #5 0x0000ffff74f86ffc >>>> start_thread (libpthread.so.0) >>>> #6 0x0000ffff75f8f9ec >>>> thread_start (libc.so.6) >>>> #0 0x0000ffff74f8d3a0 pthread_cond_wait@@GLIBC_2.17 (libpthread.so.0) >>>> #1 0x0000ffff741443ac >>>> PR_WaitCondVar (libnspr4.so) >>>> #2 0x0000ffff741443ac >>>> PR_WaitCondVar (libnspr4.so) >>>> #3 0x0000ffff756778d4 n/a >>>> (libmozjs-38.so) >>>> #4 0x0000ffff7414a708 n/a >>>> (libnspr4.so) >>>> #5 0x0000ffff74f86ffc >>>> start_thread (libpthread.so.0) >>>> #6 0x0000ffff75f8f9ec >>>> thread_start (libc.so.6) >>>> >>>> Stack trace of thread 438: >>>> #0 0x0000ffff74f8d3a0 >>>> pthread_cond_wait@@GLIBC_2.17 (libpthread.so.0) >>>> #1 0x0000ffff741443ac >>>> PR_WaitCondVar (libnspr4.so) >>>> #2 0x0000ffff741443ac >>>> PR_WaitCondVar (libnspr4.so) >>>> #3 0x0000ffff756778d4 n/a >>>> (libmozjs-38.so) >>>> #4 0x0000ffff7414a708 n/a >>>> (libnspr4.so) >>>> #5 0x0000ffff74f86ffc >>>> start_thread (libpthread.so.0) >>>> #6 0x0000ffff75f8f9ec >>>> thread_start (libc.so.6) >>>> >>>> Stack trace of thread 441: >>>> #0 0x0000ffff74f8d3a0 >>>> pthread_cond_wait@@GLIBC_2.17 (libpthread.so.0) >>>> #1 0x0000ffff741443ac >>>> PR_WaitCondVar (libnspr4.so) >>>> #2 0x0000ffff741443ac >>>> PR_WaitCondVar (libnspr4.so) >>>> #3 0x0000ffff756778d4 n/a >>>> (libmozjs-38.so) >>>> #4 0x0000ffff7414a708 n/a >>>> (libnspr4.so) >>>> #5 0x0000ffff74f86ffc >>>> start_thread (libpthread.so.0) >>>> #6 0x0000ffff75f8f9ec >>>> thread_start (libc.so.6) >>>> Process 433 (gjs) crashed and dumped core. >>>> >>>> >>>> >>>> >>>> Thanks in advance for any sort of outcome. >>>> _______________________________________________ >>>> javascript-list mailing list >>>> javascript-list@gnome.org >>>> https://mail.gnome.org/mailman/listinfo/javascript-list >>>> >>> >>
_______________________________________________ javascript-list mailing list javascript-list@gnome.org https://mail.gnome.org/mailman/listinfo/javascript-list
