Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: utri007 on March 07, 2011, 11:03:00 AM
-
I really don't understand, why not...
1. Netsurf has proven to work with low-spec machines
2. It would be happy thing to both UEA and real machine users
3. Workin browser for amiga os 3.9 ???? would it make you happy?
Chris ported Netsurf to OS4 and this is what he said about 68k possibility:
"Actually it's relatively easy. If you start with the OS4 frontend, you should be able to get it working on OS3.9 with Reaction fairly quickly. There are a few things that need backporting (I have used a lot of new OS4 calls, but most have OS3 equivalents). A couple of major changes:
fonts code - probably needs to be rewritten to use ttengine.library (I already have a ttengine.library version of this code somewhere, needs updating and fixing though)
plotters - need to be rewritten to work on 8-bit screenmodes (this needs doing for OS4 too).
I wrote a little more detailed list of changes required on the dev mailing list, if you want to seek that out.
Even starting from scratch, new (basic) frontends have been written in a matter of weeks."
-
then why dont you make this port yourself? ive looked into the source some time ago and it wasnt *so* easy (for me). but then ive been making mostly only sdl ports if anything.
-
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? While I understand a real 68k machine wont be up to the task for some online content Im sure theyre capable of a better browser experience than is available. I do actually kinda like IB/Aweb/Voyager, but the technologies behind them are really starting to show thier age.
Netsurf seems the most likely candidate for a light sort of browser for classic amigas, but despite having gotten better than the earlier 68k versions, it's probably still a little heavy for a real amiga (and needs rtg to run at all). Only way to redeem that I guess is to "amiga-fy" it a little more.
Semi off topic, but I used to like using the 68k mac broser iCab under shapeshifter a few years ago when I was amiga only (classic + amithon). Unfortunately from what a friend says the sands of time have caught up with it too and it no longer displays a lot of pages well. I'll get around to checking it out myself again one day when I get the time though, if just for nostaliga :)
-
Isn't the sourcecode available for Aweb? Might be better updating something that runs OK on classic, rather than trying to pour a quart into a pint glass.
-
The problem, much probably, is finding a 68k Amiga coder with a proper experience (sadly too tought for my programming skills and experience).
The divisions inside our community is one of the reasons for these difficulties finding passionate and skilled people.
-
I really don't understand, why not...
1. Netsurf has proven to work with low-spec machines
2. It would be happy thing to both UEA and real machine users
3. Workin browser for amiga os 3.9 ???? would it make you happy?
Chris ported Netsurf to OS4 and this is what he said about 68k possibility:
"Actually it's relatively easy. If you start with the OS4 frontend, you should be able to get it working on OS3.9 with Reaction fairly quickly. There are a few things that need backporting (I have used a lot of new OS4 calls, but most have OS3 equivalents). A couple of major changes:
fonts code - probably needs to be rewritten to use ttengine.library (I already have a ttengine.library version of this code somewhere, needs updating and fixing though)
plotters - need to be rewritten to work on 8-bit screenmodes (this needs doing for OS4 too).
I wrote a little more detailed list of changes required on the dev mailing list, if you want to seek that out.
Even starting from scratch, new (basic) frontends have been written in a matter of weeks."
http://m68k.aminet.net/package/comm/www/NetSurf-m68k
-
@nicholas
That is a non native port (SDL). The thread is about a native port due to the extremely high resource requirements for a 68k Amiga that the sdl port needs.
-
@nicholas
That is a non native port (SDL). The thread is about a native port due to the extremely high resource requirements for a 68k Amiga that the sdl port needs.
Yes, I was pointing the OP to the source code so he could get started on porting it to Gadtools. ;)
-
i dont think that after so many years of non activity aweb is any good base for an updated browser. any initiative in amiga scene has to be undertaken with some future perspective in mind. if anyone even magically manages to compile a browser who is going to constantly maintain and update it like fab does.
thats why the only feasable approach, that has been proven working is to rely on a third party maintained core adding only some gui to it.
now what concerns netsurf there are three amiga frontends:
- arturs enchanced 68k sdl port
- chris reaction os4 frontend
- and abandoned itix' mos mui frontend.
-
my proposal would be to resign on netsurf for the time being. yesterday i have checked a few provided aros contributions under winuae aros 68k, and most are working fine. also zune improves in terms of compatibility. most examples and bigger os3 programs like yam, nowined, scout already work correctly. im waiting for someone to compile aros owb for 68k. then the bounty to update zune might be taken, and mos owb port started.
-
also since yesterday nightly aros directory listing speed improved considerably thanks to new png loading procedures. also there is an approach to allow aros 68k executables to run out of the box on aos. i dont know how well it is already working though.
-
All: Please notice that Netsurf requirements are 30MHz ARM 6 computer with 16MB of RAM.
That just to point out that AWeb won't be better option. OWB and Firefox won't be either, they would require too much for real amigas.
If some body could pick up this project, I belive that he would get help he needs. At least Chris has some interest to help, so OS4 reaction frontend would be good choice to start, but Mui frontend would allso option, I belive that Itix has helped Arthur and/or coder could start from scraths.
-
im not sure if there is so much difference in requirements between netsurf qnd owb. there is efika version of fabs owb, and his last release is reported to be yet significantly faster.
itix helped artur so far i know with more general stuff, but his mui frontend isnt up to date anymore. it doesnt make sence to pick up this task for someone that doesnt know what he is doing, without significant help.
-
start a bounty. I'd certainly contribute. No offense aweb and ibrowse blow.
-
I would contribute also, could somebody who has a more experience to start it? It would also need lots of advertising.
Working web browser would be essential, I really don't understand why people are not more interested about this. They rather arguing and whining pointless things and spread their positive attitude all over them. <- sarcasm
-
I would contribute also, could somebody who has a more experience to start it? It would also need lots of advertising.
Working web browser would be essential, I really don't understand why people are not more interested about this. They rather arguing and whining pointless things and spread their positive attitude all over them. <- sarcasm
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.
-
or you could code your c2p routines directly into bernds sdl library, in order to have a potential possibilty to run all sdl apps on planard screens. this will probably cost just too much performance for most games. is though a much desired feature ive observed. also i have suggested that before.
-
or you could code your c2p routines directly into bernds sdl library, in order to have a potential possibilty to run all sdl apps on planard screens. this will probably cost just too much performance for most games. is though a much desired feature ive observed. also i have suggested that before.
No sorry, I would never try and compile the SDL source code. I'm currently using the 68k SDL library for audio and multi-threading (timer) and using native C2P AGA for graphics. With a NetSurf port I'd probably just the SDL requirement (if possible).
-
i dont understand very well, but whats more complicated in inserting c2p routines into existing sdl static library project than into a netsurf project? both sources will be most likely made available on demand if you volunteer to contribute. but improving sdl would be a more universal gain as it is used by many more applications except netsurf itself.
edit: just to be clear: sdl 68k refuses to work on planar screens for now. when such a screen was detected say by bestmodeid the gfx output could be redirected to your native c2p routine. i don think that it is complicated. bernd woulld sure help with some guidance, since he knows the source. what do you think?
-
Problem is that SDL is quite useless with real amigas. Even with 8bit modes availlable, it would be useless for real amiga users and pointeless because UEA users doens't need 8bit modes
-
that depends, ive released some stuff that works acceptably on real hardware to aminet, but with c2p overhead it will sure get slower yet.
-
Last time I looked for AWeb sources, the published server link I found was no longer available... If there is open source to any of the old Amiga web browswers besides AMosaic, which I already have through AROS, I would be interesting in playing with it under the AROS build system to see if I can get it to build and run under AROS. That should help prep for working on lighter NetSurf and/or OWB ports (without MUI or SDL dependencies).
-
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!
-
just checking, here is a lot of stuff in amiga dir, would have to read into that again, no ifdefs anywhere else?
also i think it would be better to modify p96 to cgx calls for overall 68k compatibility, otherwise half of the systems remain unsupported.
-
P96 and CGX shouldn't matter, as there are cgx emu buildin in P96?
-
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.
-
The OS4 one uses Reaction (things will need tweaking for OS3.9, but largely it should work unaltered)
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.
@
If we stick with reaction, that'll make it 3.9 only won't it? Would be a start though.
If he does not hack around, will we still be able to have a chunky graphics display? it'll probably need one on AGA.
-
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.
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!
Hiya,
I assume you use GCC to compile this for OS4?
Direct screen rendering sounds interesting, not sure how that fits in though.
Ok so is it using Reaction to render the entire web-page? I think that would be very slow under AGA, 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....that way it could be done using either C2P or even better the new chunky mode from the Indivision Mrk2. This kind of approach could only work if the underlying browser engine output the complete webpages to a chunky buffer ready for displaying to the user (including its own take on dialog boxes etc).
-
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.
-
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
-
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.
Yes, sorry that's exactly what I meant (draw directly to the window's RastPort).
-
@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.
css.c itself compile attempt results in:
Compiler: m68k-Amiga-os3-gcc-4.5.0
Building Makefile: "C:\CrossCompiler\AmiDevCpp\projects\netsurf\Makefile.win"
Executing make...
mingw32-make.exe -f "C:\CrossCompiler\AmiDevCpp\projects\netsurf\Makefile.win" css/css.o
m68k-amigaos-gcc-4.5.0.exe -c css/css.c -o css/css.o -I"/usr/local/amiga/m68k-amigaos/sys-include" -I"/usr/local/amiga/m68k-amigaos/include" -I"C:/CrossCompiler/AmiDevCpp/projects/netsurf" -w -include stdio.h
css/css.c: In function ‘nscss_create_css_data’:
css/css.c:115:4: error: too many arguments to function ‘css_stylesheet_create’
/usr/local/amiga/lib/gcc/m68k-amigaos/4.5.0/../../../../m68k-amigaos/include/libcss/stylesheet.h:27:11: note: declared here
css/css.c: In function ‘nscss_import_complete’:
css/css.c:447:6: error: too many arguments to function ‘css_stylesheet_create’
/usr/local/amiga/lib/gcc/m68k-amigaos/4.5.0/../../../../m68k-amigaos/include/libcss/stylesheet.h:27:11: note: declared here
mingw32-make.exe: *** [css/css.o] Error 1
Execution terminated
gotta check it in the morning.. but once its solved it is probably solved for all the similar errors.
-
If GUI is downgraded to work with ClassAct it will work with Reaction allso?
-
btw trying to build netsurf from the shell makefile script runs into errors. there are some "/*" strings that will be interpreted as comments i believe which leads to this:
makefile:305: Extraneous text after `else' directive
makefile:305: *** only one `else' per conditional. Stop.
besides some libs such as libcss have to be built preferably statically at this point. must see if artur has them at hand before i start to break in through the open door.
-
You need make v 3.81
-
You need make v 3.81
http://aminet.net/package/dev/gg/make-3.81-bin-m68k
-
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)
-
You need make v 3.81
oh, thanks mine is 3.80.
@nicholas: iif everything breaks i will try to compile under cubicide, for now i stay with amidevcpp environment.
-
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.
chris, i have here 2.6 source iirc, should i update to latest commit?
-
oh, thanks mine is 3.80.
@nicholas: iif everything breaks i will try to compile under cubicide, for now i stay with amidevcpp environment.
I'd forgotten about that lovely little tool, gonna install it now. Do you recommend I get the latest wxDev-cpp v7 too and update over the top off the AmiDev-Cpp folder?
-
ive got original amidevcpp and updated certain components only if need be for fear to run into some incompatibility and fail due to lack of support. i remember ive done one more general update to get it compatible with gcc 4.5.0 whatever it was. but im complete noob so dont expect any reliable info on my part. im just trying to get it to compile
-
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.
-
Post them here.
there are so many, i have to make up my mind where to start. is there any way to dump the make log to a file? im not accustomed to shell, i am using devcpp interface for most of the time.
2.7 r11956 downloaded, it had some errors unpacking, nothing essential i think. lets see.
-
Thanks, I really wish that you guys success. Semi modern browser would essential for all of us
-
dont hold your breath.
-
If cross compiling with gcc/linux, what version is recommended? Netsurf page recommends 3.4.6 release 3 or later. Is there a better choice?
Plaz
-
i have actually 3.4.0 (of zerohero i think) that came originally with amidevcpp as well as 4.5.0 compiled by bernd rosch. there is also some in between versions but ihave not been using any of them. depending on source it might be neccessary to switch, since 4.5.0 is gennerally less forgiving especially for obsolete code. though i think for a project under steady development an up to date compiler should be fine. therefore im using 4.5.0 for now.
-
here is where i first run into problems
COMPILE: render/hubbub_binding.c
render/hubbub_binding.c:40:2: error: expected specifier-qualifier-list before ‘h
tmlDocPtr’
render/hubbub_binding.c: In function ‘binding_create_tree’:
render/hubbub_binding.c:147:3: error: ‘hubbub_ctx’ has no member named ‘encoding
’
render/hubbub_binding.c:148:3: error: ‘hubbub_ctx’ has no member named ‘encoding
_source’
render/hubbub_binding.c:150:3: error: ‘hubbub_ctx’ has no member named ‘document
’
render/hubbub_binding.c:151:3: error: ‘hubbub_ctx’ has no member named ‘owns_doc
’
render/hubbub_binding.c:152:3: error: ‘hubbub_ctx’ has no member named ‘quirks’
render/hubbub_binding.c:153:3: error: ‘hubbub_ctx’ has no member named ‘forms’
render/hubbub_binding.c:165:3: error: ‘hubbub_ctx’ has no member named ‘document
’
render/hubbub_binding.c:166:7: error: ‘hubbub_ctx’ has no member named ‘document
’
render/hubbub_binding.c:171:3: error: ‘hubbub_ctx’ has no member named ‘document
’
render/hubbub_binding.c:173:26: error: ‘hubbub_ctx’ has no member named ‘namespa
ces’
render/hubbub_binding.c:173:50: error: ‘hubbub_ctx’ has no member named ‘namespa
ces’
render/hubbub_binding.c:174:4: error: ‘hubbub_ctx’ has no member named ‘namespac
es’
render/hubbub_binding.c:177:3: error: ‘hubbub_ctx’ has no member named ‘tree_han
dler’
render/hubbub_binding.c:178:3: error: ‘hubbub_ctx’ has no member named ‘tree_han
dler’
render/hubbub_binding.c:180:26: error: ‘hubbub_ctx’ has no member named ‘tree_ha
ndler’
render/hubbub_binding.c:183:15: error: ‘hubbub_ctx’ has no member named ‘documen
t’
render/hubbub_binding.c:184:26: error: ‘hubbub_ctx’ has no member named ‘documen
t’
render/hubbub_binding.c: In function ‘binding_destroy_tree’:
render/hubbub_binding.c:202:7: error: ‘hubbub_ctx’ has no member named ‘owns_doc
’
render/hubbub_binding.c:203:15: error: ‘hubbub_ctx’ has no member named ‘documen
t’
render/hubbub_binding.c:206:3: error: ‘hubbub_ctx’ has no member named ‘encoding
’
render/hubbub_binding.c:207:3: error: ‘hubbub_ctx’ has no member named ‘document
’
render/hubbub_binding.c: In function ‘binding_get_encoding’:
render/hubbub_binding.c:240:13: error: ‘hubbub_ctx’ has no member named ‘encodin
g_source’
render/hubbub_binding.c:242:10: error: ‘hubbub_ctx’ has no member named ‘encodin
g’
render/hubbub_binding.c:242:32: error: ‘hubbub_ctx’ has no member named ‘encodin
g’
render/hubbub_binding.c: In function ‘binding_get_document’:
render/hubbub_binding.c:248:19: error: ‘hubbub_ctx’ has no member named ‘documen
t’
render/hubbub_binding.c:250:3: error: ‘hubbub_ctx’ has no member named ‘owns_doc
’
render/hubbub_binding.c:252:13: error: ‘hubbub_ctx’ has no member named ‘quirks’
render/hubbub_binding.c: In function ‘binding_get_forms’:
render/hubbub_binding.c:261:10: error: ‘hubbub_ctx’ has no member named ‘forms’
render/hubbub_binding.c: In function ‘binding_get_control_for_node’:
render/hubbub_binding.c:270:12: error: ‘hubbub_ctx’ has no member named ‘forms’
render/hubbub_binding.c: In function ‘create_namespaces’:
render/hubbub_binding.c:305:6: error: ‘hubbub_ctx’ has no member named ‘namespac
es’
render/hubbub_binding.c:309:10: error: ‘hubbub_ctx’ has no member named ‘namespa
ces’
render/hubbub_binding.c: In function ‘create_comment’:
render/hubbub_binding.c:326:24: error: ‘hubbub_ctx’ has no member named ‘documen
t’
render/hubbub_binding.c: In function ‘create_doctype’:
render/hubbub_binding.c:368:17: error: ‘hubbub_ctx’ has no member named ‘documen
t’
render/hubbub_binding.c: In function ‘create_element’:
render/hubbub_binding.c:398:7: error: ‘hubbub_ctx’ has no member named ‘namespac
es’
render/hubbub_binding.c:399:22: error: ‘hubbub_ctx’ has no member named ‘documen
t’
render/hubbub_binding.c:399:35: error: ‘hubbub_ctx’ has no member named ‘namespa
ces’
render/hubbub_binding.c:402:22: error: ‘hubbub_ctx’ has no member named ‘documen
t’
render/hubbub_binding.c:406:21: error: ‘hubbub_ctx’ has no member named ‘namespa
ces’
render/hubbub_binding.c:409:17: error: ‘hubbub_ctx’ has no member named ‘namespa
ces’
render/hubbub_binding.c:426:46: error: ‘hubbub_ctx’ has no member named ‘encodin
g’
render/hubbub_binding.c:436:17: error: ‘hubbub_ctx’ has no member named ‘forms’
render/hubbub_binding.c:437:4: error: ‘hubbub_ctx’ has no member named ‘forms’
render/hubbub_binding.c: In function ‘create_text’:
render/hubbub_binding.c:452:24: error: ‘hubbub_ctx’ has no member named ‘documen
t’
render/hubbub_binding.c: In function ‘ref_node’:
render/hubbub_binding.c:467:15: error: ‘hubbub_ctx’ has no member named ‘documen
t’
render/hubbub_binding.c: In function ‘unref_node’:
render/hubbub_binding.c:486:15: error: ‘hubbub_ctx’ has no member named ‘documen
t’
render/hubbub_binding.c: In function ‘form_associate’:
render/hubbub_binding.c:659:12: error: ‘hubbub_ctx’ has no member named ‘forms’
render/hubbub_binding.c: In function ‘add_attributes’:
render/hubbub_binding.c:730:6: error: ‘hubbub_ctx’ has no member named ‘namespac
es’
render/hubbub_binding.c:732:7: error: ‘hubbub_ctx’ has no member named ‘namespac
es’
render/hubbub_binding.c: In function ‘set_quirks_mode’:
render/hubbub_binding.c:756:4: error: ‘hubbub_ctx’ has no member named ‘quirks’
render/hubbub_binding.c:759:4: error: ‘hubbub_ctx’ has no member named ‘quirks’
render/hubbub_binding.c:762:4: error: ‘hubbub_ctx’ has no member named ‘quirks’
render/hubbub_binding.c: In function ‘change_encoding’:
render/hubbub_binding.c:776:7: error: ‘hubbub_ctx’ has no member named ‘encoding
’
render/hubbub_binding.c:784:4: error: ‘hubbub_ctx’ has no member named ‘encoding
_source’
render/hubbub_binding.c:785:4: error: ‘hubbub_ctx’ has no member named ‘encoding
’
render/hubbub_binding.c:799:3: error: ‘hubbub_ctx’ has no member named ‘encoding
’
render/hubbub_binding.c:800:3: error: ‘hubbub_ctx’ has no member named ‘encoding
_source’
COMPILE: render/html_redraw.c
COMPILE: render/html_interaction.c
In file included from /usr/local/amiga/lib/gcc/m68k-amigaos/4.5.0/../../../../m6
8k-amigaos/include/dirent.h:45:0,
from ./utils/config.h:23,
from ./content/content.h:31,
from render/html_interaction.c:29:
/usr/local/amiga/lib/gcc/m68k-amigaos/4.5.0/../../../../m68k-amigaos/include/sys
/dirent.h:50:2: error: expected specifier-qualifier-list before ‘u_int32_t’
In file included from ./utils/config.h:57:0,
from ./content/content.h:31,
from render/html_interaction.c:29:
/usr/local/amiga/lib/gcc/m68k-amigaos/4.5.0/../../../../m68k-amigaos/include/net
inet/in.h:81:2: error: expected specifier-qualifier-list before ‘u_int32_t’
/usr/local/amiga/lib/gcc/m68k-amigaos/4.5.0/../../../../m68k-amigaos/include/net
inet/in.h:151:2: error: expected specifier-qualifier-list before ‘u_int8_t’
/usr/local/amiga/lib/gcc/m68k-amigaos/4.5.0/../../../../m68k-amigaos/include/net
inet/in.h:167:2: error: expected specifier-qualifier-list before ‘int8_t’
i mean the hubbub, the not recognized type errors is as i remember to some include that is non standard for gcc here (exec/types.h or stdio.h or so)
-
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 :)
-
ive got from artur his latest libs and includes, i think it must compile for him. but perhaps i will check out the most current hubbub headres. it will be some time yet before the linking stage ;)
everything seems to compile fine now, except for hubbub and most files in amiga dir. but i quit for tonight i think.
-
just wanted to say: checked out latest hubbub headers and still no success.
-
hubbub problem found, if not yet completely solved. its too old libxml2. replaced headers with those of os4 aminet distro and now it compiles ok. waiting for arturs static lib, which should solve linking stage when we come to that. now the amiga dir must get our attention.
-
btw chris, i wonder what compiler do you use.
look at the following error i get with 4.5.0- , i comment out #include .
m68k-amigaos-gcc-4.5.0.exe -c amiga/thumbnail.c -o amiga/thumbnail.o -I"/usr/local/amiga/m68k-amigaos/sys-include" -I"/usr/local/amiga/m68k-amigaos/include" -I"C:/CrossCompiler/AmiDevCpp/projects/netsurf" -w -include stdio.h
amiga/thumbnail.c: Assembler messages:
amiga/thumbnail.c:100: Error: Unknown operator -- statement `js a6@(-0x2a6:W)' ignored
mingw32-make.exe: *** [amiga/thumbnail.o] Error 1
Execution terminated
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.
-
another example that compiles fine with 3.4.0 but not with 4.5.0:
mingw32-make.exe -f "C:\CrossCompiler\AmiDevCpp\projects\netsurf\Makefile.win" amiga/search.o
m68k-amigaos-gcc-4.5.0.exe -c amiga/search.c -o amiga/search.o -I"/usr/local/amiga/m68k-amigaos/sys-include" -I"/usr/local/amiga/m68k-amigaos/include" -I"C:/CrossCompiler/AmiDevCpp/projects/netsurf" -w -include stdio.h
In file included from /usr/local/amiga/lib/gcc/m68k-amigaos/4.5.0/../../../../m68k-amigaos/sys-include/clib/alib_protos.h:22:0,
from C:/CrossCompiler/AmiDevCpp/projects/netsurf/amiga/os3support.h:31,
from amiga/search.c:38:
/usr/local/amiga/lib/gcc/m68k-amigaos/4.5.0/../../../../m68k-amigaos/sys-include/devices/timer.h:30:8: error: redefinition of ‘struct timeval’
/usr/local/amiga/lib/gcc/m68k-amigaos/4.5.0/../../../../m68k-amigaos/include/sys/time.h:50:8: note: originally defined here
amiga/search.c: In function ‘ami_search_open’:
amiga/search.c:375:0: error: unterminated argument list invoking macro "NewObject"
/usr/local/amiga/lib/gcc/m68k-amigaos/4.5.0/../../../../m68k-amigaos/sys-include/reaction/reaction_macros.h:123:29: error: ‘NewObject’ undeclared (first use in this function)
/usr/local/amiga/lib/gcc/m68k-amigaos/4.5.0/../../../../m68k-amigaos/sys-include/reaction/reaction_macros.h:123:29: note: each undeclared identifier is reported only once for each function it appears in
amiga/search.c:132:2: error: expected ‘;’ at end of input
amiga/search.c:132:2: error: expected declaration or statement at end of input
mingw32-make.exe: *** [amiga/search.o] Error 1
Execution terminated
-
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 :)
-
yeah, thanks, i barely can compile stuff let alone fix it. in the unlikely case, should i find the cause though i will let you know.
-
Here are plenty of skilled coders, hope one of those 68k gurus can help you.
Maybe itix could help you with this? His port was MUI but this problem is not Reaction or MUI related
-
i think i can just switch back to 3.4.0 for the time being. but as i think 4.5.0 is just much more restrictive to eventually broken code it might be good to pay attention to these problems. what makes me think this, is that i dont get this type of problems except with contetnt of amiga dir. please dont take it as any sort of critic, chris, i just wonder.
-
might be worth posting on eab and utilitybase as well.
-
i might open a thread on utilitybase, this weekend i have priority things to do though.
-
Wawrzon: I really appreciate your input to this. I can promote this any forum you wish.
I bet that you get all hepl you need, if we play this right. And ofcourse, if you give detailed enough problem descriptions.
I've accout quite much every amiga forum ;)
-
Would you let me be your project cordinator?
You have a problem, I ask this in all that I know.
I get an answer, I point you that direction, give a link for those who are willing to help?
-
Lets start: Piru are you only whing or what? Itix you promised this, about a year ago?
-
as i said. dont hold your breath. everybody else here that has the slightest idea of programming is a better candidate to accomplish this, i am only having a look on it since nobody else does. so dont call on piru or itix for now. to be helped with something you have to know how to use that help.
-
If I can ever get my freaking amiga online I'll look into this as well. Cant say Im not getting pissed at my amiga by now though, hopefully I dont stab it to death before I get a chance to look into Netsurf.
-
i think you dont need internet to test netsurf. you can do it locally. i also have no internet on amiga for some time now since i resigned on my stationary connection, an appropriate 68k poseidon class has not yet been released for my surfstick. ;)
-
i think you dont need internet to test netsurf. you can do it locally. i also have no internet on amiga for some time now since i resigned on my stationary connection, an appropriate 68k poseidon class has not yet been released for my surfstick. ;)
I've got a couple of hours free later this afternoon, please could you send me a zip of what you have so far and i'll have a look at it?
-
ive uploaded the source as well as libs and includes sent me by artur here:
http://www.daten-transport.de/?id=F3g3e2eayzcD
since ive ended up using not exactly the same libs and includes as him ive uploaded what differs in files marked with wawa. it must be only libcurl and libxml2 related.
devcpp project included is meant for testing the particular sources.
you will have to edit or create makefile.config ive initially removed all plugins from the build.
hope nothing has been messed up while upload. im sitting on a bad mobile connection here.
-
btw, i always comment my changes to whatever sources with //wawa, so its easy to find. in this particular case i only remember to have made one or two.
in case of problems or further requests please come back to me. also if any include is missing, my whole folder is multiple mb, i just cant upload it from here.
-
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.
too bad that the natami is still not here and show this.
and if you use a native GUI or not doesnt matter for netsurf speed.
problem of netsurf is too, that it can only support 1 pixelformat per bit depth.
I have done the convert routines to use rgb32, or rgb16, but this work not good on voodoo boards and some other cards, but SDL offer to support all cards and can swap data, and with a fast bustransfer speed this cost not so much noticable time in scrolling speed.
so there need another netsurf build do, that support bgr32 and rgb16 PC.
then need release 2 versions, and i am too lazy to add the pixelformant converter for another pixelformat again.
but if somebody add the code in netsurf framebuffer to support rgb16PC, then scroll can work faster on Voodoo 3 cards.
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.
-
hubbub problem found, if not yet completely solved. its too old libxml2. replaced headers with those of os4 aminet distro and now it compiles ok. waiting for arturs static lib, which should solve linking stage when we come to that. now the amiga dir must get our attention.
Artur can send you complete archive, only you need do is make and all compile.I have no actual version
but its important that you not use GCC 3.4.0.use GCC4, because GCC 3 give you only buggy code, when you enable optimizer.
-
lets give it a try, none here is contributing to netsurf sdl so no time wasted, and netsurf dev team is critical baout doing plane sdl ports, so an native port would fit their agenda. also sdl not being slow in itself, netsurfs sdl plotters might be not as optimal since they do not get much attention from netsurf team. i think its good to have a netsurf port across amiga platforms, as it coule be debugged better. i just wish chris had chosen mui 3.x rather than reaction which would make this more portable (mos and aros in my mind)
-
Artus should send you complete archive, only you need do is make and all compile.I have no actual version
but its important that you not use GCC 3.4.0.use GCC4, because GCC 3 give you only buggy code, when you enable optimizer.
hubbub is compiling fine now. gcc4.5.0 problem does still apply.
-
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
-
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
-
btw, i always comment my changes to whatever sources with //wawa, so its easy to find. in this particular case i only remember to have made one or two.
in case of problems or further requests please come back to me. also if any include is missing, my whole folder is multiple mb, i just cant upload it from here.
Thanks, just got to clean the kitchen and then i have two hours to devote to this. :)
-
>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.
Have you compile on OS4 a netsurf sdl version and compare speed ?
wawa own OS4, so its possible to compare render speed between OS4 and OS3 SDL version.
it was that native OS4 version was slower as OS3 SDL.
also OS4 Version is report from some user as unstable.pages crashes whole OS4, on netsurf 68k they crash not whole system.
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.
Artur have some gadgets change so they work with agar GUI and SDL.
I still dont understand wy netsurf team does not support a small netsurf version that can run on handy etc.
netsurf is a small browser but need on the portable version with gtk a big and fat GUI system.
So wy not a smaller GUI system use....
and btw
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.
-
that xinvaders 3d work with amiga port of x11 was a pure luck, i have not been able to compile any other x application for 68k.
and i dont have any os4 installation anymore. sorry.
-
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.
-
I don't know sigle SDL program, that would be joy to use with classic amigas.
With that logic Rick Dangerous is too difficult program to 68k amigas, because xrick (sdl rick dangerous) is just a pain in the ass
-
aminet seems to be down atm, otherwise i would point you to a few simple sdl game ports i ve done. it was always my priority to have it working on classic at acceptable (if not always at full) 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.
you can see the speed and can see if Cairo is a speedbrake or not.
but if you have a PC, you can compare the speed with netsurf SDL 68k too.
I have no OS4, wawa seem not want it install again, so we cant do more speedcompare
We have done a speedtest that do stress the gfx part of netsurf most.
I measure the time a big html page need to show.there need lots AA text render, but no CSS layout is use.
I use the 74 kb history.html file of ibrowse for text.
It contain 831 lines simular as this
- Fixed WACL PAGEURL not working for blocking embeds
- Renamed WACL DELAY and HIDE options to DELAYIMAGES and HIDEIMAGES, whilst adding new DELAYEMBEDS and HIDEEMBEDS options to allow blocking of flash anims, etc
- F
this file is show in 2 sec on a classic amiga with AA text.so this show, speed is optimal with such a big text file.And print of AA text is the most complex graphic action a browser do.
but a simple Forum page with only few text and some few graphic, need more than 15 sec on classic, even if that it is not load from internet.
that show, that you cant get more speed, by use of native GUI.
>I don't know why you are so against NetSurf on OS3 with a native >GUI.
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 , because it bring no advantages of speed, usability.only scrollspeed on some GFX Cards can get faster with a non SDL version.but i can in SDL Version too add another pixelformat converter.I think thats much less work, as native GUI.and with new pixelformat converter, then no speedup of GUI and native is possible, because the Limit is the GFX Bus.
netsurf team have in roadmap to speedup netsurf, but nothing happen since now, frame support, java is miss, so i think when spend much time in Port a browser, better put in Port of OWB.
but if netsurf is easy possible to port and mainten as the SDL version, wy not release newer SDL Versions.
And if somebody want do a OS3 version with native GUI, he can of course do it, and if its here, offer at least same features and at least same speed as SDL versions, i use this
-
I have compiled netsurf sdl and gtk for linux and sdl is faster.
This site:
sdl internal | sdl freetype | gtk
3.0 s | 2.9 s | 3.9 s
-
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.
-
I would bet that 68k native netsurf would be at least 30%-50% faster, that would make it totally useable.
And it wouldn't lock computer for tens of seconds like sdl version do, wich would make it feel even more faster.
;edit: lock compter is actually not true, it locks itself during page loading and when it is full screen mode it is like it lock whole computer
-
Ok... I haven't had a chance to go over the code in detail yet, but I'm going to see if it will be possible to compile the GTK version against the GTK-MUI includes from AROS.
Hopefully it shouldn't be too complicated or long-winded a process.
-
Ok... I haven't had a chance to go over the code in detail yet, but I'm going to see if it will be possible to compile the GTK version against the GTK-MUI includes from AROS.
Hopefully it shouldn't be too complicated or long-winded a process.
I'd like to have a go at a 68k AGA port but I'll wait till the new IndivisionAGA Mrk2 is released so that I can do direct 65k colors (no conversion or C2P needed).
-
I'd like to have a go at a 68k AGA port but I'll wait till the new IndivisionAGA Mrk2 is released so that I can do direct 65k colors (no conversion or C2P needed).
That sounds cool, my Amiga coding skills are a tad rusty so this is just a little play project for me to re-acclimatise myself.
The GTK-MUI wrapper seems like an ideal place to start before getting my hands dirty with lower level stuff.
I'll be working on a A4000 with Picasso IV and 060 but I can test on my A1200 with plain old AGA and 030 too.
-
>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.
yes of course it bring some advantages, but the most problems, many pages can not show with netsurf correct and faster speed all amiga users want, is not possible (only for scrolling for non rgb16 PC Cards)
And this is what i tell, because i have do some tests and profiler builds to see if SDL have a slowdown.
here is a thread i do about this using gprof.i do more tests with render compleyx sites etc.the log i post was only a netsurf start
If you have a linux, you can build a SDL netsurf and use a profiler build,(dont forget to compile a SDL for profiler support).then you can compare with the GTK Version.
http://utilitybase.com/forum/index.php?action=vthread&forum=21&topic=1877
and because i have test this, its a lie, when i write, that a native Version is faster.
>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.
I mean nothing is happen, on speedup since 1 year.netsurf devs have no time for gsoc.but when look large progress is done during netsurf was in gsoc.
Now 1 year is past, i know lots changes are in netsurf add, because libnsfb and other sdl files must be change, to compile with newest core.
currently libnsfb still not work with current core, so i need again modify 16 bit libnsfb to bring in the big endian pixelformat AOS need.
but when look, what inet sites can netsurf show more with newer versions, i mostly find none.
>I would bet that 68k native netsurf would be at least 30%-50% >faster, that would make it totally useable.
I have get the profiler working for ixemul 68k.On non other AOS system a profiler can work.
I explain what a profiler is for non developer
http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29
And i see in the output that all SDL calls are not listet, so teh consuming is below 10%
all higher time usage is netsurf non graphic core.
even if a wonder happen and speedup really is 30-50 % its too few to be usable
remember this inet site need on classic 37 sec.so 50% speedup is a time of 25 sec.
I really notice no diffrence if the inet page need show 25 sec or 37 sec.all is too long in compare to other AOS browsers.
on other side use a X86 and winuae, page show is around 4 sec.
-
For me the biggest arguement for a non SDL version is so it's not restricted to graphics card users.
-
For me the biggest arguement for a non SDL version is so it's not restricted to graphics card users.
this of course does with native version work more slow.netsurf have no planar graphic, all is render in 24 bit and need then convert with complex code to 8 bit planar
If you can test how slow AGA is on a 640*256 screen in 8 bit, you can see how slow all go with scrolling.
8 bit look very ugly, because web designer never test a page how it look on 8 bit, because all Systems today in use support more than 8 bit.
I dont believe that anybody use netsurf in daily use on amiga without GFX card.
I think you have a PC or mac right, and show a webpage cost you 4-8 sec of time.
And i dont think that you use then your amiga AGA daily (what CPu you have btw ?)which need to show a page around 50 sec or more(with a 68060 50 MHZ CPU), and give a programmer money for this.
I know there are some users that have a naked A1200, which they use very rare and want see that this old system can run new software same fast as a modern PC and only then they maybe want pay some donate
but this is impossible, and if try to do that, is only waste time.
on amiga there are so few developers and i think this time should spend do more usefull projects.
and if somebody develop for free, he do that mostly because he want use it himself, or hope that other help him and share work.
-
I dont expect to be using 256 colors with my A1200, but I'd still like to be able to browse with it. Also I dont think anyone using a Classic Amiga expects it to be as fast as a modern PC. Classic users are enthusiasts, not stupid. :)
I simply want to have a better browsing experience than whats available with Aweb/IBrowse or Voyager and netsurf seems the most likely candidate. Going by the required specs of other system, the engine should hopefully be usable on a moderately upgraded Amiga.
-
And i see in the output that all SDL calls are not listet, so teh consuming is below 10%
all higher time usage is netsurf non graphic core.
even if a wonder happen and speedup really is 30-50 % its too few to be usable
remember this inet site need on classic 37 sec.so 50% speedup is a time of 25 sec.
I really notice no diffrence if the inet page need show 25 sec or 37 sec.all is too long in compare to other AOS browsers.
on other side use a X86 and winuae, page show is around 4 sec.
Yes of course you are right, as the internet gets more demanding (almost by the day it seems), more processing power is required. Even if 68k NetSurf rendered in AGA 'for free' it would still be slow compared to any browser running on x86.
I guess the 'fun' would be seeing just how fast/usable it could be on AGA 68k and there's obviously room for improvement.
-
@bernd_afa
You've explained your point well, but AGA classic users want a new browser. Once we have a working version of Netsurf, it will probably spur classic developers to work further on it to improve it's speed (As Nova Coder has managed to do with day of the tentacle and scumm using kalms c2p etc). It's up to them if they want to give it a go. The amount of time you've spent posting negativity, you could have spent helping.
Classic users are like any other retro computer hobyists, they all own PC, mac and Linux machines, but they want to see how far they can take their old favourites. But you already know this. I'm typing this on a dual core PC, but I still get excited about a new browser on my A1200. Go figure :)
-
My idea, and I'm not working on this is at the moment, so don't ask...
To get an idea of how fast netsurf or OWB or whatever browser could be on slow machines one could port it so it just writes to a fast-mem buffer without displaying anything, except a "loading... block in window area" and see how that times out, then work on how to transfer the buffer data to Amiga window rastport depending on how it's updated and what screen type it has to render to. Maybe draw some best match luma levels first then add best match chroma info for some fixed pallette pens, etc. for low color screens such as a 16color workbench, or even open its own 8bit greyscale only screen and use that. It might not be pretty, but might be usable... Then go on to investigate profiling the underlying HTML, etc. and layout engines in more depth, options for javascript, plugins, etc.
-
Netsurf could be THE brower that people use daily and many of them are browsing sites like aminet.
8bit and 640x256 should be ok
Hope you guys succeed to make it native, with prober amiga style gui
-
8 bit look very ugly, because web designer never test a page how it look on 8 bit, because all Systems today in use support more than 8 bit.
I dont believe that anybody use netsurf in daily use on amiga without GFX card.
But there are people who are currently browsing with AWeb and iBrowse on their Amiga's without graphics cards...
For the most part, we're OK with the dithered pix and slower performance, but wouldn't mind at all a browser that renders better..
Personally, I wouldn't say 8-bit web is "very ugly," but then again, I grew up with old school dithering and I kind of like it.. ;-)
desiv
-
And who says 8bit would be the end, rather than the start? Shapeshifter runs on a chunky HAM8 screen....and who knows what goodies AROS might bring in the future?
-
hmm. i wasnt into this for a week, but maybe really given as bernd says that the x11 game i ve compiled was quite snappy on my a4k, maybe it would be interesting to update the x11 68k port as far as possible. i suspect though it was just due to its pure line vector gfx.
-
>I guess the 'fun' would be seeing just how fast/usable it could be >on AGA 68k and there's obviously room for improvement.
Yes, but only for fun for others code hundreds of hours doesnt make fun any programmer.
and when you see who is here that do speedoptimize, i see only Peterh and cosmos, but they do speed optimize on near unmeasurable parts.so who should do speed optimize then.
look on OS4 and partly AROS/MOS they have not many programmers fun to code on this systems, because there was much bounties and donations, for things that in windows and linux world everbody can get for free.
so if you want something not very usefull for the programmer you have 2 solutions, learn programing yourself, or do a bounty and hope that somebody do that.
I have no time to help on AGA or native netsurf if i not see a real advantage.
money i not need, i better do things that have more usability, but maybe somebody else is with money more motivate to do that.
-
Even when I say that SDL sucks for 68k CPU, SDL versin of Netsurf proves that Netsurf could be useable with 68k amigas. It doesn't need to be much faster to be useable.
1. Get rid of true type fonts
2. Native Gui
3. Support for 8 bit screens
That should enough to give about 50% speedup and SDL allso locks Netsurf when loading, wich makes it feels even slower than it actually is.
How many would be interested to support boynty of this?
And please, don't start to talk about firefox or OWB 68k, they are not possible for real amigas
-
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.
-
It doesn't need much to be pleasant experience. Big part of SDL Netsurf slowdown is because it locks itself when downloading pages.
This is something wich classic amiga users has wished from 1995, so all of you should be interested of this. Here are doable coders, one of them tries to do it. He needs a help, so could you help him?
Maybe not because:
1.)
x1000 has announced to announced to be prudtion, that is BAD and we should spam every possible computer related forum with information that it is expensive and old.
2.)
Sam460ex mobos are availlable, wich is simply wrong :( because it is expensive and powerless like old washmachine
1.) & 2.) requires all attention from us, no other efforts are possible.
Point is what are you doing with your spare time?
-
>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.
Now tell me which AGA only user have in his amiga 48 megabyte of RAM ???
the netsurf engine render all pages complete in 32 bit.This all browser do, but other browsers need lots more RAM.
If you use MUI or Reaction you need more RAM usage, because many unused libs are load
>1. Get rid of true type fonts
if this bring a speedup on your system, you can easy check, with first netsurf version.
there are two versions released, 1 with truetype fonts, 1 with internal and fast font that need no AA.
But in real world nobody see a speedup of internal fonts, so there is no time spend to support this.thats too an argument that graphic is no problem, and netsurf Core need most time.
normaly AA truetype fonts are 10* slower as non AA Fonts.
The mistake most amiga users do that do not program, is they live in theory.
Only when you look on praxis and measure speed use a profiler you can see if speedup is really possible.
and this i have done and i see that Problem is the netsurf core which use 95% of time.
and when you with a wonder speedup graphic part that is do from SDL by factor 8 you get only a overall speedup if 4.5 %.
but if you slowdown with AGA by factor 8(yes it cost lots time to convert from chunky to playnar) you get 8*5% 40% slowdown.
-
>Big part of SDL Netsurf slowdown is because it locks itself when downloading pages.
then there should give the donwload task a higher task pri.please tell that Artur
other do not help because when download and render a page, always time is share between render and download.and when render a page, and it take on a classic always 40 sec or more then of course download rate decrease, if system is too slow.
but when Artur change task pri of download task, then download is always fast.this must every other AOS browser do in same way, and have nothing to do with SDL or nor
-
>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.
-
this of course does with native version work more slow.netsurf have no planar graphic, all is render in 24 bit and need then convert with complex code to 8 bit planar
Surely something like TinyPTC with its fast colour conversion routines would help here?
-
>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.
I know OS4 is so bad design that it not show exact how many memory is free or memory a program use.This all other AOS /Linux /windows can do even with slab allocator
But maybe you can test netsurfg on Linux and look how much memory increase when you use modern pages.
I do some tests.start netsurf and open default page need 12 megabyte.so here is 16 megabyte true.
Now i click on BBC Page it need 24 megabyte.
then i load amiga.org same memory
click on reuters and last pages i show, memory usage is 34 megabyte.
start netsurf and do http://www.amiga.org org need 18 megabyte
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.
best is if your amiga have 64 megabyte or 128 megabyte.
a 32 megabyte system is too small.
but still netsurf use very few RAM in compare to OWB
But i think there is no AGA system with so much RAM out
>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.
when i start screenmode requester of AOS 3.9 it need 1.4 megabyte.
when i press flush i get 500 kb back.so this few GUI stuff need 500 kb and when i close the screenmode requester, the values get back by remove reaction classes
sdl is only 378 kb in size with debug symbols.i think when remove debug symbols it need only 250 kb
and on low memory every 100 kb count...
-
>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.
I know OS4 is so bad design that it not show exact how many memory is free or memory a program use.This all other AOS /Linux /windows can do even with slab allocator
But maybe you can test netsurfg on Linux and look how much memory increase when you use modern pages.
I do some tests.start netsurf and open default page need 12 megabyte.so here is 16 megabyte true.
Now i click on BBC Page it need 24 megabyte.
then i load amiga.org same memory
click on reuters and last pages i show, memory usage is 34 megabyte.
start netsurf and do http://www.amiga.org org need 18 megabyte
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.
best is if your amiga have 64 megabyte or 128 megabyte.
a 32 megabyte system is too small.
but still netsurf use very few RAM in compare to OWB
But i think there is no AGA system with so much RAM out
I'm sure there are many A1200 wedges out there with trapdoor Blizzards containing up to 256MB RAM.
-
>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.
-
>NetSurf + Google seems to use about 25MB,
I test with google too, need too 12 megabyte, but a few hundred kb less than netsurf page.
but so better, surf some pages or use netsurf 20 minutes in your normal surfing action.now look how much memory it need.
>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 do no trolling.You can read yourself what rigo written about OS4 mem handling here.the value of free memory is wrong.t
"""""
http://amigaworld.net/modules/newbb/viewtopic.php?viewmode=flat&order=0&topic_id=29561&forum=33&post_id=508514&refresh=Go#508477
In light of this, I shall reitterate what has been said many times before, free memory figures on OS4.1 are meaningless, so don't believe what you read in the WB titlebar.
Simon
""""
or this from ChrisH
"""""
http://amigaworld.net/modules/newbb/viewtopic.php?viewmode=flat&order=0&topic_id=29561&forum=33&post_id=508514&refresh=Go#508481
....
Rant: If OS4.1 had a proper reporting of free memory (it should not be rocket science!) then we would not even be having this argument. This is one area where MorphOS definitely has the advantage, even if it's TLSF allocator isn't quite as advanced as OS4's Slab allocator.
"""""
And here is a thread with benches, that show that OS4 slab is not advanced btw
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=29569&forum=14&106
>NetSurf memory cache is set to 10MB
i test some memory cache values, but it doesnt matter, the default on netsurf 68k is
memory_cache_size:2097152
this is 2 megabyte, or i am wrong ?
-
@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.
-
I'm sure there are many A1200 wedges out there with trapdoor Blizzards containing up to 256MB RAM.
maybe, but this are mostly Versions with GFX Card.But there have still nobody say, i have a AGA Amiga with at least 48 megabyte of RAM.or lets say 32 megaybte.
>Yes, the default memory cache is 2MB.
i test some values, but memory usage is always the same, maybe the value is not support in SDL build
Or do you notice a diffrence in memory usage when you change the value ?
I can too set it to 20 megabyte, netsurf need not more or less ram as with 2 megabyte setting
>(although I'm pretty sure OS3 does this too, so Rigo might be referring to something else).
chrisH report it as a OS4 problem and other later too, so its not in AOS 3.please read this thread more
If OS4 show correct memory such a memory loss bug even in a beta release should not possible.
but ok, for you the Hyperions seem great coders, for me not.
I only want say that detect memory loss or something is not good possible.
remember the netsurf cache mem loss Bug i report, nobody notice it, because on Linux there is not so easy memusage show as on WB.
I see this memloss after short usage in AOS 3
-
maybe, but this are mostly Versions with GFX Card.But there have still nobody say, i have a AGA Amiga with at least 48 megabyte of RAM.or lets say 32 megaybte.
Not sure where (or if) this fits, as I lost track of this thread. ;-)
But, considering how many ACA1230's have sold, I'd be willing to bet there are many more Wedges with 64M of RAM and AGA graphics... And I'm guessing many of them only have AGA graphics..
desiv
-
@Desiv. No wonder you lost rack of the thread, there's a troll under the bridge trying to drag it off topic!
And my 1230XA as had 32mb since the late ninties, i'm sure there are loads of classics with more ram than that.
-
>@Desiv. No wonder you lost rack of the thread, there's a troll under >the bridge trying to drag it off topic!
>And my 1230XA as had 32mb since the late ninties, i'm sure there >are loads of classics with more ram than that.
this mean a 68030 Card.there need do a non FPU build for this too.
maybe somebody is here with a 68030 card with FPU and a GFX Card and can test netsurf how slow all get when not have a 68060 CPU.
http://www.amiga.org need 37 sec to show on a 68060/50 System
there are 68030 out with 50 MHZ too, but when you use other benchmarks you see that the 68060 is more than 3* faster as a 68030 50 MHZ even if no FPU is use.but whe use worst case
so this mean 37*3 are 111 sec.then you need more seconds for chunky to planar conversion.lets say very optimistic 10% more.
then we are at 122 sec.
does really somebody want wait 2 minutes to see a web page that a slow PC from Year 2000 or other system show in 3 sec ?
there are web pads out, that cost 100 Eur, and they work faster and have better display as a AGA system.
-
if c2p only costs 10% then it would advocate to include support for it it into sdl or netsurf.
-
There are 1000's of computers that run software better than my Amiga, hell most PC's are a faster Amiga than my Amiga. Most PC's/mac/linux boxes are also faster and have a much larger software range than morphOS...but you still use it don't you? My A1200 is my hobby machine of choice, I don't need to justify myself to you, as to why I want new software for it.
To steal your comment:
"there are web pads out, that cost 100 Eur, and they work faster and have better display as a MorphOS system ;) "
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 to muck 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.
With attitudes like yours we would not have doom, scumm, mp3 playback etc on the classic Amiga.
-
This is amiga forum and we use our amigas thing that could be done better with other computer systems.
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.
Maybe Olsen could have some interested to get involved this project?
-
please guys, bernd is not trolling even if it looks like that. given his record of engagement for 68k, even if he is an uae-guy, he just tries to be reasonable about what can be done given current ressources. lets be honest, it doesnt look like we have any magick coders around any more.
i personally am all for trying to get netsurf with a native frontend and see if this helps, but im a noob who isnt even able to do it even if i would like. artur at least did a sdl port with bernds and itix help, which is an achivement we should be grateful of. and bernd considers netsurf easier to maintain without too much amiga-code in it. thats his point. thats it.
and now back to topic, did anyone got any further with it in the meantime? i pass for the time being, sorry.
-
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
-
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.
-
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 from me..;)
-
>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
-
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.
This is how it usually happend :) No matter how crappy first actually running port is, it makes native netsurf more interesting to others, wich include other coders.
Eventually that makes everything easier and development is accelerating as more people are involved it.
So don't hesitate to make first possible version public, mean v. 0,01b ;)
-
If you don't like the idea of working on yet another Amiga port of netsurf, there's always other fish in the sea. Maybe you would be more interested in porting Amaya (the w3.org HTML, CSS, and SVG editor and browser program) to your choice of interface.
-
have you seen what dependencies that demands? wxwidgets port would be a major task i suppose. why to propose such a complicated thing if even mauch simpler doesnt get done?
-
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.
-
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
-
I dont understand what monkey frontend is.Have you a link or so ?
It's a dummy frontend.
-
Netsurf version 2.7
* Some incomplete work towards AmigaOS 3 support.
What this actually means? How this makes easier to port it to 68k?
-
If you don't like the idea of working on yet another Amiga port of netsurf, there's always other fish in the sea. Maybe you would be more interested in porting Amaya (the w3.org HTML, CSS, and SVG editor and browser program) to your choice of interface.
Looks this isn't going to be updated anymore, although the mailinglist is still full of bugreports. Better choose an active one, like netsurf...
-
If you don't like the idea of working on yet another Amiga port of netsurf, there's always other fish in the sea. Maybe you would be more interested in porting Amaya (the w3.org HTML, CSS, and SVG editor and browser program) to your choice of interface.
Looks this isn't going to be updated anymore, although the mailinglist is still full of bugreports. Better choose an active one, like netsurf...
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.
Right On :D
-
Netsurf is easiest and only realistic choise port to 68k. Luckily spammers hasn't start to pollute this thread with OWB/FireFox/Amay etc posts.
-
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..
-
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.
-
@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.
-
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
-
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?
-
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. :)
-
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?
-
3. Workin browser for amiga os 3.9 ???? would it make you happy?
No. Should be 3.0 and above.
-
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
-
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 :D
-
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...
-
Discreet offers market place, easy way sell software. Not a boynty
-
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
-
@bernd_afa
This is a completely bogus/meaningless comparison. [Read more] (http://vlists.pepperfish.net/pipermail/netsurf-dev-netsurf-browser.org/2011-July/002520.html)
I am not discussing this further.
-
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.
-
@bernd_afa
This is a completely bogus/meaningless comparison. [Read more] (http://vlists.pepperfish.net/pipermail/netsurf-dev-netsurf-browser.org/2011-July/002520.html)
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
-
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
-
xRick wich is SDL frontend of Rick Dangerus, it is also faster with 68k amigas than PPC amigas, if we compare frames per mhz
Rick Dangerous as we know, plays about 2 frames per second and it is NOT possible, that kind of program plays faster with our amigas.
Or wait a minit.... are I'm wrong, how did native Rick Dangerous performs???? was it bog slow? totally unplayable?????
-
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.
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.
Secondly, the code they are running is completely different, compiled
for a different target and by a different compiler, with different
frontend code. Moreover, one of the processors is CISC and the other
is RISC - RISC processors have to execute more code by their very
nature of having a smaller instruction set. The display resolution of
the test machines is also different, the OS4 ones having to do more
rendering (unless screen res or window size was adjusted to
800x600x16, which I doubt, and would also impact the figures
negatively as there is a known slowness issue with 16-bit in the OS4
frontend)
i dont know but it is perfectly possible that resolution of netsurf on a classic was set to 800x600x16, there is no pages on internet that you can watch comfortably in a lower resolution and every amiga gfx card is capable to display this and more. i myself was setting netsurf 68k window on my a4k to about 1000x1000 when i was using it.
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.
äh, edit:
in particular:
Moreover, one of the processors is CISC and the other
is RISC - RISC processors have to execute more code by their very
nature of having a smaller instruction set.
might be that risc ppc processors are actually by default slower per clock than cisc 68k counterparts, as they were invented to allow them to run at for that time technology otherwise unreachable higher clocks, but then it remains an argument, because people usually count cpu speed in mhz, as in 660mhz sam440 vs amiga060/50. why argue with that?
-
>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
-
May seem like a strange idea, but due to the load times of many pages and lack of processing power of many classic amigas...
What if you had netbrowse run in its own screen as a background task behind workbench? If you want to browse you switch screens, type in web address, then switch back for awhile and do something else in workbench as your page loads.
Steven
-
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
-
Only if compiled and running on the same CPU too.
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.
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)
wasnt then the testcase in favour of ppc/os4 anyway? i thought 32bit was choosen there.
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.
i would call it a fair testcase if we were comparing different browsers on different architectures. we wonder why amiga (68k) sdl and os4 reaction netsurf ports are so slow in comparison to native risc os 68k implementation. this implementation differs as much from both as os4 differs from 68k, you dont find it a question worth examinating, do you? just being comfortable that it runs on os4 at all since the cpu is fast enough?
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
will check this out as soon i can.
;)
-
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.
-
Any news ?
Can we hope having a new browser with CSS support on classic amiga without graphic card.