drawRoundedRect and expected dimensions with strokes

[mobileben]

I'm prototyping code to draw menus. Essentially the menu is a rounded rect with stroke lines. The interior rows are the individual menu items. Menu items are based on a colored rectangle backing with icon and/or text. Each menu item as well as the menu panel can have their own colors.

This menu is generated "programmatically" based on metadata. As part fo the process, the max required width for each menu item is computed. The overall size of the menu panel is based on this.

In my tests, the menu panel and the menu items use different colors. Thus it's easy for me to see gaps.

I have noticed that my expectations of what the panel size should be doesn't match. What I'm seeing is the menu items width are "smaller" than the interior of the fill of the panel. I see this by seeing a leading and trailing gap between the menu item and the stroke lines of the rounded rect.

Code to create the panel looks like the following:

            this.panel = new PIXI.Graphics();
            this.panel.lineStyle(this.menuDef.panel.stroke.thickness, this.menuDef.panel.stroke.color.color, this.menuDef.panel.stroke.color.alpha);
            this.panel.beginFill(this.menuDef.panel.backgroundColor.color, this.menuDef.panel.backgroundColor.alpha);
            this.panel.drawRoundedRect(0, 0, details.width + this.extendedWidthCorr + this.menuDef.panel.stroke.thickness * 2, details.height + this.extendedHeightCorr, details.radius);
            this.panel.endFill();
            this.root.addChild(this.panel);

Current thickness is 4 and details.width is 190.

You can ignore the "extended*Corr" items. They are effectively 0 right now and will be used later since I plan on allowing the panel to be anchored to an edge, and in that case, I don't want to see the rounded corners along the edge. Also, ignore the inconsistency of width and height. I'm currently focusing on why the width is not proper.

Note that when I create the application I have been using a resolution of 1. I'm on a Mac, so the devicePixelRatio is actually 2. I've also as a test set this to window.devicePixelRatio and have the same results.

When I define stroke thickness, is that "pixel accurate" or or rather pixel close enough? It does not appear that is the case. The scale ratio of fill to stroke lines are different by roughly a factor of 2.

Observationally I have found that if I have the menu item width and the width used to create the panel be the same:

- If there is no lineStyle, then the width of both the panel and menu item is the same (they properly overlap which in this case means the widths are identical and overlap)

- If I use lifeStyle, the menu panel is slightly larger than the menu item. It looks like it is close to one lineStyle width (which also then seems to confirm my "roughly a factor of 2" from above). I also noticed that even though the menu items are drawn at x = 0 (anchor is upper left), when line styles are drawn, and even though the panel is also at 0, 0 ... The starting draw positions are not the same. They should be aligned properly. What I see in this case is that the menu item background is slightly smaller than the menu panel and the menu panel appears to be offset slightly in the draw, even though the x/y of the panel is 0, 0 just like the menu items (they are all children of the same container).

I was going to attach an example, but I get an error indicating can't create some directory for uploads and to contact for assistance.

[mobileben]

Okay, I think I found an answer to my own question. The trick seems to change the alignment if the lineStyle. Doing the following gives me the expected results.

            this.panel.lineStyle(this.menuDef.panel.stroke.thickness, this.menuDef.panel.stroke.color.color, this.menuDef.panel.stroke.color.alpha, 0);

 

[ivan.popelyshev]

alignment bounds were fixed some time ago , but werent published yet. Use pixijs.download/dev/pixi.js  if you want to check if bounds will change for your case.

[mobileben]

Thanks. Using 0 as the alignment value fixes my problems and I can compute proper bounds.