I pulled in the changes last night. Works great. I then got side tracked investigating crashes when you try to open, close, then open a new window. It's definitely possible since I do that all the time with skia. There were some https://github.com/JetBrains/skija/issues/62#issuecomment-804621280 I found in skija, but it seems like lwgl's glfw integration also doesn't support opening multiple windows. I build everything at the repl, so that would drive me crazy. @jjttjj, Can you open multiple windows with skija on Windows? Is that something that would help your workflow?

I can open multiple windows currently on windows with skija, it works for me now with membane.skija/run (if i do it in a future). I do also hit the occasional jvm crash though when closing windows or shortly after

Ah ok. Well, hopefully those crashes will be fixed in the next release.

cool! yeah I'm used to them and they aren't a big deal 🙂 it doesn't seem to happen every time.

I was able to reliably trigger it by opening a window, closing it, and the calling (System/gc)

I think (hope) those crashes will be fixed. There may be others.

Oh interesting, I'm not on windows now but I'll test that out in a bit when I get to my main computer

No hurry. I also have a Windows Virtual Box vm that I sometimes check.

Thanks for pulling in the changes too! I know they're kinda underwhelming but i was thinking it's maybe worth getting the changes in incrementally

Thanks for the patch!

Unrelated but I've had in the back of my mind the idea of trying to implement a generic layout element thing in membrane, something like hoplon/ui https://github.com/jumblerg/ui

That would be neat. vertical-layout and horizontal-layout are very bare bones.

I used that briefly awhile ago and it was always a nice way to code up layouts to me. I'm guessing it would just involve a pane function that would generate some data bottom up and then rendered by some higher level construct (to allow children to be rendered in terms of their parent). The hard part probably is managing the state changes though, as always

It seems like the layout could be a pure function

similar to vertical-layout

Oh yeah, looking at that now and it seems like a great starting point, don't now why I didn't think of that

another option is to make it a component:

(defn do-my-layout [props drawables]
  ;; layout element with ui/translate or similar
  
  )

(defrecord MyLayout [props drawables]
  IOrigin
  (-origin [this]
    [0 0])

  IChildren
  (-children [this]
    (do-my-layout props drawables))

  IBounds
  (-bounds [this]
    (bounds (do-my-layout props drawables))))

(defn my-layout [props & drawables]
  (MyLayout. props drawables))
;; use
(my-layout {:vertical true :left 20} (ui/label "hi")})

One idea I've had, but haven't needed to implement is making standard caches available: • A per-frame cache that gets blown away after every frame • A cache that evicts data that wasn't used when drawing the previous frame

One of the main reasons I haven't is that it hasn't been necessary for the UIs I've built so far.

Thanks that code sketch is useful!

Memoizing layout functions works really well since everything is value based

What would be put in those caches? I'm not immediately seeing it

The result of do-my-layout. If the child elements are changing every frame, then memoizing doesn't help, but if the child elements usually stay the same every frame, then memoizing will save a lot of duplicate effort recalculating layouts every frame

Oh yeah, that makes sense