Chrome/V8 在某些元素上缓慢 onmousemove()

发布于 2024-12-11 20:19:11 字数 1069 浏览 0 评论 0原文

我正在开发一个基于 jQuery 的音乐播放器，它在主要部分中有一个很长的项目列表（无序列表，每个

中有

元素，用于有关艺术家、专辑和标题的信息）。

您可以在此处访问它的临时公共版本： http://music.sixteennet.co.uk/?anonymous

（所有歌曲都是公共版本上的无用链接，所以不要费心去玩任何东西:P)

首先，快速描述一下这个东西到底是什么：

左边是一个侧边栏，显示即将播放的歌曲列表。用户在搜索/单击艺术家后在主列表中选择歌曲（单击、Shift-单击、Ctrl-单击，您知道该怎么做），然后通过点击或拖放将它们添加到左侧的播放列表中。我已经完成了所有这些工作（这个问题与如何构建 Javascript 用户界面无关）。

问题： $(window).mousemove()、.mouseup() 和 .mousedown() 包含显示一个框的函数，框的高度以像素为单位（16 * 中所选歌曲的数量）主列表）[每个

高 16 像素]。当鼠标移动时，此框随之移动，直到鼠标位于播放列表上时，播放列表会更改颜色，并且如果用户决定 mouseup() （取消单击），则所选歌曲将添加到播放列表中。

唯一的问题是，当鼠标在当前可见的选定歌曲框上移动时，在 Google Chrome 中，该框的移动非常滞后，但只有当鼠标位于主歌曲列表上方时（但是，CPU 使用率在该框显示期间始终停留在 100%）。在Firefox 6和IE 9中，移动自始至终都很流畅，CPU使用率也不是100%（即使在Athlon 64 3500+上也是如此）。（我）在两台 PC 上重复了这个测试，一台运行 Windows 7，另一台运行 Ubuntu Linux。

我非常怀疑这是 Google Chrome 的一个错误，但如果有人有意愿查看源代码并告诉我问题是什么（如果有的话）......你对我来说就是上帝:)

编辑：我之所以说Chrome/V8是因为Safari，使用相同的渲染引擎（WebKit）没有这个问题（虽然不如Firefox/IE9/Opera那么流畅）

原文

I'm developing a music player based on jQuery, which has a long list of items in the main section (unordered list, with <div> elements in each <li>, for info about artist, album and title).

You can access a temporary public version of it here:
http://music.sixteennet.co.uk/?anonymous

(All songs are dud links on the public version, so don't bother playing anything :P)

First, a quick description of what exactly this thing is:

To the left is a sidebar, displaying the list of songs coming up. The user selects songs in the main list (click, shift-click, ctrl-click, you know the drill) after searching/clicking artists, and adds them to the playlist to the left, either by hitting or dragging and dropping. I've got all this working (this question isn't regarding how to build a Javascript user interface).

The problem: $(window).mousemove(), .mouseup() and .mousedown() contain functions to bring into view a box, with height in pixels of (16 * number of selected songs in main list) [each <li> is 16px high]. When the mouse is moved, this box moves with it, until when the mouse is over the playlist, the playlist changes colour and if the user decides to mouseup() (un-click), the selected songs are added to the playlist.

The only thing is, when the mouse is moving with the selected songs box currently visible, in Google Chrome the box's movement is incredibly laggy but only when the mouse is over the main songs list (however, CPU usage is stuck at 100% throughout the time the box is displayed). In Firefox 6 and IE 9, the movement is smooth throughout, and CPU usage is not 100% (even on an Athlon 64 3500+). This test has been repeated (by me) on two PCs, one running Windows 7 and the other running Ubuntu Linux.

I very much suspect it's a bug with Google Chrome, but if anyone has the good will to go through the source code and tell me what the problem is (if there is one)...you're God to me :)

EDIT: the reason I said Chrome/V8 is because Safari, using the same rendering engine (WebKit) does not have this issue (although it is not as smooth as Firefox/IE9/Opera)

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

少女净妖师 2024-12-18 20:19:11

我要回答我自己的问题，因为我找到了解决方案：

在盒子上运行此 jQuery 函数修复了滞后问题：

$.fn.disableSelection = function() {
  return this.each(function() {
    $(this).attr('unselectable', 'on')
    .css({
      '-moz-user-select':'none',
      '-webkit-user-select':'none',
      'user-select':'none',
      '::selection':'none',
    })
    .each(function() {
      this.onselectstart = function() { return false; };
    });
  });
};

I'm going to answer my own question, as I've found a solution:

Running this jQuery function on the box fixed the lag issue:

$.fn.disableSelection = function() {
  return this.each(function() {
    $(this).attr('unselectable', 'on')
    .css({
      '-moz-user-select':'none',
      '-webkit-user-select':'none',
      'user-select':'none',
      '::selection':'none',
    })
    .each(function() {
      this.onselectstart = function() { return false; };
    });
  });
};

回复收藏 0 原文