the main issue that it tries to address is that on really really slow
networks, the user goes to a site and takes a long time to load, and
they think the browser has stopped working or is not doing anything
and give up and cancel the load.
By showing some content, some progress, the user can see that there is
activity and will continue to wait for the page to load.
Again, this is for slow network connections (ie low bandwidth)
Davidc
On Feb 13, 2008, at 8:18 AM, Alp Toker wrote:
zaheer ahmad wrote:
hi,
can somebody suggest websites where we can see a considerable
difference using LOW_BANDWIDTH_DISPLAY or the FOUC problem. i
dont seem to see the difference with most links i have tried.
The WebKit FOUC with LOW_BANDWIDTH_DISPLAY is quite distracting to
me both on the desktop and on mobile devices, so much so that I
don't think it's even worth supporting as an official configure flag
right now.
If you didn't notice it, the only possibility I can think of is that
you passed the wrong CPPFLAGS. It needs to be precisely:
-DWTF_USE_LOW_BANDWIDTH_DISPLAY=1
So, if you are using the configure script and compiling for the
Maemo mobile platform:
CPPFLAGS="-DMOBILE=1 -DWTF_USE_LOW_BANDWIDTH_DISPLAY=1" ./configure
--prefix=/opt/webkit --enable-video --disable-xslt --with-hildon
I actually think a throbber or other load notification system is
much more effective. When users see unstyled content (HTML without
CSS), they immediately consider it a bug in the browser. Not good.
So in summary, -DMOBILE=1 is good, -DWTF_USE_LOW_BANDWIDTH_DISPLAY=1
is not so good. The loader in current builds is significantly faster
and better at scheduling than those in other mobile browsers so I
don't think we need hacks like this. Try it out and see what you
think :-)
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
