Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

long scrolling can produce thousands of requests #38

Closed
bricestacey opened this issue Jun 6, 2011 · 7 comments
Closed

long scrolling can produce thousands of requests #38

bricestacey opened this issue Jun 6, 2011 · 7 comments

Comments

@bricestacey
Copy link

Perhaps this is not an issue (I am not sure if this is normal for such an application), but...

If you perform a relatively long scroll (e.g. holding down page-down or dragging a long distance) you can generate a rather large number of unnecessary requests. For example:

  1. If I scroll from page 500 to 583 by holding page-down, I generate 969 requests - though I never actually see any pages except the last.
  2. If I start from the beginning and drag the scrollbar to page 411 (with pretty good accuracy), I generate 871 requests.

I am running Google Chrome on Windows XP on relatively new hardware on a relative fast internet connection and it performed relatively well, but it may be problematic for others to have hundreds (sometimes thousands) of requests in a matter of a couple seconds.

A possible fix would be to not make the AJAX call immediately, but instead set a timer which will check to see if the page is still in the view and only then make the AJAX call. The actual interval can be relatively small and remain unnoticeable by the user (think 1 / # of page downs per millisecond). In fact, it may speed up performance as the user wouldn't have to handle hundreds simultaneous connections.

@ghost ghost assigned dellsystem Jun 6, 2011
@dellsystem
Copy link
Member

By requests, do you mean AJAX requests? Because simply scrolling through the document should not trigger any AJAX requests. New requests should only be made when changing zoom level, or when entering/leaving fullscreen mode; although scrolling can be a bit slow (which is something we're working on), it isn't supposed to result in any more requests. What are you using to determine the number of requests being made?

Thanks for reporting this by the way.

@bricestacey
Copy link
Author

Yes, AJAX requests when scrolling. I'm using the developer tools in
Chrome, the network tab to see them. So if I scroll to page 100 it'll
actually load most everything from 1-100 even if I'm on those pages
for milliseconds.

Maybe I can do a quick screencast of the behavior tomorrow.

Brice

Sent from my iPhone

On Jun 6, 2011, at 3:45 PM, dellsystem
[email protected]
wrote:

By requests, do you mean AJAX requests? Because simply scrolling through the document should not trigger any AJAX requests. New requests should only be made when changing zoom level, or when entering/leaving fullscreen mode; although scrolling can be a bit slow (which is something we're working on), it isn't supposed to result in any more requests. What are you using to determine the number of requests being made?

Reply to this email directly or view it on GitHub:
#38 (comment)

@dellsystem
Copy link
Member

If you have time to do a screencast that would be great, as additional AJAX requests being fired off while scrolling is not expected behaviour.

@ahankinson
Copy link
Member

Just to clarify: I don't think it's the AJAX requests to the divaserve.php script; I think it's requests sent for intermediate tiles to the tile server. As you scroll past a page, it will queue up the image tile requests to the image server. It "looks" like AJAX because of the tile loading mechanism where we dynamically load divs into the DOM, but it's really just image requests.

Nevertheless, I think @bricestacey is right to point out that these requests will pile up and overload the browser with hundreds of requests. We solved this in the earlier version by instituting a very basic timer for determining when the user has "paused" scrolling in order to then trigger the tile loading. There may be a more elegant solution to this.

@bricestacey
Copy link
Author

Actually, you are correct. It's not actually ajax, but the image tiles.

I'm going to skip on the screencast now that I think the issue is clear.

Brice

Sent from my iPhone

On Jun 8, 2011, at 1:25 AM, ahankinson
[email protected]
wrote:

Just to clarify: I don't think it's the AJAX requests to the divaserve.php script; I think it's requests sent for intermediate tiles to the tile server. As you scroll past a page, it will queue up the image tile requests to the image server. It "looks" like AJAX because of the tile loading mechanism where we dynamically load divs into the DOM, but it's really just image requests.

Nevertheless, I think @bricestacey is right to point out that these requests will pile up and overload the browser with hundreds of requests. We solved this in the earlier version by instituting a very basic timer for determining when the user has "paused" scrolling in order to then trigger the tile loading. There may be a more elegant solution to this.

Reply to this email directly or view it on GitHub:
#38 (comment)

@dellsystem
Copy link
Member

Ah, that's what I thought. This is a known issue, thanks for reporting it though @bricestacey. I had an issue for this open (#6) but closed it because scrolling directly to a page seemed to be okay; however, you're right in that trying to quickly scroll through the document will result in more images being loaded than is necessary. A timer would be a good idea, although I'm not sure about the logistics of getting it working in conjunction with the virtual rendering method to load the tiles. I'll keep this issue open until we find a way to deal with it.

@ahankinson
Copy link
Member

I just tried this on the latest version and we're still generating a ton of requests.

One way we might tackle this is to add an "didStopScrolling" event that fires off after the user has stopped scrolling. This event would then call the page load mechanism.

I'm not sure how that fits, but it might be something to look into.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants