2 ms·
You can write code both ways but it's much easier to ensure every destination pixel is handled exactly once when you interate over the destination pixels, than
by ajuc 7y ago
You can write code both ways but it's much easier to ensure every destination pixel is handled exactly once when you interate over the destination pixels, than if you do it iterating over the source pixels. It becomes especially visible when you add perspective distortion and other complications.
Which is why every graphic api out there does it pull-style.
- heavenlyblue 7y agoDrawing triangles on a screen is a push-style operation, isn’t it?
- ajuc 7y agoYes, from the POV of lists of polygons. But from the point view of textures it is pull (you go through destination pixels and fill them with source pixels fetched through transformation).
- heavenlyblue 7y agoIn the same way you could apply the reverse transform to the polygon and get the coordinates of display pixels in texture coordinates and then do a push from there. They are equivalent, as I am trying to say. The only difference is semantics or whatever makes it easier to think about.
- ajuc 7y agoYou would have to skip variable number of pixels in source texture according to the transformation, then calculate the reverse transformation to know where to push. Notice how you not only change x * 4 into x/4, you also change x++ into x+=4 for (int x=0; x<width; x++) for (int y=0; y<height; y++) destination[x][y] = source[x*4][y*4]; vs for (int x=0; x<width; x+=4) for (int y=0; y<height; y+=4) destination[x/4][y/4] = source[x][y]; If it's as simple as scaling: x+=4 isn't much harder than x++. But for complex transformations calculation of how many pixels to skip in any particular row will be slow and complicated. Meanwhile when doing pull you don't need to do it. This is the reason every graphical API i know of does these tranformations iterating over destination pixels.