Welcome, Guest. Please login or register.

Author Topic: @Bernd_afa: OWB (68k) optimizations  (Read 16182 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Fab

  • Full Member
  • ***
  • Join Date: Jun 2009
  • Posts: 217
    • Show all replies
Re: @Bernd_afa: OWB (68k) optimizations
« on: December 19, 2009, 01:29:34 PM »
Quote from: bernd_afa;534456
The source is outdate and OWB core is change much since some years.If you wish i can send you the source(write PN) or ask Jörg.but you can nothing do with it.its way toooo slow and too old.the OWB team have also speedup it

on AROS can see, OWB is slow, i dont believe it is faster on MOS or OS4, because Cairo cost too more performance.,OWB have no diskcache.On netsurf they are working on diskcache.

Its always good to wait instead spend much work, maybe the red versus blue war end in 1-2 years and working together is better possible of the few existing amiga devs

I need not sell a OS more by have a good browser, so i need not spend much time, i can wait some years so things go faster and browers get better portable and chrome enhance.

Sooner or later i buy a 4 core I5 or I7 then compiling get lots faster, then maybe at least the compile time of this slow C++ monsters is acceptable and i have fun to do it

Sorry, but this is mostly wrong. Sure WebKit isn't as fast as ibrowse (what a surprise), but it's still *much* faster than NetSurf on the same machine, actually.
And my OWB port (and also OS4 one) is also *much* faster to scroll on my Peg2 than on a Xeon 2.5GHz machine under linux with the plain OWB SDL version. This isn't surprising, considering the SDL implementation doesn't implement a "smart" scroll method at all. As the AROS version doesn't implement that scroll method either and that blitting isn't exactly very fast on AROS, it's normal you found it slow, but it can be much faster.
« Last Edit: December 19, 2009, 01:31:47 PM by Fab »
 

Offline Fab

  • Full Member
  • ***
  • Join Date: Jun 2009
  • Posts: 217
    • Show all replies
Re: @Bernd_afa: OWB (68k) optimizations
« Reply #1 on: December 19, 2009, 03:09:36 PM »
Quote from: 0amigan0;534469
The only bottleneck would then be the high compilation time.

@Fab:

How long would it take to cross-compile your version on a *very* powerful Windows machine ?


On that Xeon PC/Linux I use for crosscompilation, it needs about 30 minutes to compile OWB from scratch (a bit more when SVG is enabled). On my Pegasos2, I tried it once, and it needed 6 hours (but gcc I/O is better handled on Linux, anyway, so it's not surprising to see such a difference). :)

Anyway, on a very recent machine, it would take 15-20 minutes, i guess. I can't comment about Windows, though.
 

Offline Fab

  • Full Member
  • ***
  • Join Date: Jun 2009
  • Posts: 217
    • Show all replies
Re: @Bernd_afa: OWB (68k) optimizations
« Reply #2 on: December 20, 2009, 07:30:07 PM »
Quote from: bernd_afa;534601
>Huh? So you seriously think just because there's software X in linux distros it somehow >measures popularity of that said software?

there are also some patches for windows/linux and OWB old versions, but nobody do actual OWB release for that system.

if so, i can maybe install a small linux on vmware and test OWB here in compare with Linux netsurf.

and btw, can you tell me page times, and links where OWB is faster ?
I see the video from Fab, here the load time of full page was good, but the time the page was show first and can scroll, was much longer as on netsurf and other browsers.this cant be problem of internet, because in this early stage very few data is need from Internet.

you should not test the old Netsurf for MOS on reuters or some other page.because this old Versions have Bug that redraw is done too often when there is a image skip delay > 1 sec.thats fix in newer versions 68k have but MOS not.



My video was actually quite slow comparing to what it can achieve on a proper link (or proper router). My router often gets unresponsive after a few days uptime. Yet, it's still much faster than what i could get from netsurf (both MorphOS and current 68k version).

Quote

>The reasons for AROS OWB slowness were explained already.

You mean because of SDL ?

a browser is simple written, it render the page in ram with CPU commands.so the time the page is show first is same.maybe the transfer to GFX Card is in SDL only 4 fps but still here 4 fps are 0,25 sec, and we talk about several seconds that OWB show the page later as other browser.

also i see OWB on AROS show same fast as netsurf the whole page.but netsurf or other browser show 2-3* sooner the page.so i think its OWB dependent.

I dont know how can MOS version be faster.


First, the plain SDL version is much slower at scrolling for the reason given earlier and then, regarding network transfer, it's mostly down to Curl usage (the default in OWB is not optimal for fast connections) and underlying TCP/IP stack too. In the MorphOS port, i also moved the whole network part to a dedicated thread to avoid blocking UI during DNS resolution or other network transfers, which effectively gives a better feeling too.

Quote

using webkit is ok, but the trick is use it in best way asynchron and here it seem the OWBAL have some Problems.

So wy not accept this and report that Problem in OWB ML to discuss instead say OWB is fast and great ?

the result can only be a better OWB and it get more attractive and then come upto date Linux builds maybe.That OWB have no diskcache all browser have is also a Limit.


I don't see why the availability of linux builds has anything to do with the quality of a program. And for your information, OWB is mostly an API layer above WebKit designed to port and use it more easily. There's no major functional difference with plain WebKit (which is used in Safari, Chrome and other browsers). And about diskcache, well, it's not a big these days, and there's a memory cache, so it's ok during a same session, anyway.
 

Offline Fab

  • Full Member
  • ***
  • Join Date: Jun 2009
  • Posts: 217
    • Show all replies
Re: @Bernd_afa: OWB (68k) optimizations
« Reply #3 on: December 21, 2009, 02:29:25 PM »
Quote from: bernd_afa;534696
>Plus, I don't understand why u shouldn't believe Fab when he says that his MOS version >is faster than AROS one ?

I see this video from Fab when load http://www.cnn.com and with AROS OWB i get same times(7-8 sec) to show page first.safari/chrome is lots faster around 2-3 sec.netsurf on my winuae need 4-5 sec.not optimal, but better as OWB on AROS, netsurf Team is working to add a cache.I think when its done, netsurf is speed up.

http://fabportnawak.free.fr/vids/cnn.mpg

sure he tell situation is not optimal, but normaly i think when doing a vídeo before first try once and then do it again to see if time is same and reproducable.and when his OWB really is so fast as firefox or other windows webkit browsers, then its clear notice if a browser need 2-3 sec to show a page or 7 sec.

Also you can see on Video, he do no reload.he type the name in, its possible that there is something on cache.



When my router is responsive, cnn displays in 3-4s. But should we remind you once again that network speed and latency is a *very* important factor in this kind of benchmark?

And no, there was no cache involved in my test.


Quote

but still, it run slower because of slow internet,OWB load too much data from internet before he begin to show the page.also when press the page back button the load of the last page is same slow as a full load.this i see on 68k OWB and AROS OWB.

normaly when press page back the page is show in around 0,5 sec complete.On netsurf some pages are show fast some not, but as netsurf Team told teh cache is currently broken and is rewritten to do disk caching too.


There's a page cache in WebKit, that just happens to be disabled by default in OWB (understandable considering their embedded orientation). When page cache is enabled, it obviously displays in a fraction of second, if the page is still in cache.

Quote

I dont know, i have not compile it.there is a AROS version from 2006 nobody use.and now when somebody really need cairo, he need the newest version, maybe here is change something.Or where is the source for MOS Cairo

Cairo is a backend and i think it need some platform dependent graphic stuff.

But i remember when firefox change to Cairo render it get too slower.I think best is use SDL and fix teh scroll problem by using HWsurface and sdl blit command.


Cairo/Pixman straight-compiles (unless you add hw acceleration of course, then it's a lot more work). And there's a reason to use Cairo over SDL too. In OWB, they also moved from the SDLgfx graphics backend to Cairo one, because WebKit just needs a capable gfx library and SDLgfx isn't up to the task. So in current OWB SDL implementation, rendering is done with Cairo and the result is blitted with SDL.

Quote

i think on 68k there are more devs that can do it.But there seem no perfect browser for amiga currently here.

the browser thats done on MOS or OS4 are done from the OS Developers.On a commercial OS its important to have a better than nothing solution as fast as possible to sell more systems.

but developers that develop for fun, want do something better usefull or when they get money(see AROS Port)

And as can see, for 68k there are no bounties or something else as on AROS or OS4 or MOS.


I'm not sure what you imply there, but should I remind you I didn't charge nor ask anything for OWB? It wasn't a bounty either.

Also, to me, it seems OWB+SDL and NetSurf+SDL ports are closer to the "better than nothing" quick hacks than the other NetSurf or OWB ports on OS4/MorphOS. At least, there was some real work involved in the latters to build a GUI around the engine, unlike SDL ports.

@0amigan0
Quote

Fab already said MOS OWB is faster. I say: let's trust his words.


Actually, I didn't say MorphOS OWB was faster than OS4 OWB. They're roughly the same I'd say, both faster at scrolling than AROS or Linux ports (which is normal, since they lack a proper scroll method). The main difference would be MorphOS port uses a thread for network, which avoids blocking UI.
 

Offline Fab

  • Full Member
  • ***
  • Join Date: Jun 2009
  • Posts: 217
    • Show all replies
Re: @Bernd_afa: OWB (68k) optimizations
« Reply #4 on: December 21, 2009, 02:45:18 PM »
Quote from: bernd_afa;534715
>more hands are better than >one.
>Fab asked no money in order to do it.
Yes, but we not know if he get money from MOS sells.

that he accept no bounty can also better Marketing.

Or what do you think when Apple/MS make a browser that miss since some years the importants things as a download progress bar and more.
and there is on Apple/MS Homepage a button for bounty ?


I don't request anything from MorphOS sales, and if I did, it would certainly not be about OWB. I'm generally not at ease with requesting money for an opensource software where i only wrote 0.1% of the whole code.

Maybe you're thinking about that other open(soon-to-be-closed)-source bounty-based browser ported by some OS core developers. :)

Also, I'm not sure what you are referring to about missing download progress, but i hope you don't refer to my port.

Quote

I like more the AROS Version because it use no Cairo and is a MUI class.So browser can use with every application.and because its a class there is possible to build a amiblitz GUI for example.

because i use winuae i can use windows browsers until the browser situation in amiga land look better.maybe MOS OWB get as MUI class some day.then its more easy portable

Fine with that. It would probably be easier to port since you wouldn't have to adapt some MUI4 calls. You'd lose all the other features that are not available in AROS version, though.
About the class, it's certainly something nice to have, but I think the current AROS class crashes if there's more than one opener, which is a bit limiting. :)
« Last Edit: December 21, 2009, 03:35:52 PM by Fab »
 

Offline Fab

  • Full Member
  • ***
  • Join Date: Jun 2009
  • Posts: 217
    • Show all replies
Re: @Bernd_afa: OWB (68k) optimizations
« Reply #5 on: December 23, 2009, 02:16:25 PM »
Quote from: bernd_afa;534886
If you see no diffrence, then MOS OWB have same Problem.Here can too read from 2 OS4 dev that OWB load much of the page.try also the link on MOS OWB

other browsers need not so much load before a page is usable(mean scrollable/movable)

http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=30292&forum=32#526721

http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=30292&forum=32#526765

this page reload in 1-2 sec on windows browsers.need test how long it take on AROS.

There's a difference between speed and responsivity, but that must be too subtle for you, and these 2 OS4 dev have no idea about the real issue. It's not about loading too much data, really. You might consider WebKit is the very same engine as chrome and safari use, and OWB didn't change its behaviour there. The problem is in the network handling, like i said several times before.

In MorphOS port, I moved network code to a dedicated thread, which avoids the responsivity issues listed in that thread. So i can act on the document as soon as the document(+css?) is received, just like it should be. I can even profile it precisely with WebInspector, actually.

About your (meaningless) benchmark, that page reloads in 2 seconds on OWB MorphOS, so what?

Quote
>When page cache is enabled, it obviously displays in a fraction of second, if the page is >still in cache.

And how can enable this, so i can check in AROS/68k sources ?

In webcore settings, the name is very explicit (pagecache and cachemodel).
« Last Edit: December 23, 2009, 02:21:33 PM by Fab »
 

Offline Fab

  • Full Member
  • ***
  • Join Date: Jun 2009
  • Posts: 217
    • Show all replies
Re: @Bernd_afa: OWB (68k) optimizations
« Reply #6 on: December 29, 2009, 04:46:57 PM »
Quote from: 0amigan0;535361
I didn't know that.
well, never mind. :)

Indeed, my setup isn't ready at all for a 68k target. Not that it would be impossible of course, but sdk stuff always a tedious task (at least for me :)).

In any case, if a 3.x developer with a "correct" gcc4 + libnix setup (no ixemul, thanks :)) wants to give it a try, i'd be glad to help him. It won't be a very trivial task, so it needs a bit knowledge (i.e more than configure/make :)).

