-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Fix opengl MULTIPLY blend mode #2601
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
Conversation
… default renderer
|
That is the correct OpenGL blending for Multiply, but only for colours with premultiplied alpha. The results with an opaque fill or opaque image will be correct, but anything less than opaque will veer towards adding brightness rather than veering towards having no effect. AFAIK there is no blend settings in OpenGL that will do Multiply correctly with non-premultiplied alpha like in Processing. |
|
@codeanticode before 2.0, weren't we using ONE_MINUS_SRC_ALPHA? |
|
@JakubValtar @codeanticode are we set on this via f43046a ? |
|
@benfry @codeanticode Yes, this is no longer relevant. |
|
That new Multiply code is still broken though, at least for non-opaque sources. Perhaps the documentation should mention that? I use the OP's suggested settings in Praxis LIVE, but that uses a subclassed PGraphicsOpenGL that uses pre-multiplied textures. That may be a drastic solution just for this issue :-) Mind you as an alternative colour option that would be great, and happy to contribute back anything useful. |
|
I feel your pain. What would you propose as a reasonable default MULTIPLY for majority of users? The new MULTIPLY just multiplies the colors and adds alphas together. We have modes which support alpha – REPLACE, BLEND, ADD, SUBTRACT. There is no compromise, the result is correct and what you would expect. Other modes like LIGHTEST, DARKEST, EXCLUSION, MULTIPLY and SCREEN ignore alpha because OpenGL can't do this. Is there a reason why MULTIPLY should have an exception and try to work with alpha even if there is no good way to do it and have reliable results for all possible colors and alphas? I think this is the most intuitive and consistent solution. (full pull request) Please also note that Processing does not claim to support pre-multiplied alpha. It would be great to have it in the future, but right now you do this at your own risk. I'm sorry if I sound angry, I had a long day and I'm just trying to explain the reason why I did new multiply this way. I understand your point and would be happy to hear your thoughts. If you need your own mode, you can use PGL, so I think advanced users can still have their cake: void draw() {
PGL pgl = beginPGL();
pgl.blendEquation(PGL.FUNC_ADD);
pgl.blendFunc(PGL.DST_COLOR, PGL.ONE_MINUS_SRC_ALPHA);
// all your drawing
rect(...);
ellipse(...);
flush();
endPGL();
}Edit: Sure, documentation needs to mention the changes. |
|
On 4 November 2014 18:25, Jakub Valtar notifications@github.com wrote:
Without major refactoring, this, as long as it's properly documented
Unless the surfaces are pre-multiplied (not sure on all). Note that
If you'd seen how much I've hacked the renderer to get it to work in
Sorry if I made you sound angry! ;-) A lot of blending issues in Best wishes, Neil Neil C Smith Praxis LIVE - open-source intermedia development - www.praxislive.org |
|
Folks, I'm gonna close this one since the original issue is sorted out. However, it sounds like it might be a good idea to file a new issue around "how might we implement premultiplied alpha" for a future release? |
|
Agreed. |
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
This changes the opengl multiply blend mode implementation so the output matches the default renderer.
Consider:
Result:

Change the size method to use P2D instead and you get:

This change makes the P2D renderer output the same as the JAVA2D renderer.