Yes, patience the developers will get to it when they can.
> You received this message because you are subscribed to the Google Groups "asciidoc" group.
> To post to this group, send email to asci...@googlegroups.com.
> To unsubscribe from this group, send email to asciidoc+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/asciidoc?hl=en.
I'm ambivalent about this optimization, it adds significant complexity to the
script and I'm not motivated by the gains.
I did some really rough measurements downloading and displaying the User Guide
with Firefox and Google Chrome without the patch and the total download and
display times ranged from between 1 and 2 seconds with the TOC display time
consuming less than a third of that time (much less on Chrome). Once the page is
cached there is a brief TOC pause on Firefox when you return to the page, it's
instantaneous with Chrome. It just doesn't annoy me enough to want to do
anything about it.
This could also be a problem with the CPU load if displaying on
lightweight platforms like Android devices. The result may even be
On 11/04/11 22:50, Hongli Lai wrote:
> On Apr 11, 11:06 am, Stuart Rackham<srack...@gmail.com> wrote:
>> I'm ambivalent about this optimization, it adds significant complexity to the
>> script and I'm not motivated by the gains.
> I basically just modified toc() and footnotes() to remove the old
> entries before (re-adding) the new ones, and installed a timer which
> runs until DOMloaded/window.onload.
>> I did some really rough measurements downloading and displaying the User Guide
>> with Firefox and Google Chrome without the patch and the total download and
>> display times ranged from between 1 and 2 seconds with the TOC display time
>> consuming less than a third of that time (much less on Chrome). Once the page is
>> cached there is a brief TOC pause on Firefox when you return to the page, it's
>> instantaneous with Chrome. It just doesn't annoy me enough to want to do
>> anything about it.
> It depends a little on the caching settings as well as the user's
> Internet connection. If I Shift-Refresh with Chrome, the Users Guide
> takes 5 seconds to load. The TOC isn't generated until everything is
> done loading, including images. I have a manual written in Asciidoc
> which takes a bit longer to load than that because of all the embedded
> images. But even a 1-2 seconds delay annoys me enough to write a
> patch. As a user it feels very strange to see the TOC suddenly appear;
> I want to be able to get a birds-eye overview of what's in the manual
> while it's loading.
I generated the AsciiDoc User Guide with the patch
(http://www.methods.co.nz/tmp/asciidoc2.html) and without the patch
(http://www.methods.co.nz/tmp/asciidoc.html) but I can't see any
appreciable difference between the two in loading on my Android phone (low end
LG Optimus P500) or desktop PC.
I cleared the cache first so what am I missing here?
Anyone else out there with TOC loading issues?
> At the very least I think you should take the part which uses the 'DOM
> loaded' event instead of the 'window.onload' event. That way the TOC
> can be generated before all images are done loading.
It does make sense not to wait for linked images and frames to load but I think
there are IE compatibility issues with DOMContentLoaded, see:
Thank you for the heads up, I have enabled compression.
That's really neat, I was trying to figure out how to simulate a slow
connection. I've used your slowserver to run the patch on Firefox 3.6, Chrome
10.0 and IE8 and it works a treat.
Have committed it to the trunk:
The slow server does not serve linked documents so I was not able to tell.
On 22/04/11 04:45, Hongli Lai wrote:
On 22/04/11 04:45, Hongli Lai wrote:
Tried it out and it works great!
slowserver.rb is a handy script.