> > 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?)
>
OR MAYBE...
maybe X spawns a thread (/process?) to handle each applications drawing calls.
When the application is put to sleep, the associated X thread (/process) is
also sleeping?
hhhhmmmm......
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
