Best practice regarding different (0,0) origins
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 349
- Forks
- 33
- PR merge metrics
- No merged PRs in 30d
Description
I have a graphics lib, where the origin (0,0) is at the top/left, and rects use a top/left and width/height notation.
rbang origin (0,0) is bottom/left and uses a bottom/left, top/right notation.
So, when inserting rects from the graphics lib, I use code like this to update the same rectangle:
- r = rectangle
- xll = x lower-left
- yll = y lower-left
- xur = x upper-right
- your = y upper-right
rbang.Replace(
[2]float64{
float64(r.xll),
float64(r.yll)},
[2]float64{
float64(r.xur),
float64(r.yur)},
r,
[2]float64{
float64(r.GetLeft()),
float64(r.GetTop())},
[2]float64{
float64(r.GetLeft() + r.GetWidth()),
float64(r.GetTop() + r.GetHeight())}, r)
The problem is, that I have a very simple three rects layout (root, two childs with 50% width and 100% height of root), where a search with a point inside c2, returns the root node and c1... and not the root node and c2.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the three-rectangle layout described in the issue, using the shown Replace coordinates and a point inside c2. Then inspect the point-search and rectangle-replacement entry points to determine how the coordinate origins are interpreted. Done means the search returns the root and c2, rather than the root and c1.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- search
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100