Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal] A “expression-binding” api to avoid gesture move js-native bridge cost #1730

Closed
wintercn opened this issue Nov 25, 2016 · 8 comments

Comments

@wintercn
Copy link

wintercn commented Nov 25, 2016

Everyone knows when response to a gesture event like pan, there is three steps:

start ==> move ==> end(cancel)

For "start", "end" and "cancel" event, it's OK to raise the event to JS. But for move event, it's triggering too rapidly and there is not enough time for calling js-native bridge. At this state, it's really hard to implement fancy effect related to gesture with weex

To resolve this issue, I'm thinking of a “expression-binding” system, described as following:

  • When gesture start, (js code) create a "expression-binding" between a property and the gesture.
  • During the gesture moving process, native code automatically execute the expression with argument from gesture and set it to the binding property.
  • When gesture is end or canceled, destroy the binding.

The code might like the following

element.onPanGestureStart = function(event){
    event.createBinding(element, "transform.translate", "{x: x, y: y+10 }")
    event.createBinding(element, "opacity", " (abs(x) + abs(y)) / 100 ")
}

Now, the most necessary gesture is pan and two-finger touching.

Available variables in expression:

pan
    x : the displacement x from original point
    y : the displacement y from original point
    translate:  the translate of the point
two-finger
    x : the displacement x from original point
    y : the displacement y from original point
    translate: the translate of the two points' middle point
    rotate : the rotation from original line(in rad)
    scale : the scaling rate from original line
    transform: the combined transform of the two finger points

Available tool-functions in expression:

    abs
    acos
    asin
    atan
    atan2
    ceil
    cbrt
    cos
    exp
    floor
    log
    max
    min
    pow
    round
    sign
    sin
    sqrt
    tan

Available consts in expression:

    E
    LN10
    LN2
    PI

Available operators in expression:

  ( … )
  ! …
  ~ …
  + …
  - …
  … * …
  … / …
  … % …
  … + …
  … - …
  … << …
  … >> …
  … >>> …
  … < …
  … <= …
  … > …
  … >= …
  … == …
  … != …
  … === …
  … !== …
  … & …
  … ^ …
  … | …
  … && …
  … || …
  … ? … : …

Interface design:

event
    createBinding
        parameters:
             @element : the element to bind to the event
             @propertyPath: the property path of the element
             @expression: the property value expression
             @rangeCheckExpression[opt]: A expression to check if the bind will be execute, returns true of false
        return value
             undefined
@HiZhaoxiaoyang
Copy link

I do remember when a pen drawing on a canvas , the basic principle is logging what coordinates the pen reached. here's we need an array to log it, Queue, FIFO. .. tbc

@Hanks10100
Copy link
Member

Great! contribution welcome. 😃

@Jinjiang
Copy link
Contributor

Jinjiang commented Nov 29, 2016

It's absolutely useful to do better perf for gesture events model. My concern is whether it's enough for some extreme cases or boundary conditions? For example an element should be stoped when people move it out of the screen by an "expression-binding". It's common and how to finish it with our current design?
Thanks.

@wintercn wintercn changed the title Proposal: A “expression-binding” api to avoid gesture move js-native bridge cost [Proposal] A “expression-binding” api to avoid gesture move js-native bridge cost Nov 30, 2016
@YorkShen
Copy link
Contributor

I think this proposal can solve some problems related to js-native bridge communication.

  • Boht js->native and native-> js communication will cause precision lost as <meta name="viewport" content="750, initial-scale=1"> is set by default.

  • As sampling problem in pan gesture, there will also be precision lost.

  • js->dom->ui and ui->js threads communication may delay the UI response to user's action

@MrZstOnly
Copy link

How to use it?Have some exmple code?I can't use it in weex version 2.0.

@YorkShen
Copy link
Contributor

This PR/issue doesn't receive response since Weex migrated to Apache two years ago and this repository is no longer active yet.

Feel free to ask question in new repository and thanks for your contribution.

@Hanks10100
Copy link
Member

This issue is outdated for a long time and will be closed now. You can create a new one if you still have questions.

1 similar comment
@Hanks10100
Copy link
Member

This issue is outdated for a long time and will be closed now. You can create a new one if you still have questions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants