 |
Author |
Topic: blend() ignores transforms (Read 475 times) |
|
Maarten
|
blend() ignores transforms
« on: Jan 6th, 2005, 9:45pm » |
|
I noticed that the blend() function seems to ignore the current coordinate transform. In the sample below, the rect drawn with image() rotates correctly, while the one drawn with blend() does not. (Same problem with translation etc.)
Processing v0068, WinXP RC2, Java2RE SE 1.4.1_03
I'm getting other unexpected effects from blend() as well and see a lot of posts from people writing their own alphaImage classes; is that the way to go for blending effects for now?
thanks!
/Maarten.
Code:
void setup() {
color bgcol = color(0, 0, 0, 0); // black transparent
color fgcol = color(0, 0, 255, 255); // blue opaque
size(100, 100);
background(bgcol);
stroke(fgcol);
noFill();
rect(20, 20, width-40, height-40);
BImage cp = copy(); // copy screen into bitmap
background(0);
// rotate around the center of the screen
translate(width/2.0, height/2.0);
rotateZ(PI/6.0);
translate(-width/2.0, -height/2.0);
image(cp, 0, 0);
blend(cp, 0, 0, width, height, 0, 0, width, height, ADD);
}
|
|
|
|
|
|
|
fry
|
Re: blend() ignores transforms
« Reply #1 on: Jan 7th, 2005, 12:26am » |
|
not a bug, actually (moving out of the bugs section).. blend() acts on image data, it's not a drawing function like image().
put another way, blend() is from PImage, and the entire processing canvas is itself a "subclass" of PImage, so it's just doing compositing.
|
|
|
|
|
Maarten
|
Re: blend() ignores transforms
« Reply #2 on: Jan 7th, 2005, 1:14am » |
|
Ah, thanks for the clarification. Since both are effectively blt operations, I didn't anticipate that the implementation is completely different. That's certainly not obvious from a language user perspective--externally it looks like both operate on BImages.
I think it'd be great to have the behavior uniform. Maybe we should move this to a feature requests thread instead? 
|
|
|
|
|
fry
|
Re: blend() ignores transforms
« Reply #3 on: Jan 7th, 2005, 4:44am » |
|
yeah, we'll be adding actual blend modes sometime post-1.0, which would act the way you want.. i.e. this would affect any compositing that follows a call to blendMode(ADD) or whatever.
|
|
|
|
|
|
