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

Draft SMFL-based native canvas implementation #406

Open
wants to merge 243 commits into
base: master
Choose a base branch
from
Open

Conversation

mmore500
Copy link
Member

This pull request aims to add a native backend for emp::web::Canvas so that we can draw to a canvas and save results as an image file from our natively-compiled applications. The idea is to provide two emp::web::Canvas classes (one in web/_NativeCanvas.hpp and one in web/_EmscriptenCanvas.hpp) and then use the preprocessor __EMSCRIPTEN__ to switch out which class is used. For the native implementation, we ape only the drawing and safe-to-file methods... not the full dom model or any of Canvas's "Widget"-related attributes.

Under the hood, this PR uses the "Simple and Fast Multimedia Library" https://www.sfml-dev.org/

pro:

  • cross-platform (Windows, Linux, macOS and soon Android & iOS)
  • looks like it will continue to exist well into the future: under active development (last commit yesterday https://github.com/SFML/SFML/) & 13-year development history
  • low barrier to entry: binaries available through apt and homebrew (macos) package managers, can link with just -lsfml-graphics flag
  • was recommended in the reddit posts I was trawling through 🤷

con:

  • NOT header-only

I've got some minimal working code put together (see image!), but lots left unimplemented. If we decide to move in this direction, this might make for a good undergraduate project!
out

@codecov
Copy link

codecov bot commented Dec 29, 2020

Codecov Report

Merging #406 (f8e75b6) into master (d5aac4e) will increase coverage by 0.20%.
The diff coverage is 82.84%.

❗ Current head f8e75b6 differs from pull request most recent head 72eb305. Consider uploading reports for the commit 72eb305 to get more accurate results

@@            Coverage Diff             @@
##           master     #406      +/-   ##
==========================================
+ Coverage   82.78%   82.99%   +0.20%     
==========================================
  Files         298      299       +1     
  Lines       36943    34044    -2899     
==========================================
- Hits        30584    28255    -2329     
+ Misses       6359     5789     -570     
Impacted Files Coverage Δ
include/emp/Evolve/OEE.hpp 0.00% <0.00%> (ø)
include/emp/Evolve/StateGrid.hpp 0.00% <0.00%> (ø)
include/emp/base/errors.hpp 80.00% <0.00%> (ø)
include/emp/compiler/NFA.hpp 100.00% <ø> (ø)
include/emp/compiler/RegEx.hpp 76.02% <0.00%> (ø)
include/emp/config/ConfigManager.hpp 0.00% <ø> (ø)
include/emp/config/SettingCombos.hpp 0.00% <ø> (ø)
include/emp/config/SettingConfig.hpp 0.00% <ø> (ø)
include/emp/control/ActionManager.hpp 9.09% <0.00%> (ø)
include/emp/control/SignalManager.hpp 34.48% <0.00%> (ø)
... and 163 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@mmore500
Copy link
Member Author

Right now, this PR is structured to directly emulate emp::web::Canvas but this doesn't make a whole lot of sense because it's not a web thing.

We could put it in a new namespace like emp::sfml::Canvas .

If we did that, we could potentially make a design based around a EMP_SOMETHING macro (name ideas for this?) where you would use it in your code like emp::EMP_SOMETHING::Canvas

and EMP_SOMETHING macro would resolve to web when compiling with emscripten and sfml when not

the downside being the EMP_SOMETHING macro would be kind of an ugly namespace qualifier 🤷

@mmore500
Copy link
Member Author

TODO: switch from sfml to https://github.com/a-e-k/canvas_ity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants