Joerg Desch wrote:
> Whats the right way to use BitBlt from within an thread? Do I have to lock
> FLTK as mentioned in this group?
I would think you'd want to lock to avoid a situation where both
FLTK and your BitBlt thread contend for accessing the same window.
> Which parts to I have to overwrite if I subclass Fl_Box? There is nothing
> to draw, because the thread must draw it asynchronous. Should I overwrite
> draw and call the parents draw only if the "video thread" is not running?
Just curious; if there's nothing to draw(), then maybe it makes
sense to just use regular Windows code to open/maintain just your
video window?
For instance, this is how the WIN32 version of Fl_Native_File_Chooser
works; within an FLTK app, it opens its own window using pure win32
code to open/manage the browser window.. no FLTK is involved.
If you open your own window, I'm not sure how this impacts
the need to handle thread locking. It's probably best if you
design with locking in mind, to avoid any possibility of both
FLTK and your separate thread from both accessing the
window manager routines at the same time, just to avoid problems.
Either that, or fire off the video window as a separate process
altogether, and have the FLTK app and video player app establish
a simple messaging passing scheme to manage play control via TCP,
named pipes, or whatever.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
