Glew has the problem that it has to be selected at build time if GLX or
EGL is supported by the library, and this in not encoded in the library
name, nor ABI, nor anything.
Then it's easy to get into the situation that a binary is built but
cannot run because glew supports an API different from the one used by
wxWidgets, or the binary fails to link in the end after all objects are
compiled.
epoxy can support both with the same library avoiding this problem.
epoxy is not initialized explicitly, replaced initialization with
version check where one was not done already.
It seems to be available as vcpkg https://vcpkg.link/ports/libepoxy
There are problems related to GL context switching on Windows which does
not seem to be used in kicad
https://github.com/anholt/libepoxy#known-issues-when-running-on-windows
There is also a problem related to multithreaded rendering on Windows
https://github.com/anholt/libepoxy/pull/265 It's harder to tell if
threading is used for rendering but it does not look like kicad is doing
anything complex enough to warrant using multiple rendering threads.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/20630
Fixes https://gitlab.com/kicad/code/kicad/-/issues/12543
There are two netclass name methods, which previously were not
obvious in their uses. These have been renamed to now have:
GetName() : Used for internal or tooling (e.g. netlist export) usage
GetHumanReadableName() : Used for display to users (e.g. in infobars)
Fixing the previous unclear naming will result in fewer bugs
when users start using the multiple netclass functionality, as
the incorrect usage had started creeping in to new code. Also this
will help authors of new code select the correct name method.
This is the second try at 5326c36a5f. The difference here is that we
have moved GL_CONTEXT_MGR into kicommon first which will hopefully
address some of the Windows linkage issues
The GL context lock needs to be shared across kifaces. Otherwise, we
can end up blocking the lock from one kiface. Unfortunately, I can't
find the issue in GitLab right now for where the footprint viewer shows
a blank screen after opening too many contexts. But that's what this
fixes.
The GL context lock needs to be shared across kifaces. Otherwise, we
can end up blocking the lock from one kiface. Unfortunately, I can't
find the issue in GitLab right now for where the footprint viewer shows
a blank screen after opening too many contexts. But that's what this
fixes.
Recommendation is to avoid using the year nomenclature as this
information is already encoded in the git repo. Avoids needing to
repeatly update.
Also updates AUTHORS.txt from current repo with contributor names
After opening a context menu and left clicking on the 3D canvas, the view
was modified because a drag event was generated, probably a wxWidgets bug.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/17422
It was possible for OnMouseMove to come after ReloadRequest
but before DoRePaint.
Which meant m_3d_render_raytracing->Reload() has't been called yet,
thus the BVH contained invalid data.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/16059
Removes old defines and work arounds for earlier wx versions and adds a
CMake requirement to use at least 3.2 (or the minimum matching wxPython
version)
Most of these settings are now available in the appearances panel.
It was concluded in a Zulip discussion that any missing items can
be added back in time if people find they need them (ie: complain).
Also hooks up 3DViewer to the common language framework.
The spacemouse driver, particularly on Mac, is extremely unstable and
causes crashes even when not being used. This places the interface
behind an advanced config flag to ensure that users can affirmatively
opt-in to the potential for crashes
CHANGED: Instead of using the target style pivot that is used to move the
look at position, a different pivot is used for the center of rotation
used by the 3dmouse. Both pivots, the camera look at position and the
3dmouse rotation pivot, need not necessarily coincide. A blue ball is used
to represent the pivot.
inside the EDA_3D_CANVAS, it was initialized before settings are read,
and can be set to raytracing, although we always start 3D viewer in opengl mode,
thus creating a incorrect (not working) initialization.
