> 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.
No, with respect, I don't think that you were told that, although it's a tricky thing - lots of stuff happening "in parallel" so it is very confusing and somewhat opaque. I think that you were told that fltk would be finished with the image file, once the calls that create the Fl_PNG_Image were done (so the png file on the disk can be released, and at that point fltk will have a complete version of the image in its memory) but this does *not* mean that the image will be mapped to the display by then. Indeed, with most WM's, all you can ever know is that you have asked it to show your window - what it has *actually* done is a whole other story... > 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. Yup, well, hmmm... The fltk rendering model is such that things are drawn "in the background", so the problem is that although the fltk "foreground" (as it were) has finished with the data, the background rendering steps may not be, so fltk needs some time to chat with the X-server and get the thing drawn. This is why causing fltk to sleep slows things down. Unless you really want to stop fltk, calling sleep is seldom useful on a desktop type OS, as they will manage scheduling by fairness (rather than by hard priority) and so the X-server and everybody else will get a share of the execution time whether you make your app explicitly yield or not. So in this case, it doesn't make a great deal of sense to call sleep. You would probably get better and more consistent results using the FL timers - Fl::add_timeout() - to do what you need here, or something... > 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?) No, generally not. It can depend on what platform you are on, or even what WM you are using, but for the most part it only reports that the WM has acknowledged a request to show the window... Whether it has actually been mapped to the display or not, that's a whole other story... SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
