Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added V-Mapper:Z for flipped orientation panels chains #1014

Merged
merged 14 commits into from
Mar 22, 2020

Conversation

marcmerlin
Copy link
Contributor

This allows using every other panel in a vertical chain, upside down
so as to be able to use the shortest HUB75 cables that come with
panels.
Instead of --led-pixel-mapper=V-Mapper use --led-pixel-mapper=V-Mapper:Z

This allows using every other panel in a vertical chain, upside down
so as to be able to use the shortest HUB75 cables that come with
panels.
Instead of --led-pixel-mapper=V-Mapper use --led-pixel-mapper=V-Mapper:Z
@marcmerlin
Copy link
Contributor Author

marcmerlin commented Mar 21, 2020

Vmapper
IMG_20200321_152815

Vmapper:Z
IMG_20200321_152804

@marcmerlin
Copy link
Contributor Author

My apologies for the git history, normally I'd blow my tree and start over fresh from yours to avoid all these merges with no file changes but CL entries, but I can't do that because I still have 2 outstanding pull requests that would get lost if I did that.

Make Henner happy :)
(also show pixel count of 2 kinds of panels)
Copy link
Owner

@hzeller hzeller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code looks like it evolved 'until wit worked' :) Could you reformulate it so that it is a bit more understandable what is happening ?

lib/pixel-mapper.cc Outdated Show resolved Hide resolved
lib/pixel-mapper.cc Outdated Show resolved Hide resolved
lib/pixel-mapper.cc Outdated Show resolved Hide resolved
@@ -250,11 +258,29 @@ class VerticalMapper : public PixelMapper {
int *matrix_x, int *matrix_y) const {
int panel_width = matrix_width / chain_;
int panel_height = matrix_height / parallel_;

*matrix_x = (x % panel_width) + int(y/panel_height)* panel_width;
*matrix_y = (y % panel_height) + int(x/panel_width) * panel_height;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be easier and more readable to figure out if we need flipping first, and then do the one or the other ?

It is very hard to follow to first do the assignment, and then additional modifications later.

So start with an expression that figures out if we should do flipping

const bool needs_flipping = z_ && y / panel_height % 2 == 0;  // or something like that.

And then either some

if (needs_flipping) {
   *matrix_ = ...
   //
} else {
  *matrix_x = (x % panel_width) +  needs_flipping ? ... : int(y/panel_height)* panel_width;
  // ...
}

or, maybe even more readable

 *matrix_x =  (x % panel_width) + needs_flipping ? ... : ...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, I'm a bit torn. I'll be honest that I had a hard time figuring out what U-mapper was doing, code that was doing smart things with virtually no comments :)
There are 2 issues maybe in conflict:

  1. efficiency
  2. readability / easy to follow the algorithm flow

For #1: I'll wager that the transform table is computed once at startup and that loosing maybe a millisecond (just made that up) to a few double assigns, is not a prime concern.

For #2:
The function does 3 things
a) normal Vmapper
b) Z Vmapper on a panel that isn't flipped
c) Z Vmapper on a panel that is flipped

I wrote the codeflow to make it very clear which one of a b or c is happening.
By the time you make single line more complex assignments that do a b and/or c at the same time, it's pretty darn hard to figure out what's going on later.

I kind of like the code the way it is because it's pretty simple to follow.
The other part that would be confusing is that x_panel_offset_cnt is computed on the transposed value of X, after it's been mapped to the virtual array (i.e. the first assignment already happened). Sure, you can do smart math that would work before the assignment, but it seemed harder to write, and as a result even harder to re-read.

Keep in mind that we're not top SWEs, so keeping it a bit easier to read, is a plus IMO.
What do you think?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, efficientcy we don't care, it only happens once.

But readability. Multiple assignments to things require you to keep track of it when reading. You do and undo things, while all we need to choose is if we need flipping or not, and formulate the expression accordingly.

What happens now is

  • do one thing.
  • oh wait, we are actually doing the other thing .. maybe.
  • we actually need to do the other thing and overwrite which we did first

This is really hard to follow.
So this is why I suggest to change this to

  • do we need to do the other thing ?
  • Yep: do other thing
  • No: do one thing.

And once you've done this, you'll notice, that the ?: version of the same is even more readable.

