Severe Ruby rendering issue

[tulamide]

This is not related to the newest version, so I post it here. The issue is hard to describe and difficult to present in a schematic. Instead I made a graphic to make it more obvious.

Here's the scenario: You want to compose a grid out of rectangles. In the graphic below the chess-board-pattern represents the pixels of an area, the red lines are the rectangles, white is an area outside a view's area
The rectangles are supposed to have a width and height of 4. So, when drawing from pixel 1, they cover pixels 1, 2, 3 and 4. Or, when starting at 0, they cover 0, 1, 2 and 3. If you now draw the rectangles in a loop, stepping plus 4 pixels, you get the second graphic as a result. If you do the same thing in Ruby instead of your painting app, you get the third graphic as result. You can clearly see that the dimensions are misinterpreted. A width of 4 results in a width of 5. 1 pixel off, exactly, each time, no matter how you draw. Of course, I did set smoothing off and tried with both, normal and inset alignment. Every time the same issue.

The last two graphics show why this is so severe. You have a view area of exactly 8 pixels. The graphic to the left shows how it should look like, the one to the right shows what Flowstone produces. You can clearly see, how it is drawing outside the view area. You don't see this from the view. But you see it immediatly when using that view in another view that's larger. All of a sudden the lines to the right and bottom are drawn! Even worse, this behavior also extends the area for generated redraw orders. I placed two views adjacent. That means, whatever one does can't influence the other. And indeed it behaves so normally.

But when Flowstone extends the area unwillingly it is continously influenced by the other view, leading to continous redraws. From my tests I had thousands of redraws in just seconds, and the redrawing only ends if the other view is moved by one pixel (ctrl+arrow).

This all is giving me headaches and also is the reason for the delay in updates for the sprite font engine.

issue.png (11.32 KiB) Viewed 15910 times

[MyCo]

Hm... I've tried it, but can't see the problem that you described. Ruby and Non-Ruby version overlay perfectly.

[tulamide]

Hm... I've tried it, but can't see the problem that you described. Ruby and Non-Ruby version overlay perfectly.

Well, it wasn't about Ruby and green not overlaying perfectly. In fact I never tested green at all. It is about Ruby misinterpreting width and height when drawing rectangles. It is interesting that you found settings where the issue doesn't occur. This leads me to think that there's some rounding issue going on.

I changed your test schematic to reflect what I am talking about. Look at the grid itself and have a look inside the module. Compare it with my description and graphics. Hope the schematic helps more than my description

[MyCo]

I guess you misunderstood how the pixels are selected.

Here's a drawing:

Pixels.jpg (33.01 KiB) Viewed 15882 times

As you can see, when you say width=2, it starts in the middle of one pixel and counts to the middle of the next pixel = 1 and then to next pixel = 2, effectivly it draws 3 pixels although you just said you wanted a width of 2. The next rectangle has to start at offset 3 to not overlap, and the offset is also the midpoint of the pixel.

This wasn't the case in SynthMaker when I remember, it was changed in FlowStone, so when you use the 1/8 grid system you always draw a single pixel instead of drawing between two pixels (GDI+ allows subpixel drawing).

[tulamide]

I guess you misunderstood how the pixels are selected.

Here's a drawing:

Pixels.jpg

As you can see, when you say width=2, it starts in the middle of one pixel and counts to the middle of the next pixel = 1 and then to next pixel = 2, effectivly it draws 3 pixels although you just said you wanted a width of 2. The next rectangle has to start at offset 3 to not overlap, and the offset is also the midpoint of the pixel.

This wasn't the case in SynthMaker when I remember, it was changed in FlowStone, so when you use the 1/8 grid system you always draw a single pixel instead of drawing between two pixels (GDI+ allows subpixel drawing).

If what you say is really true, then (and please don't think I'd address this to you) this is the dumbiest I've ever heard of. A 3 pixel consuming area is said to have a width of 2? Really? Like, I want two apples and get one for free?

In each and every application of all times, a pixel width of 2 meant 2 pixels. I develop for almost 30 years now, in dozens of programming and script languages. Never ever had one tried to tell me that 3 pixels is really 2 pixels. Really, I can't imagine anything sillier than breaking mathematic rules.

So I have to add one to get the real result. I hope this is it. It doesn't address the overlapping issue, but let's put that aside. Need a coffee now. Two coffees. Or better three. So, in the end Big Brother was right: 2 + 2 indeed equals 5!

(Lost a week just because of ignored maths. At least there are people like you, who can point us to the issue. Thank you!)

[RJHollins]

... so when you use the 1/8 grid system you always draw a single pixel instead of drawing between two pixels (GDI+ allows subpixel drawing).

Question .... so did the 'grid' system change with FlowStone.

2nd question [please] ... is the 'grid user defined ?

I'm just a bit confused by this ... but maybe this was the hidden reason I had issue with a project ... I ended up doing, what I thought, a workaround ... but maybe that WAS the way it works

Thanks for any additional info MyCo

[MyCo]

Question .... so did the 'grid' system change with FlowStone.

Don't think so

2nd question [please] ... is the 'grid user defined ?

Yeah, you can change it in the schematic option dialog... called "Zoom Level". Wouldn't suggest it though...

BTW: This is how rectangle are drawn: You have a rectangle of say: 10x10 Pixel at 10x10 Pixel offset, and draw with a 1 Pixel Pen exactly on the edge of the rectangle around it. When you measure now what you've drawn you get:

Offset: 9.5 x 9.5
Size: 11 x 11

For Pens bigger than 1 Pixel, you can use Pen.setAlignment("inset") to correct for that.

Update: Just checked it, was in SynthMaker exactly the same.

[RJHollins]

Thanks MyCo ... appreciate the aditional info to help me better understand.