Avoid fractional pixel offsets by forcing integer division of m_screenSize.
Shift rounded lookAtPoint onto OpenGL pixel center to ensure consistent rounding to int.
The pixel 0..1 @ 1x needs to fill the area 0..2 @ 2x so its center moves by 0.5 * (pixel size @ 1x).
The native cursor must be set on the GAL canvas wx object,
not its frame (otherwise on GTK the cursor is only set
when we get a request for it from the WM and not immediately).
Fixes https://gitlab.com/kicad/code/kicad/issues/6421
Correcting the error is more trouble than it is worth, and anyway
might not be corrected exactly the same way plotting/filling/DRC
is corrected anyway.
Use a segment count multiple of 2, because we have a control point on the
middle of the arc, and the look is better if it is on a segment junction
because there is no arc to segment approx error
The radius correction does not fix correctly approximation errors,
and creates serious issues for thin arcs:
- control point outside the arc
- HitTest active area outside the arc shown on screen
- Cairo and opengl gives different arc positions.
- the formula used in radius correction is probably incorrect.
The OpenGL missing segments (when small) are due to rounding in larger
coordinates. The GAL shader uses floats to represent int32 values for
position and distance. Thus, at larger coordinates, the smaller integer
values cannot be represented accurately. This tests for the rounding
error and, if it exists, draws a plain circle instead
Fixes https://gitlab.com/kicad/code/kicad/issues/5751
Cairo Polyline and Polygon draw functions share a common routine. While
Polygons must have 3 points to allow triangulation, a polyline (like our
text) need only have 2
This resolves a crash when passing an empty polygon and alerts debug
users to possible generation cases when bad polygons are created.
Thanks for Frans Zellman
(https://gitlab.com/kicad/code/kicad/-/merge_requests/365) for
identifying the issue.
On platforms with limited framebuffer attachments, like GC7000L
driven by the open source etnaviv driver, we can still use
GPU acceleration by drawing directly to the main buffer.
EDA_DRAW_PANEL_GAL::onPaint checks if an overlay target is
available in the GAL, and if not, redraws the whole view if the
overlay target should be dirty.
Clearing of the overlay target is a no-op if there is no overlay
buffer.
Signed-off-by: Lukas F. Hartmann <lukas@mntre.com>
When drawing segments that are smaller than the segment width, OpenGL
did not use realistic values, leading to hidden, small tracks. Instead,
we set the track to only draw a segment when the length is at least 1
radius long (so that we can see the full semi-circle at the track end)
Fixes https://gitlab.com/kicad/code/kicad/issues/5009
- New public static function OPENGL_GAL::CheckFeatures() gets called in EDA_DRAW_PANEL_GAL::SwitchBackend() before switching to OPENGL_GAL
- Moved all OpenGL feature checks from OPENGL_GAL constructor to OPENGL_GAL::init()
Fixes https://gitlab.com/kicad/code/kicad/-/issues/4714
Swap syncs can limit the redraw rate as the screen waits for previously
issued syncs. Setting this to -1 allows for adaptive swapping
(resorting to unsynced if it falls behind) if it is supported by the
card but will fall back to unsynced (0) if the adaptive is not
supported.
Fixes https://gitlab.com/kicad/code/kicad/issues/4226
The scaling factor stored inside the canvas is created by a DPI_SCALING
helper, which will call the platform-specific functions if no user scaling
is specified. This change only affects OSX and Retina displays, so this
now also allows custom scaling to be used on OSX if desired (although it
shouldn't be needed, since wx has detection for it in 3.0.4).
* Split up the thirdparty code into the thirdparty folder (#3637)
* Create a new kimath static library containing all the math functions
This is part of cleaning the build system for #1906.
This update replaces the existing uses of unique pointer creation with
the C++14 std::make_unique call that provides proper memory release in
event of an exception.
Note that since the markup might exist for other reasons, it has
to be turned on with a preference setting. (It goes through a set
of bitflags so the same architecture can be used for other markup
structures that we might want to support in the future.)
Note also that this is more about engineering nomenclature than
visual formatting. In that respect it's more similar to overbar
than italic or bold.