Loading ...
Sorry, an error occurred while loading the content.

2407Re: [ydn-javascript] research: why YUI dragdrop is so slow

Expand Messages
  • Scott Schiller
    Jun 19, 2006
    • 0 Attachment
      This is more generic and not implementation-specific, but I think it's an interesting topic, and I'd be interested in hearing of any others' findings/experience in the area.
       
      From some of the more recent work I've done, I've seen some pretty interesting correlations between javascript animation performance (render speed / frame rate / CPU use) and graphics cards on the PC with Firefox in particular.
      IE appears to be able to take advantage of ActiveX and/or rendering hardware acceleration which results in lower CPU use and higher frame rates when doing javascript animation, even on older computers or graphics cards. In my particular cases, I'm animating multiple elements at the same time and also applying both PNG and CSS-based opacity effects.
       
      Firefox does not perform as well as IE nicely on a computer with an older or onboard graphics card (CPU use is higher / frame rate is lower,) but I've noticed it can be as fast as IE when using a newer, slightly higher-performance graphics card on machines with even slower CPUs.
       
      I'm not exactly sure how it all works, but it would make logical sense that the graphics card handles rendering and redraw of elements where possible (particularly transparency/opacity effects,) and where hardware acceleration is not possible on the graphics card itself, the work is offloaded to the CPU - presumably much less efficient - and therefore slower.
       
      From what I've seen, onboard/"integrated" graphics cards on typical desktop set-ups such as the Intel 82865G don't perform very well in this regard, so animation in Firefox is slower / requires more CPU in these cases.
       
      On my computer at work (A 2.8 GHz P4 with onboard Intel 82865G graphics), IE has no problems with JS animation for most cases; Firefox doing the same work however is noticeably slower. I have seen several 1.6 GHz laptops with nicer graphics cards, which ran the same JS effects smoothly also in Firefox despite having much slower CPUs (eg. a 1.6 GHz with non-onboard graphics runs faster than a 2.8 GHz with onboard, in Firefox.) This seems to be indicative of some video or other hardware acceleration going on.
       
      It should be noted that I can run the same effects quite smoothly on an old 866-MHz Pentium III with IE, and again Firefox is slower (also, this system has an old/integrated graphics card - I would imagine with a faster card, I would see similar performance gains.) Several years ago, my old Celeron 433 with onboard graphics would run a Javascript version of "Arkanoid" perfectly smoothly in IE, but Firefox would run slower.
       
      Unfortunately most common desktops may not have graphics cards that would enable this kind of performance gain under Firefox; at this point I'm not exactly sure what, if any, hardware feature makes this all happen.
       
      For what it's worth, I've spent a fair bit of time playing around with animation and performance experiments on previous personal projects, some more general findings are noted on my site.
       
       
      - Scott

       
      ----- Original Message ----
      From: Peter Michaux <petermichaux@...>
      To: ydn-javascript@yahoogroups.com
      Sent: Saturday, June 17, 2006 12:19:35 PM
      Subject: Re: [ydn-javascript] research: why YUI dragdrop is so slow

      Hi Scott,

      On 6/17/06, Scott Schiller <idliketowork@...> wrote:
      >
      > Regarding this demo:
      > http://peter.michaux.ca/examples/donut-dragdrop/event-test.html
      >
      > One interesting thing to note here is that if while dragging, you move your mouse around quickly enough (IE and Firefox on my machine,) the dragged element will "lag" behind the mouse cursor and therefore will not be directly underneath the cursor. At this point, a mouseover can fire on the drag target since the cursor's "view" of the elements underneath is unobstructed.

      These accidental fire's that occur when the dragged item lags behind
      is exactly how I discovered the donut idea. In my first few days with
      dragdrop I just assumed that even if the dragged item was under the
      cursor that target mouseovers would still fire.


      > Again due to "lag," it's possible that elements may fall behind the mouse cursor while moving depending on CPU load etc., effectively "blocking" mouse events if they are sitting underneath the cursor. I suspect this is something that may be difficult to minimize, but the chance of failure should be relatively low. (ie., it's possible a user might drag to a target very quickly and the "lag" works out such that the mouse was always blocked by an element while moving, thus a mouseover may not fire on the target even though the mouse may be hovering over it by the time the drag is finished.)

      Yes the donut proxy can still lag behind but when it catches up the
      hole will be under the cursor and the native browser events will fire.
      Only very small holes make this a big problem. If the user can
      tolerate a 10x10px hole things work relatively smoothly.


      > Earlier prototypes of some drag-and-drop stuff I was working on arranged items in a circle around the mouse cursor while moving, which allowed for native mouseover/out events to fire on elements as the drag was in progress. It was a bit different visually, and all dragged elements' positions were being updated individually, likely not as efficient as moving a single proxy which contained said elements, but native over/out events did fire.

      I knew this wasn't completely new:) The donut method would likely
      require JavaScript repositioning of four divs for most
      implementations. The remainder of elements inside these divs would be
      repositioned by the browser which must be faster than JavaScript doing
      the work.


      > I think this has the potential to be much more efficient than doing coordinate checks (even with caching ie., calculate and store positions/sizes onmousedown, then reference for the duration of mousemove until mouseup), given that the browser is designed to handle mouse events. Even though looping through an array of numeric values and doing <=, >= comparisons etc. for "collision detection" should be quite fast, of course "less" is always better. ;)
      >
      > Pardon the short essay. ;) For reference, I work on the new Yahoo! Photos project, and due to the nature of this project I am interested in discussing efficiency, overall performance and so on relating to drag-and-drop and other client-side, javascript-driven features.

      The boring outline donut is the simplest and fastest. I think the next
      fastest would be a single image drag. It would be very easy to
      position a single image inside the donut's four divs to make a nice
      punctured image proxy.

      Peter


      ------------------------ Yahoo! Groups Sponsor --------------------~-->
      Great things are happening at Yahoo! Groups.  See the new email design.
      http://us.click.yahoo.com/TISQkA/hOaOAA/yQLSAA/edFolB/TM
      --------------------------------------------------------------------~->


      Yahoo! Groups Links

      <*> To visit your group on the web, go to:
          http://groups.yahoo.com/group/ydn-javascript/

      <*> To unsubscribe from this group, send an email to:
          ydn-javascript-unsubscribe@yahoogroups.com

      <*> Your use of Yahoo! Groups is subject to:
          http://docs.yahoo.com/info/terms/

    • Show all 15 messages in this topic