membrane

https://github.com/phronmophobic/membrane
euccastro 2020-11-21T08:22:29.029200Z

I don't know if you prefer this feedback elsewhere, but this snippet from the tutorial:

(let [elem (ui/on
            ;; return nil for any mouse-down event
            :mouse-down (fn [_] nil)
            (ui/button "Big Red Button"
                       (fn []
                         [[:self-destruct!]])))]
     (ui/mouse-down elem [20 20]))
>>> ()

euccastro 2020-11-21T08:23:01.029700Z

...actually evaluates to ([:self-destruct!]) , not ()

😳 1
phronmophobic 2020-11-30T20:35:59.057600Z

I've fixed this issue and it will be included in the next release. thanks again for the report!

phronmophobic 2020-11-21T08:25:02.030Z

feedback in this channel works great for me

👍 1
euccastro 2020-11-21T08:26:16.030800Z

(as a minor nitpick, the next exampe evaluates to nil, not (), but I don't suppose that matters much?)

phronmophobic 2020-11-21T08:27:29.030900Z

for how I've been using it, it hasn't mattered, but I should probably think about what the "right" answer should be.

phronmophobic 2020-11-21T08:27:48.031100Z

and the docs should at least show the correct result

phronmophobic 2020-11-21T08:39:10.031300Z

the docs should say nil rather than () now

👍 1
phronmophobic 2020-11-21T08:47:19.031600Z

I've found the root cause. There's been some on going work to 1. improve event performance 2. clarify some edge cases There's still some design work left to figure out the best option. This bug should be fixed as those changes are integrated. I've removed the example for now. Thanks for pointing it out!

👍 1
euccastro 2020-11-21T09:28:50.037200Z

a more general comment on the tutorial: it seems to assume that reagent-like atom-based reactive behavior is well-known to readers, which is perhaps fair in Clojureland. but the simple-ugly-checkbock-without-using-any-framework example made me wonder how does membrane actually perform the update. it seems to be rerunning the thunk we pass to skia/run, but how does it know when to do that? I guess on every event? so if I update the atom programmatically without having any events triggered I won't get any refresh? what gets rerendered? the whole window, I guess?

euccastro 2020-11-21T09:30:36.039200Z

I also noticed that there is some lag between the time I click and I see updates in the screen, especially the very first click

euccastro 2020-11-21T09:31:08.040Z

which makes me wonder a bit about what overhead is involved in event handling and response

euccastro 2020-11-21T09:31:25.040500Z

not to sound negative, the overall idea sounds great to me

phronmophobic 2020-11-21T09:31:51.041200Z

yes, it the window will update on every event, or every 3 seconds. generally, speaking the whole window gets updated. there are a few optimizations to reduce draws, but very few at the moment. there is a way force the window to refresh, but it's not documented at the moment

euccastro 2020-11-21T09:34:02.043300Z

another bit that is not explicitly explained is that when testing out the component definitions leading to the final example plain clojure data is used, but in the final example itself we pass an atom to the component. somehow the framework seems to handle that case especially. it would be nice if the tutorial briefly explained (not only demonstrated) the semantics of that

phronmophobic 2020-11-21T09:35:05.043400Z

I test almost exclusively on mac osx. I wonder if it's some code that's not good for linux or something else.

euccastro 2020-11-21T09:35:46.043900Z

the delay is quite hit-and-miss; it's more noticeable in some runs than in others

euccastro 2020-11-21T09:36:00.044300Z

not a big deal, I guess, since it only happens noticeably in the first click

phronmophobic 2020-11-21T09:37:10.045300Z

is the delay apparent in the example code, or are there changes where the state might not have been updated before the function returns?

phronmophobic 2020-11-21T09:40:21.047200Z

i'm currently in the process of documenting the principles that underly everything. hopefully, the documentation should improve noticeably over the next few weeks

euccastro 2020-11-21T09:40:32.047600Z

the delay is noticeable in the tutorial example code as is, but only if I cilck ~quickly after launching the window. if I wait a few seconds and then click then I notice no delay

phronmophobic 2020-11-21T09:41:05.047700Z

interesting. let me see if I can reproduce that

euccastro 2020-11-21T09:43:34.049Z

I think I'm more likely to get a small delay if I press and hold the mouse button (although the code seems to be clearly reacting to presses, not press-release sequences)

euccastro 2020-11-21T09:44:06.049500Z

but I may be just being fooled by randomness

phronmophobic 2020-11-21T09:44:34.050Z

right. most of the tutorial code just responds to mouse down events

phronmophobic 2020-11-21T09:46:47.052500Z

from a performance perspective, I've done optimizations as I run into bottlenecks and I'm currently building medium size apps that feel pretty responsive, but there's still lots of optimizations that haven't been implemented yet

euccastro 2020-11-21T09:47:45.053700Z

as a phrasing nit, I had to read this sentence a few times before I understood it: "To run a component, simply call your implementation's run function with ...". In retrospect, that clearly means the implementation I chose (e.g., skia), but initially it seemed to refer to something I wrote

euccastro 2020-11-21T09:48:16.054300Z

maybe that's just coffee not having kicked in yet 🙂

😄 1
phronmophobic 2020-11-21T09:49:29.055500Z

hmmm, a better wording might be: > To run a component, simply call the backend's (eg. skia) run function with...

👍 1
phronmophobic 2020-11-21T09:51:39.057100Z

one of the ideas that I think is interesting, but haven't had time to try is that the methods for optimizing draw calls could probably be used across skia, webgl, and even vdom backends