On Mon, Apr 23, 2012 at 2:23 AM, MacArthur, Ian (SELEX GALILEO, UK) <ian.macart...@selexgalileo.com> wrote: > > > I'm still not entirely sure what that ideal situation is supposed to > > be... > > > The only thing that's holding me back from trying to render into a > > cairo_image_surface instead of a cairo_xlib_surface is that I'm > > still using XFT for text. I expect the practical performance of > > double buffering into an image surface and using Cairo's 'extents' > > functionality to avoid copying anything but the affected areas to > > the front buffer is probably going to be better than the current > > FLTK model regarding the number of actual pixels pushed through > > Xlib. But the bottom line is that drawing anything curved repeatedly > > is a bad idea with Cairo and the only solution in situations that > > require speed is to draw the shape once offscreen and copy it as > > many times as necessary. I'm pretty sure this is how most GTK > > widgets operate efficiently. This is also going to be true when > > using the OpenGL backend etc... It'll only be fast if you're caching > > everything you draw since Cairo's antialiasing of curves is so slow. > > > Having a doublebuffer() property (defaulting to off) on individual > > widgets like GTK does would make this easier on the library user in > > most cases. I'll probably do this in my fork. > > > So, hmm, I wonder... When we render text in GL contexts, both the X11 and OSX > versions actually render the text into a "cache" the first time the text is > rendered, then render it from that cache on subsequent calls (though they > appear to use different caching schemes to achieve this - or am I getting > confused with the fltk2 X11 GL rendering again? Who knows...?) (Also, note > that the WinXX WGL_ methods handle text in GL without this caching scheme.) > > Anyway, what I was wondering was whether, at least for your use case, it > would be feasible to render the Cairo widgets into an offscreen cache on > first use, then just blit them into an X11 surface on subsequent calls - > overlaying them with XFT text as required? > > That might give a Cairo-like rendering with XFT text without totally > subverting fltk's existing (albeit perhaps non-optimal) render path? > > Would that work? Might be OK and faster than "pure" Cairo - though would mean > subclassing each widget to do the render/cache thing. > > And might not work at all for that set of your end-users for which offscreen > buffers appear to be painfully slow... > > Just a thought in passing. To be honest, I haven't really thought this > through at all, but is *seems* quite attractive on first glance... > > -- > Ian
AFIAK, drawing pretty much anything 'interesting' in OpenGL is only fast if you cache things in textures on the card and then just use OpenGL to move them around. Yes, doublebuffering (triplebuffering?) all FLTK widgets individually would be fast, but it would also waste a lot of memory. GTK users might be OK with this, but I like to keep memory usage to a minimum. For ordinary buttons and things it really doesn't matter how many thousands of times slower drawing a curve is in Cairo, because the button simply isn't drawn frequently enough to be perceptibly slow. And if you're using a theme with perfectly rectangular FL_UP_BOX etc, the difference in speed is negligible. The use kind of use-case I'm thinking of for a doublebuffer() property on individual widgets is... say you are beginning a drag operation on a widget on a canvas... Set the doublebuffer() property to true at the beginning of the drag and set it back to false at the end.. This way during the draw the backing image is just copied to the screen without having to redraw the entire widget (this assumes that the need to re-display is differentiated from the need to redraw, currently the only way to do that is with damage(FL_DAMAGE_EXPOSE). Obviously this can already be done with the existing offscreen stuff, but it's a bit of a hassle. In my own applications I don't actually have a lot of use for this, because the widgets that are complex to draw and potentially slow are also effectively infinitely wide and scrollable, so I can't realistically cache the whole thing. But I have been thinking about the canvas issue because of something I'm working on in Non-Mixer and also because the canvas in SpiralSynthModular has always been embarrassingly slow and I'd like to fix that. BTW, here's screenshot of SSM rendered using my Cairo fork of FLTK with the 'Cairo' theme: http://non.tuxfamily.org/spiralsynthmodular-cairo1.png And also ZynAddSubFX (a program which many people love but often complain is ugly due to FLTK) http://non.tuxfamily.org/zynaddsubfx-theme6.png _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
