nathansmith / adapt

Adapt.js serves CSS based on screen width.

Home Page:http://adapt.960.gs

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Question: What's the purpose of the timeout?

longlostnick opened this issue · comments

I understand the reasoning of wanting to only fire when the window is done resizing. However, it does make things really lagged out when resizing because of that. Removing or setting the timeout to something smaller drastically improves the response and "snappyness". It still only grabs the css once, and only when the resolution bounds change.

I haven't seen any negative impact so far, so I was just wondering what the reasoning behind that was and/or if I'm missing something.

Thanks!

Nick.

Nick:

Yeah, the timeout is there to keep window.resize from firing constantly. Depending on the browser, it will either fire once the mouse is lifted (Opera) or constantly, per-pixel as the window width and/or height changes.

As I recall (from reading in a few JS articles), getting too low of a timeout increment makes IE treat it as zero. As in, it sees a low timeout, and is like "Meh, that's so small, I'll just execute it now."

I'll do some research, to see what that lowest increment can be.

That makes sense. However, what's the problem with having it fire constantly? I had it down to 10ms and tested it in FF/Chrome/Safari/IE7-9 with no issue. Yea it's gonna be firing a TON of times, but it doesn't seem to slow things down. I've implemented many resizing functions in the past that don't use a timeout at all, and never had any problems. Although I haven't tested in opera much, maybe that's the clincher.

Edit: and by much, I mean never :)

The lag between this and media queries is what almost made me go with a media query grid system. Even being able to lower this part of the way would make this JS method look a lot better towards mq's. Having it at 10ms makes this thing blaze compared to media queries. No flashing, just nice crisp, smooth transitions.

If there's no other reason, i'll probably even get rid of the timeout all together in my own practice.

Nick.

Last time I tested it without setTimeout, Opera was incredibly sluggish (when dragging the window width).

There have been several Opera updates since then, so perhaps it won't be (as much of) a problem now.

But, without any setTimeout, IE continually pings for the stylesheet. Though, it does recognize it as 304 "not modified"...

http://cl.ly/0Q2J140s3w0S2A3h3u0k

Ahh, I was afraid of something like that. It still looks like it only pings during the actual transition though. It's only on the "event horizon" where I'm getting it to rage ping like that.

I'm just going off the top of my head though, you undoubtedly know the code better than I. I'll probably take a look when I get home today and tinker around.

Either way, would be cool to get those transitions faster!

Either way, would be cool to get those transitions faster!

Agreed, I'm all for speed. And perceived smoother UX. :)

Found the article I was thinking of...

http://www.nczonline.net/blog/2011/12/14/timer-resolution-in-browsers/

Looks like 15.6 is the minimum timer ("safe" for older browsers on Windows).

So, I think we could set it to 16ms in Adapt.js, and call it a day.

Sound good? :)

Even 20 if you wanted to be safe. That would be a huge improvement!

but yea feel free to close the issue. It was just initially intended as a question. Glad something became of it though! Does that mean I should submit a pull request, or are you gonna take care of it? I'm not the most familiar with how things work on other's projects around here. Either way I'd be happy to slap my name on a super tiny part of this :)

Thanks for your help!

I'll go ahead and add it shortly. I'll also supply the minified version as well.

I'll update this thread with a link to the commit once I have some spare time to make that change.

Alrighty, timer has been reduced from 100ms to 16ms.

e23b6c0