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

Weird Screen->Drawing coordinates mapping with shift (QT6, master) #1787

Open
sand1024 opened this issue May 17, 2024 · 3 comments
Open

Weird Screen->Drawing coordinates mapping with shift (QT6, master) #1787

sand1024 opened this issue May 17, 2024 · 3 comments
Labels
bug An error which causes unexpected or unintended results fixed A bug that has been fixed

Comments

@sand1024
Copy link
Contributor

sand1024 commented May 17, 2024

Hi!

I've just discovered strange behavior in QT6 based version (from master) for coordinates processing.

It seems (at least, as I suspect) that there is some discrepancy in mapping screen coordinates from mouse event to inner graph coordinates...

The side effect of such discrepancy - incorrect catch of entity (for example, in parallel action original line is selected only if mouse moves from one side from the line) and incorrect positioning of points as result of click (say, setting relative point, setting start point of line etc.).

I've found such effect in free mode (no specific snaps). It seems that there is some x and y shift between the point where mouse click is clicked and resulting entity...

As far as I've noticed, and that's why I suspect that something is related to coordinates mapping - the value of the shift seems to be the same (in pixels, not in drawing units) for different zoom levels.

Shift signs are +x, -y.

What is even more strange for me - it seems that coordinates widget displays correct coordinates positions on mouse move. But when click occurs (say, for setting relative zero) - relative zero point is drawn in shifted position...

I've did some quick debugging, yet not found the reason yet. Potentially, it might be due to support of event->position() and further double/int/double conversions in RS_Vector RS_GraphicView::toGraph? My (really quick) tests does not confirm that, probably the reason is in some other place.

May check this with more details later on, yet probably such or similar issue with positioning already occurred earlier?

Anyway, please check this in your environment to ensure that this is not something specific and related to my local setup.

Expected behavior

Mouse click that creates some point in drawing (like start of line, setting rel zero) in the same position as mouse click.

Observed behavior

Point is created with some shift from click point
The following video illustrates that behavior - https://youtu.be/fiBFettr5Mc

Steps to reproduce or sample file

Entity catch error

  1. Create horizontal line 0,0-0,100
  2. invoke Parallel command
  3. try to select line moving mouse from top to bottom
  4. try to select line moving mouse from bottom to top

Positioning error (not the click point and created point)

  1. Try to set relative point in some position (say, 0,0)
  2. try to set start point of line

Operating System and LibreCAD version info

Master branch
Version: LC_VERSION
Compiler: GNU GCC 13.1.0
Compiled on: May 17 2024
Qt Version: 6.7.0
Boost Version: 1.84.0
System: Windows 10 Version 22H2

@dongxuli-concord-design
Copy link
Contributor

The offset is independent of scaling, so the trouble is in mouse coordinate space

dxli added a commit that referenced this issue May 18, 2024
@dxli
Copy link
Member

dxli commented May 18, 2024

The problem is QCursor.

We use our own custom cursor images, and the hotX/Y should be at cener or the cursor image.

In Qt6, the ctor of QCursor requires hotX/Y=-1 to use the center, instead of the lower-right cornor.

Before e0c35b5, the cursor uses the lower right corner as the hotspot, leaving a mismatch from the image center. The commit changes the parameters hotX/Y to -1 to use put the hotspot on the cursor image center again.

@dxli dxli added bug An error which causes unexpected or unintended results fixed A bug that has been fixed labels May 18, 2024
@GSStnb
Copy link
Contributor

GSStnb commented Jun 12, 2024

Re: Microscopic Mouse Cursor on HiRes Display #1765

I finaly have been able to test the appImage (Version: 2.2.2_alpha1-96-ge7526bb8) and the Microscopic Mouse Cursor issue has been resolved. The mouse cursor is consistent no matter where it is within a LC window and appears to retains the system size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An error which causes unexpected or unintended results fixed A bug that has been fixed
Projects
None yet
Development

No branches or pull requests

4 participants