Three things I've come across, and have been meaning to mention:

1) Progress bar seems to indicate the file-size for the previously loaded page.
This is especially noticeable when attempting to load a null webpage (ie where no file size is returned from the request, such as when MorphZone.org is down). A suitable amusing example of a null page to test with is www.amiga.com

The progress bar indicates that 0b of xxxkb has been received (it should indicate 0b of 0b received, or 0b of unknown size received), where xxxkb is presumably the size of the previously-loaded page.

When moving to another page after a null page has been loaded (eg clicking on a bookmarked link), the progress bar indicates (initally) that 0b of 0b has been received (ie the size of the previous null page).

2) Zooming issue ('View'/'Zoom in' or 'zoom out') - the magnification variable is maintained, but the magnification itself is not maintained between pages.
Example: with a page 'zoomed in', navigate to another page. The new page is displayed at standard resolution (ie not zoomed).
Now select 'view'/'zoom in' - the page does not zoom from standard resolution, but instead magnifies to the previous level of magnification +1 (variable is stored, but not used in initial page rendering).

3) Slow rendering of certain pages (CSS issue?)
Particularly noticeable on facebook.
If I navigate to www.facebook.com, the page can take around 35 seconds to display (according to the network activity box, this is whilst loading a couple of css files).
If, however, I navigate to www.facebook.com, then immediately stop the page from loading, then refresh - the page displays almost instantly.
Wee-eird, dude!

@Fab - Hope this is helpful in isolating a couple of bugs for you.

And thanks for your continuedd support - OWB remains my most used browser (although for this post, I am using FF).

btw - being able to spoof as IPad is a genius move - I have it set as default (everything which can use html5/mp4 rather than flash now does so by default ) and only disable it when I need certain tools (eg facebook chat).

Best Regards



Rich

[ Edited by boot_wb on 2010/10/5 15:02 ]

1. not an issue I would worry about, but it may bother others and spur someone to want to fix it.

2. Sounds like a simple thing to identify and possibly fix for someone that knows how. I would not want the new page zoomed to the same amount as a previous page that I had zoomed in on, but think the zooming in on the new page should start at the standard resolution +1, not the previous zoomed in resolution +1 as you state it does now.

3. I think facebook.com is slow on all computers and browsers and often see the exact same behavior you are describing on my Quad Core 3.0GHz PC using Firefox, so I would be surprised to find out that what you are describing is a bug in OWB.

@Fab,

I hope that since you have open sourced OWB for MorphOS after version 1.9 it does not mean that you will no longer be doing any work on it yourself, but rather that you are encouraging others to help with the workload of keeping the MorphOS version of OWB as current as it can be. Thanks for the great work you have done on it up to this date.

@boot_wb,

Thanks for the tip regarding spoofing as iPad. I will try that out from now on.

> I hope that since you have open sourced OWB for MorphOS after version 1.9
> it does not mean that you will no longer be doing any work on it yourself

OWB for MorphOS has always been open source. The source for v1.4 has been online since August 2009:

http://fabportnawak.free.fr/owb/src/

As far as I remember, v1.4 hasn't been the last release from Fab ;-)

> but rather that you are encouraging others to help with the workload of
> keeping the MorphOS version of OWB as current as it can be.

Real reason for putting v1.9 source online can be found there:
http://www.amigans.net/modules/newbb/viewtopic.php?post_id=55772#forumpost55772

> Thanks for the tip regarding spoofing as iPad. I will try that out from now on.

Fab mentioned that tip in the OWB readme btw ;-) And yes, it works great for plenty sites.

1. The progress bar stuff is really what webkit reports (so any weird size it could report is not my imagination :)). Now there was some case where progress bar wouldn't match the current active page, but i think it's fixed since.

2. The zoom factor across webpages has been fixed by webkit recently. Next version (or the one after, depends) should have that fix.

3. Facebook isn't noticably slow, here. It's even quite faster since 1.9, actually, thanks to the fixed element scrolling optimization in webkit: before, if there was a fixed element in the page, like the facebook status panel, any scroll operation would trigger a full redraw instead of just scrolling+redrawing the new displayed area. But that's not the case anymore.

Now about your loading speed issue, it might rather be related to a network connectivity issue (some people experience random performance with mac mini ethernet driver).


@amigadave

I still work on OWB (as much as my free time allows me). I also released OWB 1.4 as opensource in august 2009. I released 1.9 sources too because i was asked. But apparently, it wasn't very useful so far. :)

3. confirmed. not just with facebook but with many sites. first access of the site takes forever, but stop it and reload - site is there (its not about rendering but loading).
so fab, its not just me and not my connection:

3. Nope. It just shows you both have some weird DNS server or network configuration.

[ Edited by Fab on 2010/10/6 2:29 ]

Geees! then add me to the mix as well, as I also experience the loading issues!
I was quite about it but since the thread is opened, might as well confirm too. The thing is If I use the upgrade, by itself in it's own original unarchieved state, it (owb1.9)works better, as for the waiting, yes I also stop, and reload for bringing various pages up. This is not just a owb thing at times chrome does it too.
however using owb from my regular upgraded folder(where I just drop in the new source) tends to react much slower, and locks the tabs, movement everything til it eventually loads. I thought incresing the connections to 16 would help but not. I meant to ask you if it may be a cache issue? But yea upgrading is slower than just unarchieving and using the fresh update.

Maybe you should rather check your disk fragmentation. Files in conf/ like History.db, cookiecollection.db and most importantly WebPageIcons.db can grow after some time.

But if that's it, it would be nice to avoid confusing a fragmented/slow disk with a network loading time when reporting such things...

And it would also be nice not to confuse generic network performance issue and the browser itself (OWB just makes HTTP connections through CURL, and the rest is up to the stack and network).


[ Edited by Fab on 2010/10/6 3:32 ]

look, I'm just reporting what's happening, as I stated I kept my mouth shut, but since the thread was opened...
as for the conf. history, it's only 6megs, hardly enough to slow loading time. As ststed I was fine with using upgrades, but was curious why dropping thwe upgrade into thr previoous vers folder behaved so differently. As for generic....How are we supposed to know it it is, or not? We just use the aps, not master in them..

Quote:

OK, good to know it's not just OWB. Still happens here though.

Quote:

Excellent, will look forward to that. Since I'm now using MorphOS as media centre (and don't want a 640x480-style screen), I find myself using this feature a lot.

Quote:

Once it has loaded for the first time in a session, there is no speed issue at all, and I did not mean to imply that there was. This is just the first time the page is loaded in a session.

Quote:

No, it's 100% reproducable. I would not waste your time with a report otherwise. Please try yourself:

Case 1:
> Restart browser.
> load www.facebook.com and leave to load in its own time
This case will probably take around 35 seconds until the page is rendered.

Case 2:
> Restart browser.
> load www.facebook.com and 'stop' the page loading almost immediately (eg after 2 seconds).
> Refresh page.
This case will probably take around 8 seconds until the page is rendered.

Seems I'm not the only one to notice this either.
I'll try to make note of other websites where this is the case, see if it points to a common cause.

Best Regards



Rich

"3. Nope. It just shows you both have some weird DNS server or network configuration."

then why is happening only with owb and not with other browsers (on morphos as well as on windows)?

@boot_wb

1. It's not supposed to be fixed in 1.9 but in next version (assuming i got it right :)).

3. First, do you refer to a logged in state or not? If it's in a logged in state, it might greatly vary depending on your "Wall" content. :)

I'll assume it was not the case, and i made the test when not connected (on 3 different MorphOS machines):
- It always takes 7-8s to load after starting browser. Stopping/Refreshing page doesn't change anything here. Of course, once it has been loaded once, refresh is much faster, since there's a page cache in OWB.

Anyway, during your 35s wait, check the connections: if they're in "connecting" mode (red led) for a very long time, it's clearly not OWB's responsability anymore. A red led means there hasn't been an answer to the HTTP request yet (because the site is still being resolved, or the TCP connection is not established yet, or that the server didn't send the HTTP response).

For fun, i tried with ibrowse, and it took 6s most of the time, except once, where it took 30s (the first connection stayed more than 20s in DNS resolution state). To be noted Ibrowse doesn't even load all the resources (like css, some pictures, ...), so it should be faster than that, compared to OWB.

So, as you can see, it's not easy to make an opinion on this, considering all the external factors (TCP stack, LAN, router, router->ISP, ...).

@xyphoid

If a fresh copy of OWB doesn't show any issue, it's clearly related to a big database overhead somewhere, and i would still bet on webpageicons.db that tend to grow quite a lot (and it's not purged, atm).

@sadddam

Fine, but it still doesn't happen here on my 3 machines, no matter how hard i try. I'll even try at work when i can, to test a different network (which will likely be faster than my home crappy access, anyway).

@fab
> i would still bet on webpageicons.db
should I delete it then it is only 5.7megs
I experience the wait(20-35+secs)but with no animation, lamp action, or processing, then once loaded boom it's all back. It may also happen if I switch tabs. I mean I can live with it though, just saying.....

If it's not a synchronous disk access, i don't know what it could be, really. So try and delete/rename these .db files and see if it changes anything.

It can't be network, because it was made asynchronous in the relevant parts (asynchronous DNS resolution and optional network thread).

Now that i think about it, it could be your fonts. Like suggested in the readme, edit conf/font.conf and remove the mossys:fonts/_ttf/ line. These fonts cause heavy substitutions in fontconfig when a glyph isn't found, and it could take several seconds in some cases, totally blocking the UI in the meanwhile.

@Fab
did both and it is very comfortable now. Loaded 14 pages in like < 2mins fully
I had the fonts, but didn't delete the line as stated.
My apologies

Quote:

Ah, that explains it

Quote:

Yes, on further observation it is a logged in state. Apologies, I should have noticed that.
(Damn, wish I'd used a different example, I now feel like I've been outed as a Facebook whore )

Quote:

Thanks for the extra info. In the case I described, there are always the same two .css connections which take around 10-15 seconds to connect (ie lamp stays red).
It happens exactly the same each time under OWB, and can be circumvented by the stop/refresh method. This (to my mind) suggested that the delay is client-side, not server-side. But as you've explained, even if it is client-side, it could be due to many factors, not necessarily OWB.

(Musing: If the delay is server-side, could it be that the stop/refresh method causes cached .css files (from a previous session) to be used rather than downloading new copies (thus bypassing the delay)? Think I'll try flushing the cache, and see if this prevents stop/refresh from speeding up the process.)

Quote:

Well many thanks for taking the time to test, I do appreciate that. It seemed such a simple (and repeatable) issue, but I see there is more complexity (even just on the client-side) which could be the cause than I first realised.

Best Regards



Rich

I guess this means I am going to have to start reading "readme" files, instead of skipping past them or skimming over them very quickly.

I never would have suspected a fonts problem.

@Fab

Quote:

Well never say never