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

Support multi sampled anti-aliasing with wxWidgets 3.0.3. #3343

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@bubnikv
Contributor

bubnikv commented May 27, 2016

This patch improves rendering of the 3D scenes. The improvement is significant on the 3D path simulation.

  1. Increases resolution of the depth buffer from 16 bits to 24 bits. 16 bits cause some jagged lines at the intersection of triangles. I believe the computers offering a 16 bit depth buffer only are already in the landfill.

  2. Enables multi sample anti aliasing. This is finally supported by wxWidgets 3.1 (February 29, 2016) and the OpenGL support for creation of anti aliased windows has been back ported to wxWidgets 3.0.3 (currently in beta stage). We at Prusa Research have hacked the Alien::Wx and Wx::GLCanvas to support this feature. Please accept this patch to enable anti aliasing on Prusa builds. This change shall not have any effect with the official non-hacked Alien::Wx and Wx::GLCanvas modules.

Vojtech

@lordofhyphens lordofhyphens added this to the 1.3.0 milestone May 29, 2016

Fix of git #3293: More efficient GCode export
This fixes two problems of repeatedly copying data from the C++ layer
to perl, by factoring the copying out of an inner loop.
@bubnikv

This comment has been minimized.

Contributor

bubnikv commented Jun 2, 2016

Here are the patches for Alien::Wx and Wx::GLCanvas to make MSAA working.
These two patches are required to test the feature.
Patches.zip

@lordofhyphens

This comment has been minimized.

Member

lordofhyphens commented Jun 2, 2016

You've got unrelated changes added now to the PR (the gcode export changes). -.-;

@bubnikv

This comment has been minimized.

Contributor

bubnikv commented Jun 2, 2016

You see, I am really struggling with the git.

@lordofhyphens

This comment has been minimized.

Member

lordofhyphens commented Jun 2, 2016

Some good practices for making contributions to Slic3r (IMHO, any upstream project).

  1. Each discrete change to the code starts as its own branch. So each feature is a separate branch. Only fixes for that feature go into that branch. Once you're done working on it and it's been pulled where you need it, delete it or leave it alone. Basically treat the branch like it's a set of patches with history metadata attached.
    Rationale: Branches in git are basically free and anyone working upstream want to be able pull in multiple discrete changes than one large blob of unrelated fixes.

  2. If you messed up (it happens to the best of us) and have several unrelated changes on a single branch but different commits, create a new branch pointing at before the changes were made, then git-cherry-pick the commits of interest (this is what I'll be doing with your gcode changes and probably this one too). If the commits have a lot of unrelated changes in the same commit, then best to generate patchfiles for the individual files touched for the feature you are interested in and apply them to a branch that starts before the aggregate commits happened.

The less work the project maintainers have to do to vet and merge external code, the more likely it will be that (all other things being equal) the code gets merged in.

As a quick example, see #3349 . I created a branch on my personal fork of Slic3r, lordofhyphens:feature-1333 which originated at alexrj:master. I made the changes, tested them, and then committed them to that branch. Then the pull request got made. When the PR gets merged in (I tend to not merge my own commits in, so someone else can check them as a guard against me derping), I'll delete the branch from my own repo.

I've had my own learning curve with this too with my first few PRs for Slic3r, so I am happy to try to help you too. :)

@lordofhyphens

This comment has been minimized.

Member

lordofhyphens commented Jun 3, 2016

Closing this PR because it's been separated out appropriately into two other PRs, #3355 and #3356.

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