https://linen.dev logo
Join Discord
Powered by
# ceramic
  • b
    Yes
  • o
    and logic in lots of places
  • a
    oh, haxeui components have a 
    hasEventListener
    api?
  • b
    sure, but even if they didnt you could add one fairly easy (but it does have one)
  • a
    oh yeah, it could even just use the eventmap setup
  • b
    the problem with it bubbling up is know when to stop, but i guess you cant...
  • a
    that was my initial concern
  • a
    because how am I supposed to know that I haven't gone too far in the tree
  • b
    i mean, you could have a component with a handler, then one without, the one with...
  • o
    Well I will just clarify the point I tried to explain earlier, a composite approach you have Virtual Sprite and that manages the visual structure and the events from them so there is no bubbling up or down. But i will leave it there as it may not be easy in the systems involved.
  • b
    i dont think you can, i would be tempted to say "if it doesnt have a listener" but i dont think that would be right...
  • o
    in XAML and flash you would bubbling false
  • o
    so it would go no futher up
  • b
    realistically, its probably not THAT much of an overhead, say you had a tree that was 15 components deep (which i think would be quite rare)... that means you would check 15 times on a user interaction if it needed to redispatch, which most of the time it wouldnt need to...
  • a
    the events have a pretty simple context so that isn't really possible
  • b
    im sure there is an optimization in there too, but i can think of one off hand
  • a
    that's okay, i'll see if i can get the mvp going
  • b
    this is your test case, granted, totally contrived and non-sense, in that context: http://haxeui.org/builder/?442de27d
  • a
    lol
  • b
    but you'll notice depending on which button you click you'll get different traces
  • b
    This is really a non issue, really
  • b
    Walking through parents recursively is soooo nothing compared to what Ceramic has to do at every frame to render something on screen heh 😆
  • a
    the solution mostly works
  • a
    there's a bit of a bug for some components
  • a
    but i'm sure this will be solve the issue once i figure out what is actually going wrong with the odd component
  • b
    ...unless 
    hasEventListener()
    is a very expensive and slow method? But it shouldn't right?
  • a
    it isn't
  • a
    it's mostly just a map exists check
  • b
    I see, should be fine then. Well, map access on hxcpp generates garbage, but well it's not like it will walk through hundreds of objects at every frame so it should be negligible
  • b
    (I avoid using 
    Map<K,V>
    in Ceramic internals because of that. Ceramic has its own 
    IntMap<V>
    , 
    IntIntMap
    , 
    IntBoolMap
    , 
    IntFloatMap
    implementations instead. Ended up doing this after I spent time profiling the engine with C++ target)
1...909192...124Latest