This question changed a lot since it was first asked because I didn’t understand how little I knew about what I was asking. And one issue, regarding resizing, was clouding my ability to understand the larger issue of creating and using the framebuffer. If you just need a framebuffer jump to the answer… for history I’ve left the original question intact.
Newbie question. I’ve got a GL project I’m working on and am trying to develop a selection strategy using unique colors. Most discussion/tutorials revolve around drawing the selectable entities in the back buffer and calculating the selection when a user clicks somewhere. I want the selection buffer to be persistent so I can quickly calculate hits on any mouse movement and will not redraw the selection buffer unless display or object geometry changes.
It would seem that the best choice would be a dedicated framebuffer object. Here’s my issue. On top of being completely new to framebuffer objects, I am curious. Am I better off deleting and recreating the frambuffer object on window size events or creating it once at the maximum screen resolution and then using what may be just a small portion of it. I’ve got my events working properly to only call the framebuffer routine once for what could be a stream of many resize events, yet I’m concerned about GPU memory fragmentation, or other issues, recreating the buffer, possibly many times.
Also, will a framebuffer object (texture & depth) even behave coherently when using just a portion of it.
Ideas? Am I completely offbase?
EDIT:
I’ve got my framebuffer object setup and working now at the windows dimensions, and I resize it with the window. I think my issue was classic “overthink”. While it is certainly true that deleting/recreating objects on the GPU should be avoided when possible. As long as it is handled correctly the resizes are relatively few.
What I found works is to set a flag and mark the buffer as dirty on window resize, then wait for a normal mouse event before resizing the buffer. A normal mouse enter or move signals you’re done dragging the window to size and are ready to get back to work. The buffers recreated once. Also, since the main framebuffer is generally resized for every window size event in the pipeline, it would stand to reason that resizing a framebuffer isn’t going to burn a hole in your laptop.
Crisis averted, carry on!
I mentioned in the question that I was overthinking the problem. The main reason for that is because the problem was bigger than the question. The problem was, not only did I not know how to control the framebuffer, I didn’t know how to create one. There are so many options and none of the web resources seemed to specifically address what I was trying do, so I struggled with it. If you’re also struggling with how to move your selection routine to a unique color scheme with a persistent buffer, or are just at a complete loss as to framebuffers and offscreen rendering, read on.
I’ve got my OpenGL canvas defined as a class, and I needed a “Selection Buffer Object.” I added this to the private members of the class.
In both my resize handler and OpenGL initialization I set the dirty flag for the selection buffer.
At the begining of my mouse handler I check for the dirty bit and
setSelectionBuffer();if appropriate.This tackles my initial concerns about multiple delete/recreates of the buffer. The selection buffer isn’t resized until the mouse pointer reenters the client area, after resizing the window. Now I just had to figure out the buffer…
Then at the end of my render function I test for the sbo, and draw to it if it seems to be ready.
That gives me this…
At this point I believe everything is in place to actually draw selectable items to the buffer, and use mouse move events to test for hits. And I’ve got an onscreen thumbnail to show how bad things are blowing up.
I hope this was as big a help to you, as it would have been to me a week ago. 🙂