(solved) NetSurf very unstable?

@ChrisH

Quote:

I can make the ARexx also do a TOFRONT, that's easy enough.

Switching to the new tab is trickier, that's the same issue as below.

Quote:

Um... probably. I'll have a look.

@Chris
Another thing: I don't suppose it's possible to fix drag-scrolling to work on this site?:
http://www.theregister.co.uk/2016/08/18/amd_zen_latest/

@ChrisH

If it doesn't work it'll be a core problem. Put it on the bugtracker.

@Chris
Perhaps you can comment on the *really* slow drawing/scrolling of this web page, even on an X1000:
http://amigax1000.blogspot.co.uk/2016 ... mputing-group-august.html

Superficially it seems a quite basic page, but I didn't check the HTML/CSS...

edit: After going to another page by accident, and then back to that page, some bug seems to have stopped the pretty background being drawn past a certain point... And this made scrolling the page MUCH faster. So slow speed seems to be something to do with the tiled background picture. It's almost like the background bitmap isn't stored in video memory, or isn't a friend bitmap & so it's format is converted each time it's blitted to the screen!?!

@ChrisH

It's fine here. Check if Prefs Rendering=>Cache native versions is set to "All". If it isn't that's likely to be the cause.

@Chris
That fixed it, thanks :)

@Chris
The "Please insert volume http:" bug seems like a fairly major usability problem for anyone trying to use NetSurf (it basically renders NetSurf unusable, unless the user knows the work-around, and even then it reappears every reboot).

As it's not something you can fix (and doesn't seem like something that will get fixed any time soon), I would like to suggest that you add a work-around to NetSurf:

When NetSurf starts, it should check for a http: assignment/volume/handler/etc. If none is found, then it will assign http: to RAM: (or maybe T:). But when NetSurf quits, it should remove this assignment (if possible). An alternative would be to disable the "Please insert volume" requester for NetSurf entirely, but that seems a worse work-around to me (unless you can limit that to the times when it is rendering the page).

@ChrisH

Installing http-handler is the best workaround and won't cause problems with anything else.

@Chris
Unless you install http-handler as part of NetSurf's installation, I don't think that's a solution for the "general user".

As I said, this seems like a major usability issue for NetSurf. I can easily imagine someone trying NetSurf, find they get this unwanted & unexpect http: requesters all the time, and simpy decide NetSurf is rubbish & stop using it (rather than trying to work-around it). i.e. The fix needs to be part of NetSurf's normal installation.

But that's just my personal feeling & suggestion, and you are of course free to do what you wish. (And doesn't affect me personally, since I can always put a http: assignment in my User-Startup.)

@ChrisH

I didn't say it was a solution, but a workaround (which achieves the desired effect wrt actually fetching the requested file).

To get the libdom-expat binding to do this requires passing some callbacks for fetches up the chain, it's doable but hassle.

I might implement a temporary fix which looks for a colon and doesn't try to open the file if it finds one. That would solve the immediate problem (but won't fetch the document if it's on the network).

edit I'm having a go at fixing this properly, it looks like fopen should never have been used here so I'd rather do a wholesale replacement if I can get it working.

@Chris
I hope you manage to find a solution (going by the bug tracker, it seems you ran into problems).

Apart from that, NetSurf is working very well for me so far: Starts up almost instantly, rock-solid (no crashes so since your fix), and works well enough on most sites (yes, a few don't render well, or eat tons of CPU before rendering, but that's fairly rare).

@ChrisH

I fixed it for about five minutes!

Good to hear other than that it's working well.