> Scott A Thisse wrote:
>
> > I tried the attached code (after cloning another png file to be
> > splash-bg3.png) and I still get the noticeable delay that the OP was
> > concerned with.
> >
> > Doubling the delay loop gave a corresponding increase in delay before
> > the splash screen _image_ was displayed. I get:
> >
> > splash win background -- delay -- splash image -- delay -- main win
> >
> > The sleep/usleep appears to be suspending everything before the image
> > has a chance to display. If I made the loop condition a hundred times
> > bigger (300) and the sleep/usleep a hundred times smaller (10/10000),
> > the image displays quickly.
> >
> > ===== ===== =====
> >
> > for (int i=0; i<300; i++ ) {
> > Fl::check(); // call this first
> > #ifdef WIN32
> > Sleep ( 10 );
> > #else
> > usleep( 10000 );
> > #endif
> > }
> >
> > ===== ===== =====
>
> I can't see this with a normal Windows program, but I can also see this with
> an
> X11 version (even with a local display on my Windows box (FLTK 1.3)).
>
> <guess-mode>
> I think that this has to do with the X11 protocol, and the first Fl::check()
> is
> maybe too early to process the window show event and/or some other rendering
> or
> drawing calls. Making the delay shorter (with more loops, like you did), makes
> the image appear quickly. I don't know enough about the X11 internals to do
> more
> than guessing here. Maybe someone else can confirm this.
> </guess-mode>
>
> Just for testing I added a small delay with Fl::check() in the constructor,
> and
> this made the image also appear quickly. Seems to confirm this.
>
> However, this is now somewhat academical. I'll post another "two independent
> windows" example without these problems in another reply.
>
> Albrecht
What I find hard to reconcile is:
1. I was told that fltk should be finished with the image to be displayed by
the time show() returns.
2. usleep() is a "system call", so it will put the current (fltk) application
to sleep, granting CPU cycles to any other running
applications/processes/threads (i.e., X). So if fltk is indead "finished with
the image", WHY does sleeping the fltk application for a longer period extend
the delay? If the hold up was anything to do with X, one would expect a longer
sleep of the fltk processs would speed up the display, since X would get a
larger share of the CPU.
My own suspicion is that there IS still some level of "background processing"
being done by fltk before the image will be displayed, that explains why
usleep() increases the delay, and why frequently yielding to background
processing via wait() or run(), etc. speeds up the delay.
Which brings me to another question: does "Fl::Window->shown()" report true if
fltk THINKS the window is visible, or if it has ACTUALLY been rendered to the
screen? (and if the latter, how does it KNOW?)
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
