Native 68k Netsurf

[chris]

Are any of the existing amiga based ports (mos/os4) using mui/reaction and other "native" code paths, or are they relying on SDL backend for most everything?

The OS4 one uses Reaction (things will need tweaking for OS3.9, but largely it should work unaltered)
The old MOS version uses MUI.  Note that the interface to NetSurf's frontends has changed significantly, so this frontend will not work "out of the box" with the latest core.

Does the 68k port use the SDL and therefore need an RTG....is that about right?   If so it might be possible to remove the SDL requirement and code an AGA chunky mode instead.

No, don't do that.  The framebuffer frontend (which is what the existing 68k port is) is not really suitable and should not be hacked around for this purpose.  The NetSurf core devs don't like it either.  Create a proper OS3/68k frontend.

@all
The only code you need to touch to modify my OS4 frontend is in the "amiga" directory.

Anything relating to graphics output is in the file "plotters.c".  Currently it uses a mix of graphics.library, (optionally Cairo) and Picasso96 calls.  The graphics.library part sets colours using new OS4 32-bit calls - that will need modifying to use FindColor() - or ObtainBestPen() if you can figure out a way of keeping track of which pens can be unlocked.

I've recently added back in direct to screen rendering, it's buggy atm but should work better for 8-bit modes.

A lot of functions could be stubbed out with #ifdef __amigaos4__ to get it compiled, and then gradually fix functions as they are needed.  There is a heck of a lot of code which is extra UI stuff which won't really matter for an initial porting effort.

I will help!  Ask me questions and I will answer them!

[chris]

just checking, here is a lot of stuff in amiga dir, would have to read into that again, no ifdefs anywhere else?

You can disable features in makefile.config.  There are a couple of "#ifdef nsamiga" elsewhere but you don't need to worry about those.

also i think it would be better to modify p96 to cgx calls for overall 68k compatibility, otherwise half of the systems remain unsupported.

Actually it would be better to ditch them entirely, I only use four functions - p96AllocBitMap, p96FreeBitMap, p96EncodeColor and p96WritePixelArray.  They can be replaced, you don't want to be using p96 or cgx calls on OS3 as there's no guarantee it's available and you need to support AGA.  I'm only using them anyway for pixel format reasons (NetSurf uses RGBA/ABGR, internal OS4 functions prefer ARGB), write a pixel format conversion function and they then aren't needed.

[chris]

If we stick with reaction, that'll make it 3.9 only won't it? Would be a start though.

There's not much to the GUI, a few buttons, a string gadget, a couple of scrollers and a big expanse of empty space.  You should be able to downgrade it to work on ClassAct, there's nothing complicated there.

If he does not hack around, will we still be able to have a chunky graphics display?  it'll probably need one on AGA.

All the rendering code is in the frontend, which gets commands and colours or an RGBA bitmap.  You can do whatever you like with them.

Hiya,

I assume you use GCC to compile this for OS4?

Yes.

Ok so is it using Reaction to render the entire web-page?

No, just a blank area created by space.gadget, which gets filled in by the above-mentioned plotters.

the only way to make a reasonable fast browser for AGA is to to native hardware 'direct screen rendering' and bypass the OS's API functions....

Draw direct to the window via the window's RastPort (this is what my direct rendering does).  I wouldn't recommend hitting the hardware directly, you're probably not gaining much speed at the expense of extra complexity and hardware compatibility.

[chris]

I've dug out my old "what needs doing for OS3" and posted it on the NetSurf wiki:
http://wiki.netsurf-browser.org/Todo/AmigaOS_frontend#OS3_Support

[chris]

Yes, sorry that's exactly what I meant (draw directly to the window's RastPort).

That's perfectly fine then, and exactly what I do.

Currently it renders to an off-screen bitmap and blits it across, but with direct_render:1 the drawing happens direct to the window RastPort - which might be better for AGA.

If GUI is downgraded to work with ClassAct it will work with Reaction allso?

Yes.  The only issue might be the scroller bars and split status/scroller (not sure whether this is possible under ClassAct), but it can always be #ifdef __amigaos4__ and an alternative approach taken for OS3.

@chris:
ive checked a little my source, which im not sure if it is exactly up to date.
1. the amiga directory needs a lot of attention, thats for sure.
2.im working with crosscompiler here, and i dont know how to issue target directly to make in bash although i prepared some sort of preliminary makefile.config. nevertheless i have halfaway assembled amidevcpp project (by hand), not very conform with how netsurf is supposed to be built, i suppose.
3. most files i tested outside amiga dir comile ok, except there is some problem as soon as css is included.

