NetSurf OS3.x Issues

[utri007]

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.

Your site still offers 16th april  version?

[wawrzon]

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

mmm. ok.. simply tried to run it on aros with the freely available classes. but it doesnt load there even with the proper reaction components, which probably expect 3.9 functionality. on my 3.9(+) (i dont have a clean install anymore) it loads properly (have not installed it) and runs for a time being loading simpler sites (images rendering still seems not to work well even with 32 bit) but crashes rather soon. im not able to make any pattern of it at this time, however.

edit: (i gave it a lot of stack of course, which is necessary for it to load from command line anyway, so this is not an issue)

might be a good idea to have a version with full debug compiled in for testing.

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

[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.

[utri007]

It must be in upload queue, as I can't found it. Aminet version is excat same than you site offres.

[utri007]

It seems to be fast.

040/AGA loads amiga.org 29 sec
060/RTG loads amiga.org 19 sec

Cache native version seems to slow down 060/RTG, takes almost 10 seconds more to display amiga.org. It doesn't have any effect to scrolling either.

With 040/AGA it has huge difference fo scrolling and load time.

This one is most buggy and easy to get crash version so far resizing Windows etc is dangerous.

This version has still "slow down" effect. It slows down but load times doesn't grow exponentially any more. First two pages loads fast, but after that pages loads about 80-100 seconds, but load time doesn't seems to grow after that.

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

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

[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.

[wawrzon]

netsurf must be heavily trashing the memory all around. it takes down the whole uae with it when it fails. 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.

[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.

[wawrzon]

Really?  I've not seen that here.

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.

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.

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.

[utri007]

Netsurf has been very stable here, no crashes.

Fast test today. Nothing about speed this time, as I just installed it and loaded few pages. Lets see if I have any energy left latter today.

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

Made some tests with iBrowse, it starts to display site faster, but over all loading time is quite near same.

[utri007]

OK tested more. I thing that speed is little bit degraded, not much, it is still faster than version wich uses picture.datatype.

Memory usage is about same, no noticeable diffrence. Speed is still a problem after few pages.

How about this : I noticed that amigaworld.net uses much less memory than amiga.org. Netsurf freed memory nicely. Wich made me thing IF Netsurf would load empty page always before new "real page", it would terminate memory fragmetnion? Loading empty page wouldn't take too much time, but memory would have big contionous free block? This would be very stupid question and if it would work it would be very unsophisticated solution

[wawrzon]

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.

[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?

[wawrzon]

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

ah, i recall. i have forgotten that. thats good, might give some hint;)

[wawrzon]

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.