Copy link
Contributor Author

@marcmerlin marcmerlin Mar 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmmh, so please don't take this as me trying to argue with you :)
The way I wrote it/meant it was:
a) transform from Hmapping to Vmapping
b) if V:Z, see if the resulting panel requires inverting
c) if so, deconstruct the X coordinate to figure out if it ends up on an odd or even panel. If it's an even panel, invert X and Y

a) needs to be done regardless, it's not a) or c), nor does c) undo a)
Combining a and c in one step can be done, but it definitely felt harder to write, and likely not understandable anymore when read.
That said, keep in mind that you're talking to a programmer who isn't as smart as you are (actually I probably barely meet the definition of programmer, and it sure isn't my job description unless you compare with me with java factory factory folks :) ).

If you do see an obvious way to rewrite this in a short and yet still readable way, would you be ok merging this and modifying it the way you had in mind?
(I'll be happy to test your patch before you submit)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(and yes, calculating from the already transposed value is particularly mind-bending)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree that a) needs to be done regardless. We either do a) or we do the 'flipped a'. Right now you have to take the one a) and have to do gymnastics to then flip it.

I don't try to make it more complicated or 'smart', I actually suggest this to make it more simple that even I would understand it (right now, it twists my brain).

We can merge it and I can have a look later.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"and yes, calculating from the already transposed value is particularly mind-bending" => you'll hate me, I found it easier to vizualize after the transposition than before :)
"We can merge it and I can have a look later." =>
that would be great. I am curious to see how it can be best written.

lib/pixel-mapper.cc Outdated Show resolved Hide resolved
@marcmerlin
Copy link
Contributor Author

marcmerlin commented Mar 22, 2020

Thanks for the review. It feels like being at work :)

"The code looks like it evolved 'until wit worked' :)" => not really, I wrote it like this the first time, but maybe you mean that first the original transpose calculation happens, and then if there is a need to flip pixels, it does that afterwards.
I wrote more details in the review reply on what my thinking was with a/b/c

lib/pixel-mapper.cc Outdated Show resolved Hide resolved
examples-api-use/README.md Outdated Show resolved Hide resolved
@marcmerlin
Copy link
Contributor Author

If you prefer this picture or would like both, I can replace or put both.
Plus: no power wires, so it's easier to show the Z and the panel orienation
Minus: doesn't show how power is distributed, given that you can't use the rails.
115_20200310_FastLED_RPIRGBPanel_GFX_192x160

@hzeller
Copy link
Owner

hzeller commented Mar 22, 2020

Given that we want to illustrate the way the zig-zag wiring goes, this is a totally fine picture, no need to worry about power-connection (img/chained-64x64 doesn't have power connectors either).

Make sure to scale it down (~1024 wide ?) so that it is sufficiently small - because it will be part of the github repo that people check out on their Pi with possibly a slow connection.

If you want to see how the final rendered markdown looks like while editing it, I can recommend the grip tool.

@marcmerlin
Copy link
Contributor Author

marcmerlin commented Mar 22, 2020

Sure, done.
Actually you can see the rendered version here
https://github.com/marcmerlin/rpi-rgb-led-matrix/blob/Vmapper_Z/examples-api-use/README.md
but thanks for the grip link, didn't know about it. Normally I edit README.md files directly in the github interface which can render it online before you commit.
I also replaced the picture with one that was downsized as you requested.

@hzeller
Copy link
Owner

hzeller commented Mar 22, 2020

Cool, how can you render a markdown in github ?

@hzeller
Copy link
Owner

hzeller commented Mar 22, 2020

(edit, I mean)

@marcmerlin
Copy link
Contributor Author

  1. go to https://github.com/hzeller/rpi-rgb-led-matrix/blob/master/README.md
  2. click edit
  3. click preview changes

@hzeller hzeller merged commit 7bcd89d into hzeller:master Mar 22, 2020
@hzeller
Copy link
Owner

hzeller commented Mar 22, 2020

Thanks, merged!

@hzeller
Copy link
Owner

hzeller commented Mar 22, 2020

I've simplified the expressions to be just single assignment ( 66fc98d ). This improves readability tremendously for me as it is now clear what happens and why.

Can you verify with your panel that it indeed behaves the same ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants