On 15 May 2011, at 20:52, CIB wrote: > When I tried to create an offscreen buffer in the initialization of my > widget, it would give me a segmentation fault. Sure enough, when I moved the > code to the first draw, it would work just fine. So I'm assuming that > offscreen buffers only work when FLTK is currently drawing, but I wonder why?
Actually, offscreen buffers only work when you have a valid rendering context (as they do during the draw() method of your class) but if you are keen to render into the offscreen at other times, you can use the make_current() method, to ensure an appropriate render context is available for the offscreen. Give that a try, see if that does what you need. > After all, you're not drawing to a window or widget, you're drawing to an > offscreen buffer that may or may not be related to one. Well, the offscreen is kind of always related to a window - on most (all?) platforms it more or less inherits its "nature" from a native window for the target, so as far as most of the system knows you are rendering into a window - hence you need to have a valid context for the drawing methods to hang onto when rendering into the offscreen... > On a different note, is there a problem with drawing offscreen buffers onto > themselves(with an offset)? This would be useful to speed up scrolling. Don't know - might work. Or, might work on some platforms, or with certain graphics drivers... Not sure. You could try it of course. The results might be interesting and/or entertaining anyway! Why do you think it would speed scrolling, though? Scrolling is generally buffered on most platforms anyway, so adding an additional indirection might not make any differences and might even feasibly be slower, so... YMMV. -- Ian _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
