Native 68k Netsurf

[unusedunused]

if c2p only costs 10% then it would advocate to include support for it it into sdl or netsurf.

it cost sure much more time, but i use optimistic 10% value and i reach 2 minute market to show this page.every 10% slower give at 120 sec 10 sec more

>With attitudes like yours we would not have doom, scumm, mp3 >playback etc on the classic Amiga.

doom scumm mp3 play is usable with afats classic user.

but now tell me which user  play doom on his AGA machine ??
does mp3 play in realtime on the 68030 ?

>Netsurf is only possibility to get modern browser for 68k amigas, it >will require some work. There will be new network stack for our >amigas and it would nice if we could get native Netsurf same time.

yes its nice, i told when i need not program it, i use it too.

But i dont want invest lots time for it, i think i need more than 600 hours for this.and later need more to keep update.

maybe a user that want netsurf on a AGA amiga can answer the questen.

If you can program and you can do a native GUI for netsurf in 600 Hours, do you really want spend this lots of work to see netsurf run on your AGA amiga without Java script and frames ?

reason for me its not worth the big work now, and keep it upto date during netsurf enhance.

so the longer you wait, the less work you have.and to see how netsurf grow and fit your needs and pages SDL version is good, you can not reach faster speed.

but things change maybe when netsurf get usefull speedups, frames and java script.

but before maybe OWB work on AOS.

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

[unusedunused]

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

thats same, i tell this in ML, the problem for me is not to write a GUI and Code to read or set the values, this i can do in 1 Hour with stormwizard

http://stormwizard.amiforce.de/

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.and to learn how netsurf work cost much time i think, and more because no good docu is here

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.

I look now into new libnsfb, now is a function in bitmap scale.
This let show in amiga.org the bars correct.

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

[unusedunused]

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 dont understand what monkey frontend is.Have you a link or so ?
SDL is only choose because GTK is too big, slow and memory hungry

If there is another netsurf frontend that is keep maintained its maybe interesting to compile this for AOS 3

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

for me its important to understand how all work, when i program more and the compile and run fail.

But for Port i dont need know how it work

[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

[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

[unusedunused]

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.

have you read the text ?
The OS4 values and the 68040/40 values are come from same inet.the slowdown of OS4 Version is really large.

currently there are no netsurf OS4 on classic and no RISC OS values.here you can see even more how slow netsurf on OS4 is.

so the very large slowdown can at least show, that it bring no speedup in netsurf when you not use ixemul and SDL

[unusedunused]

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

thats best.but as we can see the 1 GHZ G4 with 45% more clockspeed is 2.3* faster as the SAM 667 MHZ.
so can see inet seem no bottleneck.the G4 boost netsurf a lot in performance /MHZ, so there seem no time for inet wait loss.

maybe can look how much faster blender is on G4 in compare to SAM.I dont think its more that 2.3*

I see here

http://www.eofw.org/bench/

733 MHZ SAM need 00:19:54.38

1 GHZ G4 need 00:10:50.23.

so speedup of G4 is on blender too around 2 in compare of SAM

and last not least we talk not about some few 20-30% we talk about 3* more speed of netsurf 68k