Jos Dreesen wrote:
> This works, i get a more or less usable display.
> But at the expected cost of some flicker.
As Ian mentioned, use an Fl_Double_Window instead of
Fl_Window. That should prevent seeing drawing operations
as they run.
>> Or, don't do that and just make sure the widget you're deriving
>> from has a solid box() type type of some kind, like box(FL_FLAT_BOX).
>> This way when the widget redraws, it won't leave the old image behind.
>
> This does not work.
Hmm, would have to see your code to know why that doesn't work.
Maybe your draw() function isn't calling the underlying widget's
draw() first, short circuiting the widget's ability to draw itself.
eg. if you derive a class 'MyClass' from Fl_Box, then your
MyClass::draw() function would need to call Fl_Box::draw()
at the top, so that it draws its decorations, so you can then
draw over that.
> Any possibility to have a behaviour more in line with xlib's XPutIMage ?
I suppose anything's possible, but FLTK being a cross platform
library, it should only support features common to all the OS's..
anything 'native' is usually up to the user. You can probably use
native X windows calls with FLTK, but I'd suggest trying to avoid
it if possible for portability sake.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk