Native 68k Netsurf

[chris]

>But there are people who are currently browsing with AWeb and >iBrowse on their Amiga's without graphics cards...

Can you tell how much memory this classic systems without GFX Cards have ?

netsurf nead at least a amiga with 48 megabyte of RAM to run usefull.

I can get the executable down to 5MB, maybe less (given my estimate is based on PPC code, which is bigger than 68k), by removing all optional dependencies and using DataTypes only for the images (this is pending some core changes).  I reckon it would run fine in 16MB (and the NetSurf website agrees), you'd just lose some images on image-heavy pages.

the netsurf engine render all pages complete in 32 bit.

Actually it sends drawing commands to the frontend with 32-bit colour definitions.  If you're drawing direct to the window there's no memory overhead to be concerned with, you just need FindColor(), RectFill() or whatever.

Images are 32-bit uncompressed RGBA, but losing a few images on an image-heavy page isn't much of a problem.  If we're set to only use a DataTypes loader we can cheat anyway, and draw direct to the window in 8-bit ignoring the decompression stage.

If you use MUI or Reaction you need more RAM usage, because many unused libs are load

I can't speak for MUI, but with Reaction you only load the libs you need.  My "gadgets" dir is only 1MB anyway, and that contains things like texteditor.gadget which NetSurf won't be using.

[chris]

>I reckon it would run fine in 16MB (and the NetSurf website >agrees), you'd just lose some images on image-heavy pages.

this was some years ago, maybe with small pages test.
please surf a little and measure how many memory is used.

NetSurf + Google seems to use about 25MB, however this is with everything optional compiled in, and it's a debug symbols binary.  The version of libjpeg I'm using is 1MB alone - libjpeg, libvpx, libmng, liblcms, libpng, libcairo+dependencies total nearly 6MB, which brings it down to just over the 18MB a 16MB A1200 will have available.  That's without even delving into the off-screen bitmaps and other allocations that are catering for 32-bit mode.

16MB is probably cutting it fine, but 32MB isn't.  This page on amiga.org is taking up 6MB more than Google.  Bear in mind my NetSurf memory cache is set to 10MB, and PPC code takes up more memory than 68k code.  These figures are going to be really rough and aren't worth pouring over in that much detail.

I know OS4 is so bad design that it not show exact how many memory is free or memory a program use.

Er, what?  OS4 is perfectly capable of saying how much memory is available.  Take your OS4 trolling elsewhere, this isn't the thread for it.

I ask in ML if netsurf have a low mem situation handler, i get no response, so i think, it have non so i am sure amiga with lower as 48 megabyte of RAM you run in crash sooner or later.

It won't crash, it's well written to cope with such a situation.  At worst you'll get the semi-default "NetSurf is running out of memory" error.

[chris]

@bernd_afa

Yes, the default memory cache is 2MB.

As far as OS4's memory display is concerned, AFAIK it only "can't be trusted" as OS4 caches a load of stuff in memory which will be freed when necessary (although I'm pretty sure OS3 does this too, so Rigo might be referring to something else).  Quite frankly, this isn't the place for this discussion and neither do I really care how accurate or good OS4's memory system is at this point in time.  That's the last I have to say on that subject unless by some miracle it becomes relevant to porting NetSurf to OS3.

[chris]

As iv'e said If we get it running, it's a start. Alterations to the code base can happen from there. More coders will be willing tomuck in once they see something running, the Same as happened with AROS, and I don't care if we start to wander away from the main fork either.

Exactly.  I agree with everything you wrote (not just the quoted bit).  Getting it running is the first step - Bernd & Artur's work proves that the core works on OS3/68k, next step is to get a native frontend.  We can optimise after that.  Bernd says the main bulk of processing is parsing and layout - well, that's due to be improved for NetSurf 3/4 anyway.

and now back to topic, did anyone got any further with it in the meantime? i pass for the time being, sorry.

You might like to try compiling the "monkey" frontend.  That will prove your build system is set up correctly.

Here is a mail, what problem it is to make a native GUI.
the atari mint version is develop many months now.

http://vlists.pepperfish.net/pipermail/netsurf-dev-netsurf-browser.org/2011-March/002417.html

That's mostly irrelevant, since we have a frontend that just needs back-porting.  Also the Atari port got results quite quickly, adding on the extra months used to develop it further is missing the point somewhat.

[chris]

dont see any monkey frontend here  to compile for..
i think the build system is set up ok. just to reprogram the amiga frontend is a little too much one could expect fromme..

The monkey is new, you'l need to update to latest SVN.  It's better to do "svn co" and "svn up"  instead of downloading the tarballs.

 

I can  write faster a stormwizard GUI than porting your reaction GUI, the problem come when something not work, there need understand how netsurf core work.

