declarative event mapping question

[regard...@gmail.com]

I am on vacation, so sorry for the 'not-so-professional' post. Once I am back I will dig more into this and hopefully will find out what exactly is misbehaving. 

I have big time issues with touch events interfering with smooth scrolling in iOS and started digging, found out some disturbing stuff. 

For example in core-header-panel I see code like this:

<div on-scroll="{{scroll}}">...</div>

where the scroll handler is not really bound to any frame timing or throttling but instead is directly executing code and also is directly accessing scrollTop.

When we were little kids the big guys at Google used to teach us NOT to do that, but instead wait for the next animationFrame (in Polymer this translates to 'this.async(..)') and then do as little work as possible and let it go. 

Now, I start to wonder: are the guys at Google considering this to 

a) not be part of the best practices anymore (things tend to evolve and they should know how it works internally), 

b) not needed because of some magic going on with declarative event handlers that take care of this timing/frame issues or 

c) simply do not care/think that this is not important in this case...

Or is this may be simply a bug/omission?

Interesting fact - in iOS when I have core-header-panel inside core-header-panel inside core-header panel the console is flooded with mouse move events and take ~ 60 ms  which completely breaks the scrolling. Another interesting fact - if I have 10 core-header panels as siblings (actually section elements being the siblings of core-animated-pages) the scrolling is completely trashed in Safari mobile but just fine in Chrome. I know Google cares mostly about Chrome but a nice 'do not do X if you want to be running fine in other browsers' could help penetration of the project a lot.  

[Frankie Fu]

Afaik Chrome fires scroll events with raf timing so additional throttling is not needed.  And that's why you saw header-panel worked fine in Chrome.  But on other browsers we still need to throttle events to that timing.  In Polymer we care about all supporting browsers and if header-panel doesn't work well in iOS then is just a bug.

Btw, my understanding is iOS (mobile Safari) fires scroll events only after scrolling has stopped.  So code in the scroll handler shouldn't affect smooth scrolling in iOS.  You mentioned about "flooded with mouse move events and take 60ms" and that may indicate some other issues causing the scrolling to misbehave.

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/8631bdcd-ca4f-4ed3-91c8-42f44a47a05f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[regard...@gmail.com]

Thanks,

This explains maybe the smoothness in Chrome.

Indeed core-header-panel is not the problem, I have altered the component to not have bindings for scroll event but still I see a lots of scroll events from platform.js - how come? I have no listeners at all for it, why is the event even registered in JS?

Also debugging speed issues is kind of impossible IMHO for iOS because once I attach the debugger to the device it becomes 20x slower and even the digest cycle (and note that I do not have any bindings nor models) becomes ~25 ms every 125 ms... this is crazy. Basically iOS wont cooperate I am ready to give up Polymer for iOS as target.

If you guys have any pointers on what to do with this problem please share!