Joerg Desch wrote:
> On Thu, 03 May 2007 17:10:45 -0400
> Greg Ercolano <[EMAIL PROTECTED]> wrote:
>
>> 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.
>
> So I must use lock even if the thread don't use fltk to draw to the
> window!? Is that right?
Depends on what you're doing in the other thread.
Any WIN32 calls made in your separate thread may overlap/contend
with WIN32 calls in the FLTK thread, especially on a multiproc
machine where race conditions rear their head the most.
Consider if the FLTK thread changes the window size
(something you mentioned you needed) while your separate
thread is calling BitBlt. This is a situation that /might/
cause an intermittent crash if locking isn't used to sync the two.
Having two threads accessing the same global object (a window
in this case) can create unexpected contention for global data,
not so much the pixel data, but the window manager's and FLTK's
own global data. So I'm just saying be careful.
Creating a window separately with WIN32 calls in an FLTK app
doesn't mean FLTK won't be receiving events for managing it.
FLTK's event loop will likely be receiving events globally for
all windows in the app, not just the ones FLTK created.
> I've never subclassed a fltk widget before..
A simple example of subclassing draw():
http://seriss.com/people/erco/fltk/#FltkX
And here's one example of how to animate an image in fltk
using one of fltk's floating point timers to change the
Fl_Box's image() and call redraw():
http://seriss.com/people/erco/fltk/#Animate
In your case it sounds like you might want the draw() routine
to just call fl_draw_image() or BitBlt() to draw the image's
pixels yourself. Or calling a 3rd party video playback lib
with the HWDN and x/y/w/h position you want the video to play.
Best situation is to know as much about your playback library
as you can, and all the options it offers, then try to see which
has the 'best fit' into fltk.
>> If you open your own window, I'm not sure how this impacts
>> the need to handle thread locking.
>
> I don't want to have a separate window. The video widget must be part of
> the mainwindow. So subclassing is the only way I think.
So it sounds like you want to mix fltk widgets either around
or over the playing image, and having the image playback managed
by a separate thread.
Hmm. I'll let Matthias and Ian's responses take over from here..
I don't know anything about how to go about mixing fltk
and WIN32 calls in the same window with separate threads.
I can tell you the "general" rule in fltk is all drawing
involving FLTK should be done in the main thread:
http://fltk.org/documentation.php/doc-1.1/Fl.html#Fl.lock
http://www.fltk.org/doc-2.0/html/group__multithreading.html
..however there are probably some exceptions if locking is
used carefully.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
