Otter Browser

If you’ve got plenty of spare ram for a big enough ram disc change the !Run file to e.g.

Run <Otter-browser$Dir>.otter-browser --cache=/RAM::RamDisc0.$/cache ><Otter-browser$Dir>.debug 2>&1

The folder will be automatically created. Page loading will then be much faster.

Thanks very much Chris. I’ve followed your instructions and got Otter working OK on my PandaBoard (non-ES). Indeed this post has been posted using the Otter browser.

I am running !UnixFC and !UnixFont from the RamDisc.

My RISC OS ROM needs updating as I do not have large RAM disc support enabled yet. So speed can only get better :-)

Ralph

I’ll have to throw in the towel here. Deleted SharedLibs and stuff (I need that ~170MiB), and couldn’t make a RAMdisc big enough anyway.
I look forward to trying Otter again when I get myself a Pi2 and have the resources to make it work. ;-)

Thanks for the advice about using the RAM disc. I enlarged the RAM disc to 128M and inserted into the !Run file extra lines to copy !UnixFC and !UnixFont there, and to filer_run !UnixFC.fc-cache. It all works very nicely. Most impressive. I have only just discovered that the lack of window furniture can be mitigated by SHIFT-mousing. I miss not being able to drag URL files to the address window. Am I right in thinking that the configuration-editor is not implemented yet? No doubt I will learn how to use more features with practice. Are there any docs about what, if anything, can be edited in !Otter-browser.resources.

Rick, you had better get yourself a Pi2! They are not hard on the purse.

you had better get yourself a Pi2!

otter-browser is running here on a 512MB Mk1 Pi. With all of its Shared Library dependencies it does use rather a lot of memory, it has used 110MB for DA’s in addition to its WimpSlot, very approximately it needs at least 128MB in total. Based on minimal experiece the RAM disc is required for an initial font cacheing but not thereafter. It’s all running from a 16GB SCSI Pen here. Having otter-browser’s cache on RAM disc may be of value and currently that stands at 13MB on a 128MB disc.

I have done the decent thing and used Otter for this reply.

Based on minimal experiece the RAM disc is required for an initial font cacheing but not thereafter.

Try docs.google.com. I was redirected to the Google login, and it tried to fetch from fonts.gstatic.com and then just froze everything for the time it took to have a bath and wash some clothes (maybe an hour and a half?). Don’t know how long it would have taken, I taskkilled it. Maybe placing the cache on RAMdisc would have sped things up. I don’t know, with SharedLibs and the huge amounts of memory required (not just the WimpSlot but numerous DAs), I just didn’t have enough free to allocate any useful size of RAMdisc. My Pi is only a 256MiB model (with ~32MiB reserved for the GPU).

Don’t worry. I’ll be back, as a guy way cooler than I’ll ever be once said. ;-)

Doesn’t work on my ARMx6. Debug file is as follows:

[create:124:tools/qdynamicarea.cpp] - RISC OS Error: Unable to allocate logical address space

Fatal signal received: Segmentation fault

Stack backtrace:

Running thread 0x5183d8 (Main Thread)
  ( 1007f34) pc: ecaf8564 lr: ecaf8980 sp:  1007f38  __write_backtrace()
  ( 1007fa0) pc: ecaf86b4 lr: ecafa538 sp:  1007fa4  __unixlib_raise_signal()
  ( 1007fb0) pc: ecafa3ec lr: ecb063f8 sp:  1006844  __h_cback()

  Register dump at 01007fb4:

    a1:     c008 a2:        0 a3:   5522d8 a4:    17fe0
    v1:   51b240 v2:   56a2b8 v3:   51b444 v4:        1
    v5: ecb063b4 v6:        0 sl:   f07208 fp:  100685c
    ip:        0 sp:  1006844 lr: ecb063f8 pc: ecb053a4
    cpsr: 60000110

  ecb05390 : ...ã : e3110001 : TST     R1,#1
  ecb05394 : .À”. : 0595c008 : LDREQ   R12,[R5,#8]
  ecb05398 : ..”. : 0595100c : LDREQ   R1,[R5,#12]
  ecb0539c : .ÀŴ. : 0581c008 : STREQ   R12,[R1,#8]
  ecb053a0 : ..…. : 058c100c : STREQ   R1,[R12,#12]
  ecb053a4 : .0ƒ. : 00833000 : ADDEQ   R3,R3,R0
  ecb053a8 : <.“å : e594103c : LDR     R1,[R4,#60]
  ecb053ac : ..Ŷå : e5850004 : STR     R0,[R5,#4]
  ecb053b0 : 4À✘â : e284c034 : ADD     R12,R4,#&34        ; ="4"

  ( 100685c) pc: ecb0532c lr: ecb063f8 sp:  1006860  free_unlocked()
  ( 1006874) pc: ecb063c0 lr: eb748b18 sp:  1006878  __free()
  ( 1006890) pc: eb748ac0 lr: eb748c30 sp:  1006894  QImageData::~QImageData()
  ( 10068a8) pc: eb748bd4 lr: eb78e19c sp:  10068ac  QImage::~QImage()
  ( 100695c) pc: eb78dc6c lr: eb789abc sp:  1006960  QPixmapIconEngine::addFile(QString const&, QSize const&, QIcon::Mode, QIcon::State)
  ( 10069ac) pc: eb789a44 lr: eb78a0d8 sp:  10069b0  QIcon::addFile(QString const&, QSize const&, QIcon::Mode, QIcon::State)
  ( 10069c8) pc: eb78a0a8 lr:    58c8c sp:  10069cc  QIcon::QIcon(QString const&)
  ( 1006db8) pc:    58afc lr:    3f28c sp:  1006dbc  Otter::Application::Application(int&, char**)
  ( 1006fec) pc:    3f250 lr: ecb0f304 sp:  1006ff0  main()

Doesn’t work on my ARMx6.

Looks like there is software running on your system that is reserving too much logical address space (aka dynamic areas).

You just need to make sure you quit any other programs that use dynamic areas. Once the ‘PMP’ changes filter through to the ARMx6 the problem should go away.

I have no problems with my ARMX6. Working stable and any testversion-problems are gone.
Thanks a lot.

Well, I’m waiting for it to launch under RPCemu (which is the fastest RISC OS box I have). Averaging 240 MIPS, it’s taken an hour so far and no sign of it completing loading.

I wonder how much of this time is the RTLD and how much is Qt/QML constructors before main() is called.

Well, I’m waiting for it to launch under RPCemu (which is the fastest RISC OS box I have). Averaging 240 MIPS, it’s taken an hour so far and no sign of it completing loading.

Tried on RPCEmu at the weekend and it takes a few minutes. I dumped everything in a large RAM disc.

It is a memory glutton though.

I’ve made a little progress. I no longer get a complaint about being unable to allocate logical address space, but I do get this instead:

Fatal signal received: Segmentation fault

Stack backtrace:

Running thread 0x5183d4 (Main Thread)
  ( 1007f34) pc: ce429564 lr: ce429980 sp:  1007f38  __write_backtrace()
  ( 1007fa0) pc: ce4296b4 lr: ce42b538 sp:  1007fa4  __unixlib_raise_signal()
  ( 1007fb0) pc: ce42b3ec lr: ce4373f8 sp:  1006844  __h_cback()

  Register dump at 01007fb4:

    a1:     c008 a2:        0 a3:   552260 a4:    17fe0
    v1:   51b23c v2:   56a240 v3:   51b440 v4:        1
    v5: ce4373b4 v6:        0 sl:   f07208 fp:  100685c
    ip:        0 sp:  1006844 lr: ce4373f8 pc: ce4363a4
    cpsr: 60000110

  ce436390 : ...ã : e3110001 : TST     R1,#1
  ce436394 : .À”. : 0595c008 : LDREQ   R12,[R5,#8]
  ce436398 : ..”. : 0595100c : LDREQ   R1,[R5,#12]
  ce43639c : .ÀŴ. : 0581c008 : STREQ   R12,[R1,#8]
  ce4363a0 : ..…. : 058c100c : STREQ   R1,[R12,#12]
  ce4363a4 : .0ƒ. : 00833000 : ADDEQ   R3,R3,R0
  ce4363a8 : <.“å : e594103c : LDR     R1,[R4,#60]
  ce4363ac : ..Ŷå : e5850004 : STR     R0,[R5,#4]
  ce4363b0 : 4À✘â : e284c034 : ADD     R12,R4,#&34        ; ="4"

  ( 100685c) pc: ce43632c lr: ce4373f8 sp:  1006860  free_unlocked()
  ( 1006874) pc: ce4373c0 lr: cd079b18 sp:  1006878  __free()
  ( 1006890) pc: cd079ac0 lr: cd079c30 sp:  1006894  QImageData::~QImageData()
  ( 10068a8) pc: cd079bd4 lr: cd0bf19c sp:  10068ac  QImage::~QImage()
  ( 100695c) pc: cd0bec6c lr: cd0baabc sp:  1006960  QPixmapIconEngine::addFile(QString const&, QSize const&, QIcon::Mode, QIcon::State)
  ( 10069ac) pc: cd0baa44 lr: cd0bb0d8 sp:  10069b0  QIcon::addFile(QString const&, QSize const&, QIcon::Mode, QIcon::State)
  ( 10069c8) pc: cd0bb0a8 lr:    58c8c sp:  10069cc  QIcon::QIcon(QString const&)
  ( 1006db8) pc:    58afc lr:    3f28c sp:  1006dbc  Otter::Application::Application(int&, char**)
  ( 1006fec) pc:    3f250 lr: ce440304 sp:  1006ff0  main()

Most confusing thing is, one of the test versions DID used to work, but the new versions don’t. Is this still the same issue, as much of the info looks the same?

Otter also stopped working on my pandaboard A2. Debug was similar but different to Andy’s above. I’ll post the debug text if anybody is interested, although probably just the top section ?

After much faffing about Otter started to work again after deleting the !Boot.choices?.Qt5 folder and reloading Qt5 from Chris’s release zip file.

I’d been changing the browser settings to see if they did anything before it bombed.

Otter does look promising…

Ralph

I’ve made a little progress. I no longer get a complaint about being unable to allocate logical address space, but I do get this instead:

A couple of things to check. Make sure you’re not running Aemulor. The default !Run file in !SparkFS doesn’t set a specific memory size. Change ‘SetEval SparkFS$Memory -2’ to e.g. SetEval SparkFS$Memory &100000’.
Also sometimes if Otter Browser crashes it leaves behind it’s dynamic areas. Either reboot when this happens or find a tool that deletes dymamic areas. e.g. !ResRec or ‘removeda’ in the debugtools module.

Well, I’m waiting for it to launch under RPCemu (which is the fastest RISC OS box I have). Averaging 240 MIPS, it’s taken an hour so far and no sign of it completing loading.

I wonder how much of this time is the RTLD and how much is Qt/QML constructors before main() is called.

Sounds like whatever you have RPCEmu running on has slow I/O. Font caching is the culprit. On RPCEmu here it takes about 20 secs to start up.

Otter also stopped working on my pandaboard A2. Debug was similar but different to Andy’s above. I’ll post the debug text if anybody is interested, although probably just the top section ?

This might be to do with dynamic areas being left behind when it crashes.

Otter does look promising…

Here’s the current todo list.

Otter browser works OK with Memphis on my PandaBoard (non ES) with a recent RISC OS build. Memphis is like RAM: but Memphis remembers the files saved from previous sessions. Memphis works at the same/similar speeds to RAM: i.e. faster than reading/writing to an SD card (about 30-50% faster).

I note that Otter is an updated version of Opera, which started life on the Psion Netbook with a StrongARM processor all those years ago.

Ralph

Chris – Just to let you know that I have not been able to download anything from your web server for the last couple of days ?? I’m getting network timeout errors so I assume that your server is down ?

I’d really like to get a copy of the updated library that fixes the missing certificate issue. The old version with the missing certificate error message is driving my crazy…

I note that Otter is an updated version of Opera, which started life on the Psion Netbook with a StrongARM processor all those years ago.

No, they share no common history. Apple forked KDE’s KHTML as WebKit, which Otter uses as its browser engine. Otter’s front end is designed to be a clone of (or inspired by) older versions of Opera, implemented in Qt. So there’s no connection to Psion Netbook browsers. Modern Opera actually uses Blink rather than its own browser engine now, which is itself a Google fork of WebKit.

Chris – Just to let you know that I have not been able to download anything from your web server for the last couple of days

Yes – Having just come back from vacation, I tried to download Otter several times and just got timeouts.

Web site is back up. Thanks.

A test release of Otter Browser is now available for download. It uses the RISC OS port of Qt5 (v5.4.1) which includes the WebKit backend.

Woo! Congratulations! I go away for a bit and look what happens! Fantastic news! :—)

Not only has a Qt port materialized (what planet have I been on…missed that entirely!) but a new and modern browser too! Inspired by Opera is a good thing – its what I use whenever on a Windows computer (which is thankfully only at work now…).

OK so it might be a bit memory hungry but this is fantastic news and has really made my day! As soon as I find all my computers again (just moved house) I’ll definitely give this a go.

…I’ve always loved otters too!

Should Otter also run on an ARMiniX?
I’ve installed everything as described, both !UnixFC and !UnixFont are seen by the filer, the !SharedLibs are merged into !Boot.Resources. But when I run !Otter, the machine freezes. Only an Alt-Break brings it back to life, saying that some unknown application has been interrupted. Did I do something wrong, or is the ARMiniX too old already?

How long did you wait? My Pi 1 appeared to freeze for several minutes, when it was actually just a very slow (and blocking) load. I don’t know how an ARMiniX compares to a Pi in terms of speed…