1. A lot of files can be ignored or stubbed out initially (eg. the whole of context_menu.c).  Any functions which start ami_ are called from elsewhere in the frontend rather than from the core.
2. make TARGET=amiga
The makefiles are set up for cross-compilation already.
3. Your libcss is too old (or your netsurf is too old, either way I'd advise to update everything)

[chris]

ok, guys. now after a little tweaking im able to build from bash. there are lots of warnings and errors, a few easy, others i dont know how to handle. i suppose i will have to create a new target, like "m68k-amigaos" not to interfere witch os4 version.

Post them here.  You shouldn't need a new target, if you're cross-compiling it takes a slightly different route anyway - have a look at makefile.target.

If necessary use $SUBTARGET to specify OS3 and make changes in that file.

chris, i have here 2.6 source iirc, should i update to latest commit?

Yes, definitely.  Latest SVN/2.7 has masses of UI changes.

[chris]

here is where i first run into problems

Do you have latest libhubbub?


Unrelated, note there are some AmigaOS makefile changes being made - there is now a subtarget of "os3".
Apparently the right way to trigger an OS3 build is "make TARGET=amigaos3"

You may need to be a couple of SVN revisions newer for that to work though

[chris]

btw chris, i wonder what compiler do you use.
look at the following error i get with 4.5.0- , i comment out #include .


3.4.0 compiles this file apparently just fine.
 i wonder if this is 4.5.0 bug or wrong code that accidentaly slips through unsuspecting or less restrictive 3.4.0. in that case it would be better to remain complaint with the up to date gcc, i think, as i suspect it is more probable to avoid wrong machine code this way.

gcc (GCC) 4.2.4 (adtools build 20090118)

If you can figure out what's causing the error please go ahead and fix it

[chris]

hubbub is compiling fine now. gcc4.5.0 problem does still apply.

Take a look at this:
http://vlists.pepperfish.net/pipermail/netsurf-dev-netsurf-browser.org/2011-March/002416.html

[chris]

SDL is not too slow, its the reason that today no programmer code for a 50 MHZ CPU.

you can use the netsurf or other game ports for linux on a X86 with 50 MHZ.

You see all crawl.the programs are too complex, and they use more bustransfer speed as a slow mediator can offer.thats all.

If you put a 68060 CPU and have a fast GFX Card interface, you can see SDL fly.

You have contradicted yourself.  SDL is too slow for a classic Amiga.

and if you use a native GUI or not doesnt matter for netsurf speed.

No, but how you draw to the GUI does matter.  If you're using SDL it's going to be slow.  If you use graphics.library or cgx it's going to be faster.

problem of netsurf is too, that it can only support 1 pixelformat per bit depth.

In the core, yes.  But there's no problem for the frontend to convert this into something more suitable for display.  You're going to have to do that anyway for 8-bit screenmodes.

but on page create time it speed up nothing. css is too complex and need so much FPU calcs that a 50 MHZ CPU give no better results.

A CSS compatible browser is always going to be slower than a non-CSS one.  I don't think libcss does floating-point maths though.

Chris

[chris]

Have you compile on OS4 a netsurf sdl version and compare speed ?

No.  I did try compiling it once out of curiousity but it didn't work.  It wasn't worth more than five minutes of my time fixing it since I have a native version anyway.

also OS4 Version is report from some user as unstable.pages crashes whole OS4, on netsurf 68k they crash not whole system.

Bug reports would be useful.  If I don't know about it I can't fix it.

Having somebody working on the same frontend for OS3 is also useful, as there is greater chance of bugs being caught or fixed.

I know you spend lots time in netsurf OS4, change version to work with newer cores, so i think to get a stable version for OS3 is too lots work.

Mostly I'm tweaking things that aren't relevant to the core.  Core changes don't tend to require significant changes to the frontend code, if they do then the person implementing the changes usually fixes the frontends even if they can't test/compile them.  If you keep up-to-date it's not that much time really.

wawa have compile a xwindows program that run on the xlib wrapper.so i think better is when try to compile gtk for xlib wrapper and use then xlib version.this allow lots more programs run on aos 68k.

Again, why would I want to use this if I have a native GUI version?  It's a lot of effort (much much more than writing a new frontend from scratch) for no gain as far as NetSurf is concerned.

I don't know why you are so against NetSurf on OS3 with a native GUI.

[chris]

you can see the speed and can see if Cairo is a speedbrake or not.

Cairo is no slower here than using graphics.library, until Cairo clipping is involved.  Hence why I use a mixture of both by default.
 

but if you have a PC, you can  compare the speed with netsurf SDL 68k too.

I have, it's painful.  But that's not really a fair test since my OS4 system is running at a completely different speed than my emulated 68k system.

I am not against a netsurf OS3 with native GUI, i only tell, i dont want spend time on it to find problems or write pixelconverter

OK, well that's up to you and I don't have a problem with that.  If somebody does want to spend their time on it you shouldn't be discouraging them though.

I would strongly argue that a native GUI does bring advantages.  For a start, the OS4 version has full drag'n'drop, tabs, multiple windows, history, cookies and hotlist windows, ARexx port...  Plus it looks and feels like a native browser, which means a lot to some people.

netsurf team have in roadmap to speedup netsurf, but nothing happen since now, frame support, java is miss

Things are progressing, probably more slowly than than any of the devs would like, but it is completely unfair to say nothing is happening.  There are only a few core developers and you can hardly expect them to spend all their free time on NetSurf.

@__artur

That's interesting, probably something to alert the other devs to.  I believe there is an overhead issue with text printing, but there might be something else causing it to be so much slower.

[chris]

1. Get rid of true type fonts

Doable, but won't look pretty due to ambiguous sizing  of text on web pages - you're looking at scaled bitmap fonts for the most part (or a lot of different sized bitmaps converted from a TrueType/CG font).  You'll also lose UTF-8 character support.

If you delve way back into SVN there is a font.c set up exactly like this.  It's probably best left as a user option (fast+ugly, slow+pretty)

2. Native Gui

All the popupmenu.class stuff should be removed now for OS3 compiles.

3. Support for 8 bit screens

Something that needs doing for OS4 as well.

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