I've been working on it a couple of years, and only have the vaguest clue how the core works.  You don't need to know.  Any API that the frontends used is either obvious, documented or can be nicked out of one of the other frontends.

You or netsurf team do not compile or test 68k Port, so if something is change in main core, then need search wy it not work.

It's quite rare for core changes to need frontend changes, and if they do then usually the person making the changes fixes up the frontends as best as they can.  I've been through this already.

Anyway, this is one of the reasons why I suggested backporting the OS4 frontend instead of creating a new one.  Anything like that I'm going to be fixing anyway, all it needs is compiling and testing on OS3.

but with needed scale feature, netsurf get slower i think.and more slower of course on AGA

It's as slow as BitMapScale(), which is the same speed whatever the graphics output device.  Scaling before or after converting to 8-bit might make a difference.  This is all optimisation that can be investigated after we have something working.

[chris]

I dont understand what monkey frontend is.Have you a link or so ?

It's a dummy frontend.

[chris]

@bernd_afa

This is a completely bogus/meaningless comparison.  [Read more]

I am not discussing this further.

[chris]

the benchmarks should be made loading a page saved locally to a harddrive, displayed in same resolution in the same screen depth. if done like that they are meaningful.

Only if compiled and running on the same CPU too.

i dont know but it is perfectly possible that resolution of netsurf on a classic was set to 800x600x16

To clarify, this is the reported resolution on classic in Bernd's orignal email.  I was doubting that the OS4 machines had been set to this (although 16-bit creates a bottleneck on NetSurf-OS4 anyway, so I'd rather any tests were done in 32-bit mode)

besides for the end user who doesnt care about processors instruction set, compile options and the gui frontend used but if application works and how fast, the comparison between os4 implementation and 68k port is perfectly sane. you, chris, should be interested yourself to identify bottlenecks, in case the comparison was fair.

That would be fine if it was a fair comparison, but it isn't.  It may as well have been comparing NetSurf OS4 to Lynx running on Mac OSX for the amount of useful data it generated.

See also:
http://vlists.pepperfish.net/pipermail/netsurf-dev-netsurf-browser.org/2011-July/002523.html
http://wiki.answers.com/Q/What_is_a_controlled_experiment

Chris

[chris]

if i get you right, you mean you dont want to compare two things at a time: architecture and the software implementation. otherwise the result of comparing something to itself on the same cpu should be always 1:1. the problem is sometimes architecture implies the implementation, like for instance ppc/os4>reaction. generally i think you may compare everythyng to anything as soon as you have set a single benchmark. in this case its netsurf engine. of course the benchmark becomes increasingly meaningful when narrowing test categories, but one has to start somewhere.

If you're comparing the NetSurf engine then you need to compare it fairly.  ie. run both engines on the same computer under the same conditions.

wasnt then the testcase in favour of ppc/os4 anyway? i thought 32bit was choosen there.

No idea, wasn't mentioned.

i would call it a fair testcase if we were comparing different browsers on different architectures.

Why?  What is that proving?  That a 3GHz Core Duo runs Firefox faster than a 667MHz PPC440 can run NetSurf?  That means nothing to me.  However, if somebody was comparing Timberwolf to NetSurf on the same hardware then they might be making a valid point.

Even comparing NetSurf GTK under Linux on a SAM440 to NetSurf under OS4 on the same hardware would be more useful, but even then you don't know if any differences are due to the frontend or the OS.

we wonder why amiga (68k) sdl and os4 reaction netsurf ports are so slow in comparison to native risc os 68k implementation.

RISC OS runs on ARM.  As I'm sure you'll know, ARM chips are blazingly fast.  You can do some comparisons from the screenshots:

BBC
RISC OS: 11.1s
AmigaOS4: 12.9s

NetSurf
RISC OS: 1.6s
AmigaOS4: 2.8s

Wikipedia
RISC OS: 4.9s
AmigaOS4: 12.8s (although more of the page is displayed for some reason)

What does that tell me?  That NetSurf on some unknown RISC OS hardware configuration is faster than NetSurf on my lowly 600MHz SAM440?  If RISC OS is running on a 600MHz ARM would that mean anything more?  No, there are too many variables to say why there is a speed difference.  The Wikipedia screenshot might be slower because on that one, I used libmng instead of libpng for decoding PNGs.  Maybe I had something intensive running in the background, like a compile or TuneNet.

this implementation differs as much from both as os4 differs from 68k, you dont find it a question worth examinating, do you?

I've just examined it and came to no conclusions, except that it is as meaningless a comparison as the original one.

just being comfortable that it runs on os4 at all since the cpu is fast enough?

I think you're missing the point.  Compared to other CSS browsers on OS4 it is faster.  Therefore I don't think it is likely that there is a major slowdown issue.  I accept that some optimisations could be done (16-bit screenmodes, text size calculations), but it is unlikely that the speed difference is anywhere near what Bernd is quoting.