Some things would have to be adapted or "degraded" to work on OS3.x/MUI3.8 (network thread support, MUI tabs or list methods, ...), but it's just some additional work, nothing impossible (and if it's too scary, one could always start with the AROS port first, which should compile more easily on 3.x). About the speed it would have on a real amiga, i couldn't tell though, but it would certainly be substancially than current SDL version in any case, at least regarding scrolling.
 

Offline Fab

  • Full Member
  • ***
  • Join Date: Jun 2009
  • Posts: 217
    • Show all replies
Re: @Bernd_afa: OWB (68k) optimizations
« Reply #7 on: December 31, 2009, 02:28:14 PM »
Quote from: bernd_afa;535535
>but it would certainly be substancially than current SDL version in any case, at least >regarding scrolling.

I look at the OWb 68k 1.2 (SDL version) and test without JIT.Scrolling is very slow need ca 1,3 sec for 1 frame.netsurf scroll also when pixel format not match with at least 8 fps on my System and disable JIT.

But when use the JIT OWB 1.2 scroll with 10-15 fps and thats lots faster as AROS Version run on my System.AROS Version scroll only with 3 fps on vmware.

Now when use OWB 68k 1.4 that use a enhanced SDL Version.It scroll on my system without JIT with 10-15 fps thats fast as netsurf do when pixelformat in SDL is ok.



