6e56b00b9a
This change is quite subtle. The goal is to improve responsiveness
of highlighting even further. To understand this change you need
to keep in mind that Windows and Gtk have dramatically different
behavior for paint (WM_PAINT in Windows, expose in Gtk) and
mouse move events.
In Windows, WM_PAINT and WM_MOUSEMOVE, unless sent explicitly,
are synthesized: WM_MOUSEMOVE is delivered when there are no other
messages and the current cursor position doesn't match the remembered
one, and WM_PAINT is delivered when there are no other messages,
even WM_MOUSEMOVE. This is pretty clever because it doesn't swamp
programs that are slow to process either of those events with even
more of them, ensuring they remain responsive.
In Gtk, expose events are delivered at the end of the frame whenever
there is an invalid view, and every single mouse move that happened
will result in a separate event.
If mouse move events are handled quickly, then the behavior is
identical in either case:
* process mouse move event
* perform hit testing
* invalidate view
* no more events to process!
* there are invalid views
* repaint
If, however, mouse move events are handled slower, then the behavior
diverges. With Gtk:
* process mouse move event
* perform hit testing (slow)
* while this happens, ten more mouse move events are added
* invalidate view
* end of frame!
* there are invalid views
* repaint
* process mouse move event...
As a result, the Gtk-hosted UI hopelessly lags behind user input.
This is very irritating.
With Windows:
* process mouse move event
* perform hit testing (slow)
* while this happens, mouse was moved
* invalidate view
* process mouse move event...
As a result, the Windows-hosted UI never repaints while the mouse
is moved. This is also very irritating.
Commit HEAD^ has fixed the problems with Gtk-based UI by making
hit testing so fast that mouse move events never quite overflow
the queue. There's still a barely noticeable lag but it's better.
However, the problems with Windows remained because while the queue
doesn't *overflow* with the faster hit testing code, it doesn't go
*empty* either! Thus we still don't repaint.
This commit builds on top of HEAD^ and makes it so that we don't
actually hit test anything if we haven't painted the result of
the previous hit test already. This fixes the problem on Windows
but also helps Gtk a little bit.
Curiously, the Cocoa-based UI never suffered from any of these
problems. To my understanding (it's somewhat underdocumented), it
processes mouse moves like Windows, but paints like Gtk.
|
||
|---|---|---|
| cmake | ||
| debian | ||
| exposed | ||
| extlib | ||
| include | ||
| src | ||
| tools | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .travis.yml | ||
| CMakeLists.txt | ||
| COPYING.txt | ||
| README.md | ||
| appveyor.yml | ||
| wishlist.txt | ||
README.md
SolveSpace
This repository contains the official repository of SolveSpace.
Installation
Mac OS X (>=10.6 64-bit), Debian (>=jessie) and Ubuntu (>=trusty)
Binary packages for Mac OS X and Debian derivatives are available via GitHub releases.
Other systems
See below.
Building on Linux
Building for Linux
You will need CMake, libpng, zlib, json-c, fontconfig, freetype, gtkmm 2.4, pangomm 1.4, OpenGL and OpenGL GLU. On a Debian derivative (e.g. Ubuntu) these can be installed with:
apt-get install libpng12-dev libjson-c-dev libfreetype6-dev \
libfontconfig1-dev libgtkmm-2.4-dev libpangomm-1.4-dev \
libgl-dev libglu-dev libglew-dev cmake
After that, build SolveSpace as following:
mkdir cbuild
cd cbuild
cmake ..
make
sudo make install
A fully functional port to GTK3 is available, but not recommended for use due to bugs in this toolkit.
Building for Windows
You will need CMake, a Windows cross-compiler, and Wine with binfmt support. On a Debian derivative (e.g. Ubuntu) these can be installed with:
apt-get install cmake mingw-w64 wine-binfmt
Before building, check out the submodules:
git submodule update --init
After that, build 32-bit SolveSpace as following:
mkdir cbuild
cd cbuild
cmake -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchain-mingw32.cmake ..
make solvespace
Or, build 64-bit SolveSpace as following:
mkdir cbuild
cd cbuild
cmake -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchain-mingw64.cmake ..
make solvespace
The application is built as cbuild/src/solvespace.exe.
Space Navigator support will not be available.
Building on Mac OS X
You will need XCode tools, CMake and libpng. Assuming you use homebrew, these can be installed with:
brew install cmake libpng
XCode has to be installed via AppStore; it requires a free Apple ID.
After that, build SolveSpace as following:
mkdir cbuild
cd cbuild
cmake ..
make
The app bundle is built in cbuild/src/solvespace.app.
Building on Windows
You will need cmake and Visual C++.
GUI build
Check out the git submodules. Create a directory build in
the source tree and point cmake-gui to the source tree and that directory.
Press "Configure" and "Generate", then open build\solvespace.sln with
Visual C++ and build it.
Command-line build
First, ensure that git and cl (the Visual C++ compiler driver) are in your
%PATH%; the latter is usually done by invoking vcvarsall.bat from your
Visual Studio install. Then, run the following in cmd or PowerShell:
git submodule update --init
mkdir build
cd build
cmake .. -G "NMake Makefiles"
nmake
MSVC build
It is also possible to build SolveSpace using MinGW, though Space Navigator support will be disabled.
First, ensure that git and gcc are in your $PATH. Then, run the following
in bash:
git submodule update --init
mkdir build
cd build
cmake ..
make
License
SolveSpace is distributed under the terms of the GPL3 license.