hmmmm just installed opera just for a test and the results for my MacPro are Elapsed wall-clock time: 2689ms (ideal: 640ms). Elapsed non-idle time: 2049ms (ideal: 0ms). Speed: 5.58fps (ideal: 25.00fps).
Amiga is the heart and soul of computing nothing else comes close
If you used AmiUpdate for installing it the new shared objects used by 1.13+ should have been installed automatically, but if you installed it manually you have to download sobjs.lha from my homepage as well and copy the Sobjs/#? files to SOBJS: and from the OWB archive OWB/Workbench/Devs/curl-ca-bundle.crt to DEVS:.
This, in the end was what I did - AmiUpdate didnt like not being able to connect to the strohmeyer site - but this has been mentioned elsewhere as a problem with ports and AmiUpdate !
works brilliantly - although I don't like the back/forward buttons being disabled while the previous page is loaded - but thats just me I guess. Also, it does seem to go t1ts up on some sites - but the rendering looks fantastic compared to iBrowse !
Well a web page contains of lots of stuff, like Text, table, background colors, and so on, think about this as vectors, and attributes, images you do not display does not need to be in memory they can be on disk, so that a few more mb saved.
There is enough non-vector stuff on a web page. Besides, vector images take up room too...
In any case, it would be a ludicrous effort to save enough memory to make it possible to run OWB on a classic by the means of a method that would be dead slow on the classic's CPU's.
And if you come up with disk, then the only viable solution is paging anyway; which, incidentally, is already being worked on. Not that it would be that fast on the Classic IDE drives, but at least it would not be such a tremendous effort to implement.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
I'm curious as to what OWB is doing with memory, given that the requirements are so high. Right now I'm typing this in Firefox, and it's using ~32MB. With ten pages open (and browsing for a while) this can get up to 80MB. Is OWB grabbing a huge chunk of memory for itself on startup? Does it have a huge stack?
Also, how much faster would it be if SDL were dropped and the native API was used directly? It's a sizeable task, but SDL is known to add a certain amount of overhead.
BTW, does anyone know how to use the profiler with GCC?
I'm curious as to what OWB is doing with memory, given that the requirements are so high.
Always rendering the complete page, not just the visible part. That's also the reason for the 100% CPU usage on forums with lots of animated smilies on the page. For example a 1000x8000 page needs 30,5 MB RAM that way just for the empty page, maybe temorarily twice as much (it does for some gfx operations like aplying alhpa, but that shouldn't happen for the final page bitmap), on top of that the contents of the page (images/anims, text and fonts, javascript objects, CSS, ...) and of course OWB itself and the used libraries (about 10 MB code and 10 MB data, most of that for the Unicode tables).
Quote:
Is OWB grabbing a huge chunk of memory for itself on startup?
No.
Quote:
Does it have a huge stack?
The 512 KB currently used in the AmigaOS4 version are probably way too much, on embedded systems they IIRC run it with 16 KB stack.
Quote:
Also, how much faster would it be if SDL were dropped and the native API was used directly?
Not at all. Even if you have a gfx card with 128 MB RAM or more and all bitmaps always fit on the gfx card it would most likely slow it down. Drawing lines, rects, poligons, straight copies of bitmaps, etc. would be much faster of course, but that's not done much. Since it's using alpha for everything and that's not HW accelerated on AmigaOS4 it would very likely be much slower than now (everything done in software in the mainboard RAM and only copying the currently visible part to the gfx card), reading back bitmaps from the gfx card RAM is very slow.
Also, how much faster would it be if SDL were dropped and the native API was used directly?
Not at all. Even if you have a gfx card with 128 MB RAM or more and all bitmaps always fit on the gfx card it would most likely slow it down. Drawing lines, rects, poligons, straight copies of bitmaps, etc. would be much faster of course, but that's not done much. Since it's using alpha for everything and that's not HW accelerated on AmigaOS4 it would very likely be much slower than now (everything done in software in the mainboard RAM and only copying the currently visible part to the gfx card), reading back bitmaps from the gfx card RAM is very slow.
So, until we have hardware accelerated alpha-blending, an Warp3D/OpenGL-based rendering engine would probably help. I'm not sure if Warp3D supports non-power of two texture sizes (if it doesn't MiniGL won't either).
Is it possible to embed some version indication into sobjs archive filename?
If a new version of a shared object is required I'll add something, or more likely split it in 2 parts since it's very unlikely that all 4 or 5 shared objects in the current sobjs.lha will be updated at the same time. But it's unlikely that newer versions of any of them will be required at all.
Quote:
I usually download the browser from your site (once tried AmiUpdate, but there were some dns problems with OWB).
It was a problem in AmiUpdate I didn't know about, until version 1.95 it didn't support port numbers in http:// urls and tried to connect to port 80 of a server "strohmayer.org.nyud.net:8080", which of course couldn't work, instead of using port 8080 on strohmayer.org.nyud.net. With AmiUpdate version 1.96 it should work.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
