Native 68k Netsurf

[eb15]

My earlier response was due to someone legitimately stating they thought creating yet another GUI for a standard web browser engine would be to themselves a boring job.  (keeping netsurf or owb internals as a closed box unto itself)

I was expecting someone to say Amaya was outdated (and it is).  However Amaya does CSS and SVG web content creation (which could possibly be extended and updated), and had hooks to connect to a javascript interpreter, which could make it a more interesting project to a developer than just trying to hack a basic GUI wrapper program onto another generic browser engine.   Creating custom Amiga gadgetry objects that can do what the wxWidgets functions did could do be an interesting challenge and might help facilitate other wxWidget based software ports.    

Eventually OWB for AROS will be compiled for the m68k-aros platform so  someone will see how good or bad that works out to be in relation to  netsurf-m68k.  If both of those are too resource heavy, it may be possible for someone to revitalize the old AWeb sources, and graft CSS into it for an alternative.  

An other interesting idea would be to rip apart the various open source web engines, game development systems, and media content players (along with consulting available docs for the latest versions of things like HTML5, flash and pdf to gather information about their object and method support needs) and use the info to design and create a whole new GUI toolkit (and content creation apps) for the Amiga-like OSes that would support cross development between web app space and a more private platform (Amiga) app space..

[utri007]

Well it seems that nobody with good coder skills is not interested to port netsurf, wich is MUCH easier task than make Amay work with AOS or make Aweb support CSS.

[Dwyloc]

@utri007
I expect/hope that when the FPGA Arcade and NatAmi boards start shipping the number of people interested in programming for AOS 68k as well as using it will increase.

I know my interest increased in AOS 3.1 quite a bit when I first got my 4MB Minimig and the newer FPGA boards look much less Limiting and have built in USB and or Lan ports so getting them on line seems like a more realistic option.

[LaserBack]

Well it seems that nobody with good coder skills is not interested to port netsurf, wich is MUCH easier task than make Amay work with AOS or make Aweb support CSS.

it is easier add CCS and good JAVASCRIPT to ibrowse or Aweb
even there is the full aweb source code
I'm sure anyone with good skills can do it and make them run on a standart A1200 /020 +8mb ram/AGA only
the problem is the hard work..nobody will make it for free

[nicholas]

it is easier add CCS and good JAVASCRIPT to ibrowse or Aweb
even there is the full aweb source code
I'm sure anyone with good skills can do it and make them run on a standart A1200 /020 +8mb ram/AGA only
the problem is the hard work..nobody will make it for free

Why don't you start a bounty to show how much you want this browser?

[Fab]

it is easier add CCS and good JAVASCRIPT to ibrowse or Aweb
even there is the full aweb source code
I'm sure anyone with good skills can do it and make them run on a standart A1200 /020 +8mb ram/AGA only
the problem is the hard work..nobody will make it for free

No, believe me, it's much easier to build a full browser around a proven web engine like WebKit (or Netsurf) than implementing yourself full CSS and Javascript and stuff it into AWeb/Ibrowse/Whatever.

Now, about making it run on a 1200/020 and 8MB, it's a whole different story.

[utri007]

it is easier add CCS and good JAVASCRIPT to ibrowse or Aweb
even there is the full aweb source code
I'm sure anyone with good skills can do it and make them run on a standart A1200 /020 +8mb ram/AGA only
the problem is the hard work..nobody will make it for free

You gotta be kidding? Right?

[Thorham]

3. Workin browser for amiga os 3.9 ? would it make you happy?

No. Should be 3.0 and above.

[utri007]

OS4 version is based to reaction, should be possible to add support to ClassAct so that it would work with OS3.X

After all reaction is just later version of classact.

But if this will be done I ques that first versions would suport reaction only

[utri007]

Maybe Project Metropolis makes somebody interested to make native Netsurf for 68k Amigas? At least it would make easy way to publish software and earn some money

http://www.discreetfx.com/ProjectMetropolis.html

I would buy it IF:

It supports 6-8bit screens and of course better screen depths (it should work low spec amigas if it has enough memory 32mb ->)
It supports Amiga system fonts (Truetype fonts shouldn't be requirement)
It has Reaction or MUI gui

Maybe Discreet could promote this

[mousehouse]

I think if we want a slightly useable and working browser on OS3.x we *all* need to contribute. Personally I like the idea of a bounty, maybe managed/organized by Discreet for the fixes / porting needed to get Netsurf running... I would donate to the bounty immediately...

[utri007]

Discreet offers market place, easy way sell software. Not a boynty

[unusedunused]

So now some users have done speed compare between OS4 and 68k netswurf.this show that ixemul and SDL is no speedbrake and 68k netsurf is 3-5* faster if use a CPU with same clockspeed(see the virtual 100 MHZ time)

here are netsurf speed values between 68k 2.7 SDL netsurf and OS4 2.7 netsurf on a SAM 667 MHZ.
newest OS4 and a Pegasos 1 GHZ OS4

more stand here in earlier posts.its german

http://www.a1k.org/forum/showthread.php?p=443367#post443367

the test site for time test was http://www.osnews.com

maybe a user with a risc OS machine can do the test, to see if SDL is fastest possible speed.

a classic amiga is a very slow system, and if OS4 netsurf have no speedbrake somewhere, a SAM or a
Peg should get at least same sec on virtual 100 MHZ.

The OS4 SAM and Pegasos values and 68040/40 netsurf values are from cha05e90.a User who like OS4.so
its no OS4 bashing result possible.only too fast OS4 values are maybe possible ;-)

