Fork me on GitHub
#membrane
<
2023-02-21
>
genekim00:02:24

@smith.adriane Quick question โ€” Iโ€™m trying to color these rooms based on their state. Is the only way to set their background color to draw a rectangle around the element, which means I need to call bounds on the room element (to get their width and height)? Thx!

phronmophobic00:02:06

๐Ÿ‘ , yep, that's right.

genekim00:02:24

Was wondering if there was something like (ui/bordered) that I can set a style to.

phronmophobic00:02:54

there's fill-bordered

phronmophobic00:02:22

oh, did you want a completely filled background or just a different outline for the border itself?

genekim00:02:39

Umm, was thinking a filled background. If fill-bordered does that, that would be awesome, because I can just wrap the existing element. (Versus putting that element in a let block, computing the bounds, and then feeding that into rectangle, if you get my driftโ€ฆ)

phronmophobic00:02:01

yea, that's what fill-bordered does.

genekim00:02:15

Sweet! Super helpful โ€” Iโ€™m so glad I asked!!! Thank you!

genekim00:02:30

Iโ€™m recording this session, too. Iโ€™m sure this saved a bunch of effort!

phronmophobic00:02:05

although, fill-bordered is just a convenience function that essentially does the following if you want to tweak it:

(defn fill-bordered-draw [this]
  (let [{:keys [color drawable]} this
        [width height] (child-bounds drawable)]
    [(filled-rectangle color
                       width height)
     drawable]))

genekim00:02:22

Nice!!!! ๐ŸŽ‰. Okay, will work on coloring based on state this evening!!

๐Ÿ’š 2
Ben Sless06:02:00

Trying to run Gene's example on my Linux machine I again stumble across the godawful slowness I encountered in the past. Only on Linux and Skia ๐Ÿ˜ฌ

phronmophobic07:02:12

I can't quite remember if we narrowed down the issue last time. > Only on Linux and Skia I don't suppose that means you tried it with the java2d backend (I don't think it will even work because the paragraph stuff). I can't remember if it was because painting was slow or because it wasn't repainting. I think it was because it wasn't repainting. Does clicking the animate button do anything? What about the keyboard commands ("j" and "k")?

Ben Sless07:02:19

Doesn't do anything and the log messages are very slow to come

Ben Sless07:02:02

I profiled it with JFR and visualvm

Ben Sless07:02:32

Saw almost all CPU on the thread was spent in the glfw paint function

Ben Sless07:02:12

And I found that default mouse move global is slightly wasteful, I can send a patch if you'd like

Ben Sless07:02:40

I'm thinking of profiling it using Jane street's magic profiler

phronmophobic07:02:05

I'm always interested in improvements. If it changes behavior, then it might take some time to review, but if the change doesn't change the output, I can probably get to it pretty quick.

phronmophobic07:02:46

Was there any particular function eating a bunch of time? maybe glfwWaitEventsTimeout?

phronmophobic07:02:18

or glfwSwapBuffers?

phronmophobic07:02:23

> Doesn't do anything and the log messages are very slow to come This is the result when you clicked the animate button? If so, that's pretty bizzare since it should be in a completely separate thread from the UI and shouldn't be block by any UI related activity. Do you get the same result if you call animate-all-frames! manually?

Ben Sless07:02:14

I can check all these slightly later, not at the computer atm

Ben Sless07:02:45

FFS this Heisenbug is killing me, I check again and now it responds

Ben Sless07:02:20

And opened a PR with the optimization I found

๐Ÿ™ 2
phronmophobic07:02:42

which distribution are you using?

Ben Sless07:02:36

PopOS 22

๐Ÿ‘ 2
phronmophobic07:02:49

I'll see if I can try it out at some point.

๐Ÿ‘ 2
Ben Sless07:02:22

I'll try to repro

phronmophobic07:02:04

I think I saw you've tried HumbleUI (which also relies on skia). I assume you haven't run into the same issue? Maybe I can try and see which things they're doing differently.