If you’re using glCopyTexSubImage2D to paste the dirty rectangle:
RECT DirtyRect; // computed by Brush_Position and Brush_Size
int wid = tempRect.right-tempRect.left;
int hei = tempRect.bottom-tempRect.top;
glCopyTexSubImage2D(...); // x/y/width/height/xoffset/yoffset derived from tempRect and the texture-position onscreen
The glCopyTexSubImage2D approach is prone to the following pitfall, though: if the brush/DirtyRect is not completely in the viewport or even some window is partially obscuring it, the copied pixels will have undefined values.
This can be solved in many ways, but maybe the best+easiest would be to use FBOs and draw the brush on each FBO/texture it covers.
ok. you can think of my app as a meter that is drawing intensity as the paper below it scrolls. the paper is my background texture. right now my paper is a single texture that is twice the size of my display (viewport). i change which portion i show from the texture to accomplish the “scrolling” it works, but the paper is real short
I then capture the entire image at the end for the user.
i want the “paper” to be infinite or longer that 2x.
does that help? i appreciate the suggestions. i am in the opengl es environment
Ah, I see. So with infinite length, an open-ended array of textures is probably your best bet. Based on scroll position and zoom factor, you can dynamically decide which segments (textures) are within viewport, and draw just them. Or let GL cull them - your pick.
However, you might consider whether it might not make sense to rerender the raw data within the scroll window directly, rather than save the result off into a textures. Less memory consumption…
opengl es environment
…which is probably a bigger deal on your embedded platform.