Fork me on GitHub
#membrane
<
2020-11-21
>
euccastro08:11:29

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]))
>>> ()

phronmophobic08:11:02

feedback in this channel works great for me

👍 3
euccastro08:11:01

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

😳 3
phronmophobic08:11:19

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!

👍 3
phronmophobic20:11:59

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

euccastro08:11:16

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

phronmophobic08:11:29

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

phronmophobic08:11:48

and the docs should at least show the correct result

phronmophobic08:11:10

the docs should say nil rather than () now

👍 3
euccastro09:11:50

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?

euccastro09:11:36

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

phronmophobic09:11:56

I'm pretty surprised by that. especially for small examples

phronmophobic09:11:05

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

euccastro09:11:08

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

euccastro09:11:25

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

phronmophobic09:11:05

this is feedback is really helpful. one of the challenges of this project is that it has a pretty large surface area. to make a ui, you need graphics, state management, and supporting documentation. there's quite a few areas where it's still running on the "simplest implementation possible"

phronmophobic09:11:51

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

euccastro09:11:02

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

phronmophobic09:11:21

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

euccastro09:11:46

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

euccastro09:11:00

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

phronmophobic09:11:10

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

phronmophobic09:11:05

this is feedback is really helpful. one of the challenges of this project is that it has a pretty large surface area. to make a ui, you need graphics, state management, and supporting documentation. there's quite a few areas where it's still running on the "simplest implementation possible"

euccastro09:11:32

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

phronmophobic09:11:05

interesting. let me see if I can reproduce that

euccastro09:11:34

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)

euccastro09:11:06

but I may be just being fooled by randomness

phronmophobic09:11:34

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

phronmophobic09:11:47

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

euccastro09:11:45

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

euccastro09:11:16

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

😄 3
phronmophobic09:11:29

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

👍 3
phronmophobic09:11:39

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