The thing is when you scroll 20 pixels or so per step, it should be much faster, when a backstore scrolling method is used, which isn't implemented in the SDL backend.
For instance, here, on peg2, on average, with a 1024x768 window, rendering+scrolling a 1024x1 line takes about 2 ms. Rendering the whole page can take about 40-100ms (depending on content). So, implementing a proper scrolling method can effectively make scrolling dozens times faster (of course, when you scroll with a very big step (page per page or more), it doesn't have any benefit anymore).

Quote

But!!!

The OWB 1.4 need for a page load 2* longer as the OWB 1.2 full SDL Version.



No idea, but like i said several times, there are many things to be done in network layer.


Quote

So i think best is to fix in the SDL Version the pixel Match Problem.It seem SDL is in general very slow when it must convert pixel Formats.Same Problem is maybe with Cairo.

on 68k some GFX Cards work in RGBA some in BGRA.Cairo use same as opengl intern RGBA Pixel Format.any other must convert and get speedloss.

Do you know if its possible to set the Pixelformat of the OWB render engine to any Pixelformat, or use the OWB render engine a fixed Format ?

the Netsurf Render engine work only in the ARGB Pixelformat.This Pixelformat does Cairo not support native, so Cairo get some speedloss because it need convert internaly

What Pixel Format MOS use ?
Can MOS open screens of diffrent Pixelformats ?


The SDL version of OWB didn't use cairo at all. It used sdlgfx to render (since a few weeks, it can also use cairo to render, blitting still happens in SDL of course).

And by the way, Cairo supports ARGB pixel format.
 

Offline Fab

  • Full Member
  • ***
  • Join Date: Jun 2009
  • Posts: 217
    • Show all replies
Re: @Bernd_afa: OWB (68k) optimizations
« Reply #8 on: January 12, 2010, 07:33:18 PM »
Quote from: bernd_afa;537896


I have measurement enough and i notice always the same that other have written too (link in this thread).OWB show a page much later as all other browsers.I see this on a Video too.If this video is not good, then wy there is no better.

And its near impossible that this in MOS or OS4 is better

In Amiga land its known everybody want have the best system and you cant believe what cant see with own eyes.



Will you finally understand that there are some differences between all these OWB ports? In MorphOS port, I changed a few things because the default values were just not adapted for "modern" inet speeds (that small change can actually make transfers 20 times faster, going from 400kB/s to 8MB/s locally ...). And more importantly, I threaded the network to give a better responsivity.

Recently, the AROS port implemented backstore scrolling, and also the trivial (but needed) network speedup. So you might try it again, and finally understand that the plain SDL OWB port doesn't mean nothing at all, performance-wise, and that some work is needed, just like in netsurf...

Quote

I like to see this too, but as long every system want fight for more user with a better browser its lots work when all systems do their own Version.

And i have hope in 1-2 years when the MOS/OS4 developers maybe see there cant make enough money with the OS they stop the lots work spend on browser.

and then the last existing users/dev maybe do together bring a actual browser.
I can also port in 4 years OWB to 68k, maybe then OWB is better


Or maybe that in 4 years, you'll have finally understood that not everyone wants to develop on a dead OS, and that if you really want it, you could port it yourself, instead of waiting for someone to do it. And by the way, I offered my help for a 68k port, and someone contacted me about it.