2011-12-12 27 views
5

Tôi biết rằng sự khác biệt hiện tại sẽ không đáng kể do bộ hẹn giờ trình duyệt không chính xác, nhưng vì mục đích của kiến ​​thức nếu không có gì khác: có trình duyệt nào hỗ trợ setInterval và setTimeout không, nhưng yêu cầu chúng phải được chuyển qua giá trị nguyên?Có an toàn khi vượt qua setInterval hoặc setTimeout một sự chậm trễ phân đoạn không?

Hoặc, rephrased với các ví dụ, là thế này:

setInterval(animate,50/3); 

như qua trình duyệt tương thích như thế này?

setInterval(animate,17); 
+0

Cách thức được xác định, đối số thứ hai là "số miligiây". Bây giờ, nếu số đó phải là tự nhiên không được xác định ... –

+0

@ ŠimeVidas Nó được xác định hoàn toàn. Xem đặc điểm kỹ thuật DOM ;-) –

Trả lời

6

Nó hoàn toàn an toàn.

(Như RobG chỉ ra, tôi đã không cung cấp một tham chiếu đến các quy tắc cầu DOM/JS bản thân và ông kêu gọi thận trọng FWIW, tôi tin rằng -. Nhưng không có tài liệu tham khảo để thuyết phục nhà nước - mà ToInteger Dưới đây là một jsfiddle cho thấy thời gian chờ được truyền như một chuỗi, một phao, và một tích phân (cùng loại như nổi trong JS) mà hoạt động tốt trong FF8 và IE9. Phản hồi chào mừng.)

là vì the DOM interface only accepts integers cho sự chậm trễ trong setTimeout/setInterval - yup, chúng được xác định trong DOM, không phải trong ECMAScript. Giá trị trễ được chuyển đổi thích hợp thành giá trị tích phân trước tiên (và trong khía cạnh này hàm [JS-internal] ToInteger được gọi thực hiện cắt ngắn *).

Tuy nhiên, những con số ví dụ sẽ thực sự mang lại kết quả hơi khác nhau (mặc dù nó có thể không được chú ý) :-)

này là vì, 50/3 (16.66andsomemore ->16) và 17định timeout khác nhau .

Mã hóa vui vẻ.


* ToInteger được định nghĩa là sign(number) * floor(abs(number)), trừ các trường hợp đặc biệt. Xem Phần 9.4 của đặc tả ECMAScript phiên bản thứ 5.

+0

Ok, vì vậy thông số này mô tả triển khai C (hoặc cái gì khác không phải là javascript), phải không? Vì vậy, sự cắt xén xảy ra bên ngoài môi trường javascript? –

+0

@ skier88 Về mặt kỹ thuật, việc triển khai DOM không * có * ở trong C - mặc dù tôi nghi ngờ nó trong hầu hết các trường hợp - nhưng nó hạn chế giá trị thành tích phân "dài". Có một phần [n không thể tiếp cận với người dùng] của công cụ JS mà biết cách "nói chuyện với DOM" mà các chuyển đổi đến/từ DOM. Liên kết được đăng chỉ bao gồm giao diện * *. Hàm 'ToInteger' là hàm nội bộ được định nghĩa trong ECMAScript, và tôi tin - nhưng tôi có thể sai - rằng điều này (hoặc tương đương) được sử dụng trong chuyển đổi tích phân. –

+0

Vâng, tôi biết ngôn ngữ có thể khác nhau, nó chỉ giúp tôi nghĩ về một ngôn ngữ lập trình ví dụ để hình dung mã mức đang được thực hiện tại.Cảm ơn bạn đã phản hồi - có lẽ tôi đã tải xuống đặc điểm kỹ thuật từ lâu rồi. –

0

Tôi sẽ tưởng tượng tham số thứ hai sẽ được đánh giá dưới dạng biểu thức và miễn là nó trả về số sẽ hoạt động. Dường như nó hoạt động trong chrome. Chỉ cần chắc chắn rằng bạn không chia cho số không!

0

Các chức năng này dự kiến ​​là mili giây. Tôi nghi ngờ bạn có thể mong đợi bất kỳ độ chính xác nào lớn hơn 10 mili giây và các trình duyệt enforce timer restrictions.

Firefox không nhớ giá trị thập phân. Bạn can test trong bất kỳ trình duyệt nào khác mà bạn tò mò.

+0

Cảm ơn bạn đã trả lời. Như trên, tôi không quan tâm đến thời gian chính xác nhiều như trôi dạt (không thể nhận thấy mặc dù nó có thể). –

3

Javascript không tạo ra sự khác biệt thực sự giữa các số dấu phẩy động và số nguyên, và là cùng một kiểu dữ liệu bên dưới mui xe. 11.0 là bit cho bit giống nhau trong bộ nhớ.

Vì vậy, có, bạn có thể chuyển một giá trị phân số mà không có bất kỳ vấn đề thực sự nào. Đó là JavaScript hoàn toàn hợp lệ. Và ngay cả khi nó đã yêu cầu một số nguyên, nó có nhiều khả năng nó sẽ đơn giản và âm thầm vòng nó xuống cho bạn.

Nhưng đừng mong đợi nó chính xác! Thời gian 0.1, 1 hoặc thậm chí 4.87 tất cả có thể sẽ cháy ở rất gần cùng một thời điểm do độ chi tiết thấp của lập lịch gọi lại.

+0

Cảm ơn, tôi đã không suy nghĩ các loại dữ liệu vì lý do nào đó. Và điểm tốt về granulatiry - IIRC, nó thực sự thường là xấu như 15ms. Mối quan tâm của tôi thực sự chỉ cho sự trôi dạt (có lẽ không thể nhận thấy) của một khoảng thời gian dài. –

+0

Sự trôi dạt là có thật và đó là một vấn đề mà tôi mới gặp phải khi sử dụng nó cho nhịp điệu âm nhạc thời gian. Và nó hút. Đây là giải pháp của tôi: http://alexwayne.tumblr.com/post/13744997785/accurateinterval Hoặc bỏ qua văn xuôi và lấy mã thô của tôi ở đây: https://gist.github.com/1d99b3cd81d610ac7351 –

+0

Thực tế là '1' và '1.0' đại diện cho cùng một giá trị Số trong ngôn ngữ JavaScript không có liên quan ở đây. Câu hỏi đặt ra là về hành vi của hàm 'setTimeout'. Lưu ý rằng hàm này không phải là một phần của ngôn ngữ JavaScript. Nó là một chức năng trình duyệt được chỉ định trong tiêu chuẩn HTML. Theo như tôi có thể biết, nếu một số không tự nhiên được cung cấp làm đối số thứ hai (như '1.23'), hành vi là không xác định, có nghĩa là các trình duyệt thực hiện hành vi cho điều này. –

Các vấn đề liên quan