NetSurf OS3.x Issues

[chris]

NetSurf 3.5 BETA for AmigaOS 3.5+ is now available here: http://aminet.net/package/comm/www/netsurf_os3

Don't ask me what's changed, I can't remember

[chris]

Great !

It runs very well and fast.

Cool!

- Couldn't it use the FPPrefs?

I have no idea what that is.

- Can't it be done without FPU needed?

Probably, if I could figure out how to force gcc to use certain compiler switches by default.

[chris]

About using the FPPrefs I was wondering if the images couldn't have some treatment and use the palette you are using, or at least some other. IBrowse for example looks much better -compared- when you use few colors. I believe that's because a option of MUI that IBrowse uses though.

The palette mapping/dithering is done wrt the screen NetSurf is running on.  If Multiview displays OK, then NetSurf should too.  picture.datatype handles all this, I don't have any dedicated code for it as yet (that's an optimisation which really needs doing but I have no idea where to start).

Apologies if this has been asked before but any chance of a WarpOS version?

Presumably it will require yet another build of GCC.  So, in theory, yes.  In practice, probably not.

It seems that this version uses more memory than previous version used?

Shouldn't do, there are very few changes.

Only half of second tab/page will be displayed. Is it because of Graphics card memory is ending?? Previous version could dispaly both amiga.org / amigaworld.net same time.

Probably.  Again, I've not knowingly done anything to screw that up.

The only thing I remember changing for rendering involved reducing the number of pen changes - as apparently that's a slow operation.

[chris]

Image loading isn't a problem. It's resampling it for a particular screen which is the tricky bit.

[chris]

OK, I've put a new version up - this is an experimental guigfx.library one.
Rendering=>Cache Native Versions should be set to "All" for fastest image display.
Play with the dithering too: "Low" is really "None", "Medium" is EDD and "High" is Floyd-Steinberg.
Here it looks like it has converted to a palette of about four colours, which is horrible, but might just be me.
Anyway, I'm more interested in the performance, I'll fix the display later, as it isn't working properly on OS4 either.

Now it is possible to log on amiga.org/amigaworld.net Previous versions gave errors.

ITYF you've reverted to an old version.

[chris]

seems netsurf expects v44 version of reaction classes. is this a necessary requirement, or could this check be lowered in order to check with v41 class act ones?

I'd have to check for sure which features I use, but I suspect not. It needs v44 of other components anyway.

[chris]

edit2: btw. im using the version from aminet, which probably is not the current one.

Other than the guigfx experiment it's the same.

Your site still offers 16th april  version?

Yes, on Aminet.

[chris]

It seems to be fast.

After quit, reboot is mandatory. Netsurf is slow after (program) restart without reboot.

It has always crashed on exit here, probably memory trashing.

I used that guigfx library from aminet, is it latest one (2005)? I could found newer one but it is for MUI.

That's the latest AFAIK.  It's probably better to use the old 68k asm version of render.library with it, rather than the newer one.

[chris]

netsurf must be heavily trashing the memory all around. it takes down the whole uae with it when it fails.

Really?  I've not seen that here.

 i might try to recall how ro run muforce or uae enforcer in order to catch these hits. but in order to localize the offending function the binary would have to be compiled with debug symbols anyway. the question is if gccfindhit would work with the utilized compiler, whichever it is. however probably the most sensible would be to enable all debug first. it doesnt make sense to try to speedup and optimize a buggy binary.

gccfindhit doesn't work, so I have no way of tracking down Enforcer hits beyond somebody who knows what they are doing disassembling the code.

I'm basically doing what I can with my limited resources, and that doesn't include spending hours tracking down a memory bug I have no hope of finding except by chance.  I suspect it's something like the MinList bug which I would never have found without matthey's help.

[chris]

OK, new version up which should now be showing the correct colours.  guigfx doesn't seem to do anywhere near as good a job as picture.datatype at colour reduction, but I think the speed up is worth it.  If it's broadly OK then the DataTypes-based quantizer will be removed.

[chris]

have you browsed from site to site or simply loaded a site just once to verify the browser works? a reproducable way to crash netsurf and uae was here to navigate to google.com, enter amiga as search phrase and click a link to amiga wikipedia article, afair.

I'll try that when I have some more time.  I do browse around a few pages and try different pages each time, but I've not been using it extensively.  I'm surprised there haven't been more crashes reported.

maybe its due to my setup, not being clean 3.9, but it isnt crashy otherwise,so i must assume its netsurf this time. what concerns the debug techniques thats unfortunate, since it makes it almost impossible to somehow contribute useful feedback to this project. dont you have at least debug statements spread in the code you could simply turn on in order to find the crash location at least roughly? i know i could look at the sources myself;..
how about others? dont they experience stability issues? because if so, it would be better to go for stability first and then for performance.

NetSurf -v will produce a log.  That's useful for indicating where it crashes but doesn't necessarily pinpoint the exact location.

just tried the last development version. images seem to display all right on rtg 32bit. the crash no matter uae version and cpu setting remains the same. but so far not confirmed by others i assume its my setup fault.

I suspect your crash is genuine.  I know for sure there's some memory corruption happening which is having weird effects.  But as it's only happening on OS3 (which I can't easily debug) and not OS4 it isn't easy to track down - especially as the time the crash happens doesn't relate to when the memory was overwritten.

Amiga.org's logo text amiga.org is red with AGA. No color problems with RTG.

I noticed white text showed up in an odd colour in another image.  Is everything else the right colour on AGA?

[chris]

i need to redirect the outputu to serial to catch the log orderly.
so far after a lot of ami_font_bm_open calls, which seem to process all fine there is browser_window_update_favicon in desktop/browser.c 1182
and then amiga/schedule.c 247amiga_scheduler_run callback with at the first sight possibly valid arguments. callback like that look like being executed alright previously

and thats it.

That sounds like something I spent quite a while looking into previously, and decided it was only crashing there because something previously had overwritten memory.  I was still none the wiser as to what.

[chris]

Would it be possible add friend_bitmap to settings GUI? or is it there already?

No, I'd rather get rid of it completely.

Amigaworld.net logo has also red color. I think that everything is OK otherwise, dithering colors are acceptable.

It's looks like red and white are getting swapped... weird.

[chris]

Tested with WinUAE (Amiga Forever 2013)

It doesn't start, it kills UAE. Also previous install was tested with it without problems.

By "previous one" I assume you are comparing the previous guigfx version with the new guigfx version?

There's very little change between them but I could have screwed something up.

[chris]

now with winuaeenforcer i cannot trace the issue, it actually opened the wikipedia page. however i must correct myself. the images are not rendered correctly.

Not rendered correctly how?

[chris]

What you see is quite normal.
The C standard library contains its own memory allocation manager.
It allocates big chunks from the OS and manages them internally, which is why you dont see OS memory releases as often as you might expect.

Also switching between a blank page and amiga.org isn't going to free up much memory, because most of amiga.org will remain in the memory cache.

Reduce the size of the memory cache to free memory up more frequently (won't stop it fragmenting though)