@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!
π , yep, that's right.
Was wondering if there was something like (ui/bordered) that I can set a style to.
there's fill-bordered
oh, did you want a completely filled background or just a different outline for the border itself?
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β¦)
yea, that's what fill-bordered does.
Sweet! Super helpful β Iβm so glad I asked!!! Thank you!
Iβm recording this session, too. Iβm sure this saved a bunch of effort!
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]))Nice!!!! π. Okay, will work on coloring based on state this evening!!
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 π¬
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")?
Doesn't do anything and the log messages are very slow to come
I profiled it with JFR and visualvm
Saw almost all CPU on the thread was spent in the glfw paint function
And I found that default mouse move global is slightly wasteful, I can send a patch if you'd like
I'm thinking of profiling it using Jane street's magic profiler
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.
Was there any particular function eating a bunch of time? maybe glfwWaitEventsTimeout?
or glfwSwapBuffers?
> 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?
I can check all these slightly later, not at the computer atm
FFS this Heisenbug is killing me, I check again and now it responds
dang
which distribution are you using?
I'll try to repro
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.