Can only scroll a scrollview when touching a surface

[gadicc]

We can probably pipe events from all descedent children, not just surfaces, for a smoother experience.

[raix]

I think it should be possible/enough to pipe from the scroll container itself

[PEM--]

Apparently, it's doable: http://codepen.io/PEM--/pen/jEOJpg?editors=001

See line 136. This could remove my trick to set background surfaces on our examples in the ScrollView.

[raix]

btw. is the scrollview in famous working stable now, no jigging?

[PEM--]

Still not what we expect out of the box. Very far, indeed. Even on iOS8 with the WkWebView. I haven't dig it enough but there is may be some hope when using different depth of field.

As far as I know, the texture size are limited. Therefore putting everything on the same surface will end up making call from the GPU to the RAM.

If you divide the main surface so that they fit in the GPU maximum size OpenGL surface, put it on different depths, that should remove the pressure on the GPU. This is why small chunks like results from a table are fast while simple surfaces filled with HTML seems to jigger.

[PEM--]

I've reworked the Pen a little bit. If you put 600 surfaces, the scroll length is over 50 pages length. As the surfaces are all mounted in the GPU with a proper modifier, they only take 2 OpenGL surfaces per famous surface (though not being WebGL, the GPU is used this way with CSS3 Transform). 50 pages is enormous. Still, as you can see it, the scrolling is perfect.

I think this all drill down to my first assumption: surfaces must be contained within the maximum size of the texture size allowed by the graphic card. Therefore, they must be tweaked so that they fit within. One way to do that could be to enclose the HTML in a SVG. The SVG is then clipped into multiple surfaces that respects a maximum size. This tricks the browser into thinking that it is bringing an image in the GPU that is smaller than the texture size.

My main concerns with this basic utilization of the device architecture is the texture loading time and the reactivity that we require for our apps in Meteor.

[gadicc]

@PEM-- , that's some very useful research. I wonder the impact their new mixed mode will have on this stuff.

Umm, I feel stupid but I couldn't see where the line numbers were :> But assuming you meant Engine.pipe scrollview. That's how we worked originally; you're right, you can scroll anywhere, but then this causes problems for multiple scrollviews on the same page, and nested scrollviews, that's why we had to change it. I guess we could set up an engine event and then compare the location to all the mapped scrollviews in the tree :>

@raix, see also some (minor) comments in mixing native scrollviews #105.

[gadicc]

And yes, reactivity is a big concern. It's up to us to keep a careful watch on this, work around problems where we can in famous-views, and give clear guidelines to developers for what to watch out for and how to work around problems. Until now I haven't run into firm examples but I'm sure this is going to be a big issue in the future.