Otter and Qupzilla Browsers on the ARMbook

Has anyone got Otter or Qupzilla going on the ARMbook?

Launching Otter just freezes my ARMbook. I haven’t got Qupzilla going either.

Proper freeze or just busy? The first time Otter starts up, it takes forever.

Browse through https://www.riscosopen.org/forum/forums/1/topics/3599

The first time Otter starts up, it takes forever.

It only does that if you’re not using the pre-cached fonts. Due to a combination of the way RISC OS does IO and slow disk media it can take 10’s of minutes if they are not cached.
Check the ‘!UnixFC.cache’ folder. The contents should look similar to the below,

!UnixFC.cache.82c111c32192566eec2715cc40a09455-arm-riscos/cache-4
!UnixFC.cache.8c8c87c04bac0d8a276f876f0ed7af16-arm-riscos/cache-4

The font folder ‘!UnixFont.truetype.droid’ should also be present.

Well after yesterday’s MUG meeting I can confirm that !Otter does indeed work on an ARMBook as one of the club members was using it and also after the event I installed it on my ARMBook and successfully used it abet it has a Red/Blue colour swap issue.

Note this was a clean install via !PackMan but some MUG members stated they had OBrowser which I think ROD/RComp did their take on.

As to !Otter on other machines then we had mixed results as Raspberry Pi that I used for demonstration purposes refused to start up after successfully using it the day before on numereous occassions.

We put that down to presenters curse as the backup Pi ran it’s copy of !Otter OK though as observered it did take a little while to start.

I have also used !QupZilla on a Pi but have yet to try it on the ARMBook.

By the way we used !Otter to configure a Wispy V wireless device from RISCOSBits and it did this really well, once we got passed the initial Pi startup issue.

Wispy V can also be set up from a mobile phone as well as we demonstrated.

@Chris
Yes, it’s true for my ARMbook; but, funnily enough, not for my Pandaboard which can run OBrowser! On the Pandaboard, there is no droid directory in !UnixFont.truetype with dejavu and ttf-bitstream-vera directories instead. Also, in !UnixFC.cache there is only 8c8c87c04bac0d8a276f876f0ed7af16-arm-riscos/cache-4 ,
the second of the two files you mention, along with a file called dummy/txt.

But, I can’t get Qupzilla or Otter to run on my Pandaboard which is strange as I thought they all relied on the same files in the Boot directory. I have noticed this before that one of them may work on a RISC OS computer, but not the other two – weird.

I have now got Otter and Qupzilla going on my Pandaboard and ARMbook. Qupzilla needed nearly 5 minutes to open the start window first time round. Previously, I had given up after 2 minutes and did an ALT Break. Subsequently, it is taking about 45 seconds to open the first page. I didn’t realise it took nearly 5 minutes to initialise the fonts or whatever. OBrowser works on the Pandaboard, but not on the ARMbook. Both computers were running with 16 million colours and I wasn’t using ‘Big Mode’ on the ARMbook.

On the ARMbook, OBrowser displays that banner saying “OBrowser is initialising ……” and after about 30 seconds both the banner and the hourglass have disappeared without the browser’s start page – just nothing. Input is returned to the user, there is no freeze.

It should not take five minutes to access font files. Something spectacularly wrong there.

Those timings do sound a bit horrific. I just tested Iris (essentially a larger version of otter etc, because it is based on more recent [current] webkit engine). It takes about 15 seconds (first time) from double-click to iconbar, which includes loading all the sharedlibs etc. The main window takes about 4 seconds to open as that loads further processes (and more sharedlibs). Second-time load to iconbar is 3 sec, and main window is also about 3.

Looking at the task manager, there are approx 100 MB or so of shared libraries and other binaries to load.

It’s hard to compare, of course (I haven’t installed any other browsers on it except for !OWB which is much faster again), but I’d wait and try OWB or Iris on it soon. David – I believe you may well have access to these in the next couple of weeks.

I have raised another thread under “General” about whether there’s any scope to compress shared libraries further, as their sheer size seems to be a stumbling block for us all when running on slower discs (eg. SD cards etc).

On my slower machines I copy the Unix stuff (~Fonts, ~FC, ~Home) to RAMDisc in predesk and “Look at” in Boot.
Otter and Co. are a bit faster with this.

I copy the Unix stuff (~Fonts, ~FC, ~Home) to RAMDisc

Likewise, except that that I do it in the !Run file. It makes quite a difference and is useable on a Zero.

Yes, the load times were much better from RAM. Unfortunately it took as long (if not longer) to copy everything to RAM disc than it did to just load normally, so it wasn’t really a win unless you were regularly loading from RAM, and clearing shared libraries in between. Probably good for demonstrations though, must remember to do that at show!

there are approx 100 MB or so of shared libraries and other binaries to load

Which still shouldn’t take five minutes. What on earth is it DOING? “It’s on SD” is not an explanation. “It’s reading a byte at a time from an unbuffered file system” might be.