100 MHZ line mean the values is calculate to a 100 MHZ CPU, to make it more easy possible, to
compare performance /MHZ.less time is better.you can see that on OS4 performance /100 MHZ is more
than 3* slower as on netsurf SDL 68k.
because the 1 GHZ G4 in compare to 667 MHZ SAM is 2.3* faster with netsurf it show that inet access
is no important speed brake.also the BPPC 060/50 mhz values are from a diffrent user, values are
simular, so diffrent

SDL netsurf 68k

BLIZZARD 2040 68040/40 MHZ

         init load 35.10 sec reload 28.1 sec
100 MHZ  init load 14.04 sec reload 11.24 sec

amiga OS 3.1 A3000-PPC PHASE5 68060 50 MHZ 128MB

     init load 23.8 sec reload 17.5 sec
100 MHZ  init load 11.9 sec reload 8.75 sec

BPPC 060/50 mhz und Bvision mit 800x600x16 Screen

         init load 24.4 sec reload 18.8 sec
100 MHZ  init load 12.2 sec reload  9.4 sec

OS4 netsurf 2.7

SAM 667 MHZ OS4.x

        init load 8.4 sec reload 5.0 sec
100 MHZ init load 56  sec reload 33.35 sec

Pegasos 1 GHZ G4 OS4.x

        init load 4.1 sec reload 2.1 sec
100 MHZ init load 41  sec reload 21 sec

[chris]

@bernd_afa

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

I am not discussing this further.

[Fab]

So now some users have done speed compare between OS4 and 68k netswurf.this show that ixemul and SDL is no speedbrake and 68k netsurf is 3-5* faster if use a CPU with same clockspeed(see the virtual 100 MHZ time)

Seriously, your calculation is totally wrong...

Benchmarking a distant site is already very wrong if not done on the same machine/network, but your assumption that loading times are exactly inversely proportional to CPU clock is absolutely insane.
Sure, some time will be spent in building, rendering and blitting the page, but that's only a fraction of the process.

[unusedunused]

@bernd_afa

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

I am not discussing this further.

I haver answer in netsurf ML too

> This is a completely bogus/meaningless comparison.  Firstly, a 100MHz
> 68060 and a 100MHz PPC440 aren't going to be running at the same
> speed.  Even a 100MHz 68060 and a 100MHz 68040 aren't the same speed.

between diffrent CPU and compiler can maybe 20-60% diffrence but the slowdown of OS4 version is
3-5*.thats very large.You dont want compile netsurf SDL Version to see if your use of Cairo slow all
down.

when i do tests on winuae without JIT, so its very slow i notice, larger window run faster.on
800*600 lots need clip.so i find out, clipping cost more time as render complete page in X.

I guess every OS4 machine is run in 32 bit.But i ask the OS4 tester, if he have use netsurf on 32
bit.
Use netsurf on OS4 in 32 bit is maybe faster, because the routines need no byte swapping.

But on 68k there is in 16 bit alot of byteswapping need.so the compare of 16 bit is valid, because
both systems need byteswapping then.

The transfer speed to a 68k amiga GFX Card is around 6-12 megabyte /sec and memory copy speed of a
060/50 is around 24 megabyte /sec.So SAM and a Peg have more than 10* more memory transfer speed.so
it should at least 10 faster.

68k have lots smaller caches.A big app as netsurf like alot big caches.this is maybe the reason wy
the the G4 with the 256 kb secondary cache is so much faster as the SAM.

here can see the 16 bit byteswap code the 68k netsurf need do.

#if __BYTE_ORDER == __BIG_ENDIAN
static inline nsfb_colour_t nsfb_plot_ablend_be16(UNUSED nsfb_t *nsfb, nsfb_colour_t
pixel,nsfb_colour_t  scrpixel)
{
      int opacity = pixel & 0xFF;
      int transp = 0x100 - opacity;
      uint32_t rb, g;
      pixel >>= 8;
      scrpixel >>= 8;
      rb = ((pixel & 0xFF00FF) * opacity +
          (scrpixel & 0xFF00FF) * transp) >> 8;
      g  = ((pixel & 0x00FF00) * opacity +
          (scrpixel & 0x00FF00) * transp) >> 8;

    return ((rb & 0xFF00FF) | (g & 0xFF00)) << 8;

}

static inline nsfb_colour_t pixel_be_to_colour(UNUSED nsfb_t *nsfb, uint16_t pixel)
{
        return ((pixel & 0x1F) << (8+3)) |
              ((pixel & 0x7E0) << (8+5)) |
              ((pixel & 0xF800) << (16));
}

static inline uint16_t colour_be_to_pixel(UNUSED nsfb_t *nsfb, nsfb_colour_t c)
{
        return ((c & 0xF8000000) >> 16) | ((c & 0xFC0000) >> (16-3)) | ((c & 0xF800) >> 11  );
}
#endif