Geometry update during scroll

Viktor
2014-05-15
2014-05-19
  • Viktor
    Viktor
    2014-05-15

    Hi,

    Looking at host.js and its scroll handler, I gather the geometry update is made only after the scrolling has finished, as the geometry update timer is cleared when the scroll event fires. This makes it somewhat problematic to poll $sf.ext.inViewPercentage() for resolving whether an ad has been in view or not. If the user scrolls past an ad with a constant scrolling motion, the geometry information all the time claims the ad isn't in view, right?

    Triggering the geometry update each time the scroll event fires is obviously not a solution due to performance reasons, but perhaps throttling the update to be made every 100 or 200 ms during scrolling could solve this in-view information polling issue?

     
    • Sean Snider
      Sean Snider
      2014-05-19

      The throttling can't really be much faster than 500 to 750ms depending on browser due to performance concerns with both x-domain
      messaging, and with calculating the geometry.  The SafeFrames geometry calculation has dual purpose, 1.) to send you view information
      and 2.) (more important) to send you details about the available area to expand and what not.  As such we still have to do some brute
      force looping up the parent chain, in order to calculate the available area to expand, meaning that calculating geometry itself is expensive,
      so we have to be very very careful.

      In turn, while the geometry information is not true "real time", we also do send updates whenever you do a command like expand or collapse, in
      addition to the updates we trigger from the host events.  Polling will not help you at all (see below).  At start
      you'll either be in-view or not, and at somepoint later you'll get another geom-update event which will likely be close to the required 1 second
      duration.  And if the geom-update event says you've gone out of view, then you'd note that and move on.

      So for example:

      1.) Start (in-view at render)
         a.) you set timer to wait for 1 second
         b.) you are handling safe frame events/ messages
      2.) geom-update comes in (still in-view)
      3.) timer goes off, no other geom-updates received, fire your event

      Now, you're right that the user could have started scrolling or resizing just as your timer goes off, and at which point you could have gone

      out of view.  But that's likely an edge case. . .and polling the API wouldn't help you in that regard b/c we don't update the internal information
      until the host sends new data (in other words calling $sf.ext.geom over and over is not going to give you anything new unless a geom-update
      or some other event comes in).  Narrowing the throttle gap is possible, but also problematic.. . so I don't think that's the right approach given
      the limitations we have to deal with.

      The only addition I can think of would be to notify you have potential incoming changes to the host dom, sooner with a lightweight message first.
      Like when we get a resize or scroll, immediately start notifying of each SafeFrame of a potential incoming update, but don't do the geom stuff

      at that point. . .that maybe could help a bit. . .just have to see what it would do to perf.

      I should also note that this will likely change over time a bit. . . there are some optimizations we can make in the geometry stuff if we didn't have
      to support IE 8 and less.  We could fork the code more for that now, but I'd rather not do that to keep things consistent and keep the codebase
      smaller.

      Sean


      From: Viktor viktordjup@users.sf.net
      To: [safeframes:discussion] general@discussion.safeframes.p.re.sf.net
      Sent: Thursday, May 15, 2014 2:03 AM
      Subject: [safeframes:discussion] Geometry update during scroll

      Hi,
      Looking at host.js and its scroll handler, I gather the geometry update is made only after the scrolling has finished, as the geometry update timer is cleared when the scroll event fires. This makes it somewhat problematic to poll $sf.ext.inViewPercentage() for resolving whether an ad has been in view or not. If the user scrolls past an ad with a constant scrolling motion, the geometry information all the time claims the ad isn't in view, right?
      Triggering the geometry update each time the scroll event fires is obviously not a solution due to performance reasons, but perhaps throttling the update to be made every 100 or 200 ms during scrolling could solve this in-view information polling issue?


      Geometry update during scroll


      Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/safeframes/discussion/general/
      To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

       
      Attachments
  • Chris Cole
    Chris Cole
    2014-05-15

    This is a good suggestion. I'll look into what the perf impacts are as part of applying the new geometry calculation updates.

     
    • Sean Snider
      Sean Snider
      2014-05-15

      It's legacy from when we first started and getBoundingClientRect was not available for all browsers, which now is far from the case.

      That said, ideally we'd still want to look at brute force. . . to find out what's happening.  I think it's mainly a matter of scrollTop/scrollLeft
      not always getting dealt with properly.

      Sean


      From: Chris Cole goosemanjack@users.sf.net
      To: [safeframes:discussion] general@discussion.safeframes.p.re.sf.net
      Sent: Thursday, May 15, 2014 12:53 PM
      Subject: [safeframes:discussion] Geometry update during scroll

      This is a good suggestion. I'll look into what the perf impacts are as part of applying the new geometry calculation updates.


      Geometry update during scroll


      Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/safeframes/discussion/general/
      To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

       
      Attachments