I took a closer look at how CN1 is handeling pointer events and I must say it is kind of a mess. Most of this is explained by the fact that the pointer events logic is directly merged into the Form, Container and Component classes (rather than having a dedicated general pointer events controller, with all the logic on a single point, wich is good coding practice and avoid logic inconsistencies that seems to occur in the current implementation, as component in the background beeing returned instead of the frontmost one when the frontmost focusable component is a container inside an other container alowing layout overlay or the getComponentAt() method beeing unecessarilly called twice, in the case of a pointerPressed call on a container...). Also, it appears that the pointer listeners of a Form would always be called in the case of a pointer event as the call of these listeners appear before dispatching the pointer event to the front most focusable component. So, in fact, in the CN1 logic, if seems that, if you have a form F containing a focusable container Cc, containing a focusable component Co, a touch on Co would first trigger a PointerPressed event on the PointerPressedLiteners of F and then a PointerPressed event on the PointerPressedLiteners of Co (and PointerPressedLiteners of Cc would never be called). And theses two events would be distinct meaning that consuming the event triggered by the Form would not affect the event triggered by the component Co.... In my point of view, this is not how pointer events should be handled and a real events bubbling approach would be preferable (or, even better, an hybrid approach). And unlike you may say, this do not specifically affect performances. After all, Android, iOS and Flutter are all examples of lightweighted frameworks implementing events bubbling (and web frameworks, that I cited as example of hybrid approaches, may be "slow", but it is unrealated to the way they handle touch events). In a correctly implemented bubbling approach, the event propagation phase is distinct from the event reaction phase (where the event would be passed to event listeners). And, by default, the event reaction phase usually stops after the first component that notifies beeing interested into this event (so events are not sent to every parent of the hierarchy, like you say, thus performances are kept intact.) BUT it can also continue to dispatch the event to the parent if the developper decided to implement a component that shouldn't block dispatching the event to its parent after reacting to it. For example, this is how it is implemented in Android: http://codetheory.in/understanding-android-input-touch-events/ This alows to easily implement some UI like blocking (where a touch the parent would have no effect) or non-blocking (where the parent would remain interactive) modals, drawers, user inactivity tracker... And no, I am not implementing a game but I am implementing some generic UI components (like a drawer (~= side-menu) that I can add to any component (not just a Form)) and the lack of possibility to dispatch pointer events to more than one layer of the components hierarchy in some cases, complicates the creation of such components when it should be (and would be with a native lightweighted framework) straightforward ...
On Saturday, September 22, 2018 at 6:18:59 AM UTC+2, Shai Almog wrote: > I was talking about events being handled at the top since they arrive from > the canvas so I'm not wrong about that as that's literally the definition > of lightweight implementation. Every implementation needs to go from root > to child to find the child. > > Sending events to every parent in the hierarchy has no valuable use case > and can impact performance on large layouts. If you want to listen to an > event or broadcast it you can do so easily. However, if we implemented > something like that people will always pay the performance penalty whether > they want to or not. > > Web isn't a lightweight framework. It's a great example of SLOW because of > various decisions e.g. automatic reflow and generic events. This makes a > lot of sense for a high level scripting language but not for performance. > > You wrote a lot but didn't mention a single programmer visible benefit for > slowing everything considerably... > > Events go to the top most focusable component. You can disable > focusability and use features such as lead component to implement typical > use cases. If you are building a game where you need to handle complex > event logic overriding the event handling at the form level makes the most > sense anyway. > -- You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discussions+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/codenameone-discussions. To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/4325f6ca-5b85-41fe-a81e-e652635b6a1e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
