It seems like OWB is having a harder time scrolling longer web pages than before (1.4). Even with relatively graphics-lite pages, when I grab the scroll bar and pull it down at a normal clip, I get some pretty heavy stuttering. It feels like the system is going to come crashing down sometimes. I don't know when this started, but I don't feel like I noticed it before.

The only things I've done recently was to upgrade to OWB 1.6 and to turn off 'enhanced displays' to stop the clicking in audio playback when changing screens. (I don't really need eye-candy.)

Has anyone noticed this?

Side note: Some web pages create there own scroll bars like the one pictured below. These don't suffer from the scolling stutter.

Travis

Hmmm... file attachments isn't working...

Well, any site that would show that? It's certainly not normal for most sites (the ones with static background or huge images can be slow, but that's it), and custom scrollers are always slower than system scrollers, so not normal there either.

First off, it seems 'favicon' loading is bogging down my system. I have two rows of quicklinks and it takes OWB easily twice as long to display the favicons as it does to load OWB itself. I can hear the hard drive chugging away as the favicons pop up. This wouldn't be a concern, but it seems the program is VERY unresponsive and nearly useless until all favicons are loaded!

Try photography-on-the.net and go to the forums. Even topics without lots of pictures causes my browser to stutter when scrolling down. It's as if it still trying to load somethings but no activity appears in the LEDs.

After much "testing" it always seems like the worst stutter is caused by some unknown background disk activity. I can hear it whirring, but no LEDs indicate downloading.

Strange.

TJH

Then your harddrive must be really very fragmented. Favicons are loaded asynchronously in a separate task, but anyway, you can disable favicons if you want.

And about that photo site, I don't encounter any particular slowness, it's smooth, even in threads with many photos. But you can always play with cache mode, in case that would make a difference for you.


[ Edited by Fab on 2010/2/26 21:15 ]

Hey, thanks for the tip about fragmentation. Even though DeFrag reported only 9% fragmentation, I did a backup and defragged the drive. All seems to be working much better than before.

Could you explain the differences among the cache methods?

Thanks,

Travis

Favicons (and history and cookies) are stored in a sqlite database. Maybe sqlite itself tends to fragment more than wanted. It would have to be checked.

About the caching modes, let's just say that it goes from the smallest size to the biggest. And if picture don't fit in cache anymore, they are redecoded when they become visible, which would explain small stutters.

@Fab

could You implement favicons cache without sqlite (for example using normal files in favicons directory)

Nope. This is generic WebKit code there, and touching it is really asking for trouble. :)