Unfork?

[alexeden]

Hey @wesleytabaka. I've finally gotten around to working on my rpi-led-matrix library.

I stumbled onto your fork and see a lot of really neat functionality you added for drawing filled shapes and polygons, and I plan on bringing this into the library.

In the interest of not creating API bloat (i.e. with the added drawfilled* functions), I wanna rework the API entirely to more smoothly accommodate the new functionality and vump to 2.0.

I started this branch to track the work. My approach right now (I only started messing with it a few hours ago) is to give the draw* functions a relatively consistent options object argument for customizing and overriding draw/shape behavior.

I've got a POC going with the unstable_draw_circle here as an example (native impl). I appreciate any input on this approach and any contributions you wanna make. Thanks!

[wesleytabaka]

Hi @alexeden !

Thanks! And thanks for your awesome work on the original library. That's fine by me.

I agree with the design of ShapeOptions as of 8a05d05 Implementing strokeWidth might be a bit tricky/time consuming. I'd probably skip this for now. I guess to accomplish this one could think of a Shape that is filled, and then a scaled down version of the same shape with transparent fill that overrides the opaque fill in the layer below it. Or somehow check the distance from any of the edges in the case of a rectangle or polygon.

Sure, I'd love to contribute to this! I think I understand where the design is headed. Let me know what you'd like me to work on and I can submit a PR on the next-api branch.

[alexeden]

You turned out to be absolutely right about everything re: stroke colors and weights. I had to learn the hard way that it is extremely not easy. So... I'm nixing that idea and just making fill a binary option. Especially because if someone really needs a shape to have a stroke of a different color, they can just draw it with a fill and then draw it again without a fill but in a different color.

As for polygon filling, I thought it'd be fun to try to implement a scanline fill algorithm to do the job. It was not fun; I forgot how much I dislike/am bad at programming in C++. I gave up and copied your stuff over. It seems to work after a couple basic tests.. do you recall whether or not you finished ironing it out? I ask because I saw a few lines that had been commented out. If so I'm gonna run with it and get back to the actual API bindings. 😄

[wesleytabaka]

Hi @alexeden , True, worse comes to worse the user could layer different shapes.

Yep, the "ray casting" or scanline algorithm sounds simple enough but there's a lot of special conditions like if the point you are working on is a vertex, it may or may not count depending on whether the two lines are on opposite sides of the line being scanned. That's why my code has all those lovely if statements and creating imaginary lines just above the line we're scanning to figure out if a line boundary should be counted or not, or if the slope of the line is 0 or undefined. There'll definitely be a more efficient way of doing this compared to what I farted out in a couple of weeks. 😋 I'd be curious to see if there are any non-crossing shapes where my algorithm breaks.

https://www.cairographics.org/cairomm/ https://www.cairographics.org/manual/cairo-cairo-t.html#cairo-set-fill-rule cairomm looks like it might be useful for just such a use case. But I know even less about C++. If I were to do it all over again, I'd do a POC with cairomm and try to get that library working. It looks like cairomm can define polygons and it will attempt to fill them for you. And it probably does it in a more clever, efficient way. It looks like it has a few different algorithms you can pick from.

As for the draw_filled_polygon method, just lines https://github.com/wesleytabaka/rpi-led-matrix/blob/e4448f67fbdc9bb441e53757a6ad93915c1650a9/src/led-matrix.addon.cc#L438-L439 aren't strictly necessary. They're remnants of my comment-hoarding problem.

Also, there's a private method https://github.com/wesleytabaka/rpi-led-matrix/blob/e4448f67fbdc9bb441e53757a6ad93915c1650a9/src/led-matrix.addon.cc#L322-L324 This is used in the imaginary line calculation to compare two doubles to figure out what lines a point might exist on as we scan an imaginary scanline. This method should come over as well.

[samturner3]

Hey just wondering on progress to un-fork? Has the filled shapes functionality been resolved in alexeden/rpi-led-matrix?

Curentlly my project dependency tree is like: hzeller/rpi-rgb-led-matrix -> alexeden/rpi-led-matrix -> (forked) wesleytabaka/rpi-led-matrix -> wesleytabaka/rpi-led-matrix-painter -> samturner3/rpi-led-matrix-painter-mqtt

[wesleytabaka]

Hi @samturner3 ,

As far as I'm aware this hasn't been merged into @alexeden 's master branch. I could totally be wrong -- I'm afraid I haven't tested the latest version of @alexeden 's repo.

I made my additions for drawing polygons and the ray tracing (filled shapes) algorithm in my fork of the the C++ addons from @alexeden 's repo thinking that's probably where they belonged, rather than my wesleytabaka/rpi-led-matrix-painter repo, which just enables the whole declarative model concept.

I'm planning to focus on the bug you identified in https://github.com/wesleytabaka/rpi-led-matrix-painter/issues/14 first. Then I can give @alexeden 's latest code a go.

Thanks!