Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re^2: Perl/Tk window contents disappear when obscured then revealed

by Another Ed (Acolyte)
on Jan 22, 2013 at 13:45 UTC ( #1014658=note: print w/ replies, xml ) Need Help??


in reply to Re: Perl/Tk window contents disappear when obscured then revealed
in thread Perl/Tk window contents disappear when obscured then revealed

Hi BrowserUk, thanks for your reply. I was under the impression that entering MainLoop put Perl/Tk into a state of waiting for and handling user interaction, such as clicking a button on a dialog. This is not what I want to do at this point in my program: I want Perl to display a message (one which doesn't disappear), invoke an external program (the scanner program), then carry on processing (without user interaction) once the external program has been closed by the user. Sounds a simple sequence of events, but I'm beginning to think that Perl can't handle it.

Do feel free to correct me if you still think MainLoop is appropriate here. Any pointers to specific documentation other than "RTFM" would be appreciated.


Comment on Re^2: Perl/Tk window contents disappear when obscured then revealed
Re^3: Perl/Tk window contents disappear when obscured then revealed
by choroba (Abbot) on Jan 22, 2013 at 13:53 UTC
    "carry on processing" is not an event. Start the program in the background, make its finish an event.
    لսႽ ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

      Hi choroba, you've lost me a bit here. thundergnat suggested I run the external program with 'start', which I believe puts the program into the background on Windows. As I replied to his post, doing this means that Perl doesn't wait for the external program to finish, but steams on regardless. That is no good to me.

      It would be nice if there were some way of making Perl wait. You say "make its finish an event". That sounds promising, except that I haven't a clue how to translate that into code. Surely we're hampered here by the fact that Windows doesn't have a readily accessible process table, so I can't do things like 'system ("ps", ...)'?

      One thing that's occurred to me is that I could try a 'fork' call for the external process, combined with 'waitpid'. These, I understand, are emulated on Windows by Perl. It just seems a bit of a sledgehammer to crack this nut, but at the rate this thing is going, I will have to try it.

      Ed
Re^3: Perl/Tk window contents disappear when obscured then revealed
by BrowserUk (Pope) on Jan 22, 2013 at 18:54 UTC
    Do feel free to correct me if you still think MainLoop is appropriate here.

    The nature of GUI's is that whenever a window (or part thereof) is uncovered; or has its size changed, you have to re-draw the contents of that window.

    To achieve that you can call $->update() within long running loops; but that will often mean that updates are forced each time around the loop when they are not needed -- ie. you chew CPU for no reason -- or you can enter the event loop (MainLoop;) which will monitor the event queue and call update() only when it is required; along with servicing any and all other events as they occur.

    If you have a piece of code to run that is going to take more than say 1/10th of a second, then you have three choices:

    1. Just run the code and accept that the GUI will 'freeze' for the duration.

      This is what you have now. It's not nice or professional.

    2. Break the processing into small bits that take less than 1/10th of a second and arrange to call update() (Or better: DoOneEvent() or DoEvents()) between those small chunks.

      In practice, putting a call to DoEvents() into a convenient place in your processing loop works well enough provided that you have a loop and its frequency is neither too fast nor too slow.

      Not all long running processing involves convenient user-code loops. Waiting for an external command is one such situation.

      And even when it does; if the loop is very tight; constantly calling out to DoEvents() can substantially slow down the processing; doubling or trebling the time it takes.

      Conversely, if the loop itself takes long than 1/10th of a second to iterate, the GUI can become sluggish to respond to user input.

      This can be finely tuned by only calling DoEvent() every 5th, or 50th or 500th iteration for the fast loop; or calling it at multiple places for the slow loop; but it requires trial and error to strike the optimal balance between GUI responsiveness and processing throughput.

      But the big problem is that when you've achieve that fine balance on your development machine and move it to a different machine; the balance is lost because that machine has a faster or slower CPU; memory; disk; or a higher background workload; or any of a dozen other differences that screw up your hard one balancing act.

    3. Put the long running processing into a background thread or process.

      This is best of all, because the OS scheduler takes care of balancing the needs of the GUI responsiveness with the CPU requirements of the processing.

      Whether a background thread or process is the best solution for your application very much depends upon what that application is.

    What is this program that you are running in the background? Does it produce output that you need in your GUI application? Does it produce a file that you then need to read?

    If you supply more details; we might be able to recommend a better way of tackling the problem.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
    This can be finely tuned by only calling for the duration.

      Thanks BrowserUk for your very detailed explanations.

      I'm amazed that we're facing this problem at all: if, for example, I obscure the Firefox window into which I'm currently typing, then reveal it again, it redisplays exactly as you would expect; I am sure that the Firefox code doesn't have to contain things like sub-second checking loops just to redisplay the contents of its own window. Surely the task of redrawing a window when it is revealed is down to the window manager, not the application whose window it is? So why is Perl/Tk any different? Is this a "feature" of Tk, or is it something that has gone wrong in the Perl interface to it? You say this in the nature of GUIs - but this is so crazy that I find that difficult to believe, with all respect to you.

      I'm also surprised that this problem, which must surely be one that many many people will have faced, doesn't appear to have a standard workaround, let alone a fix.

      Regarding the choices you list, I agree that (1) is not nice. I am very uncomfortable with (2), on the basis that making the machine do a lot of work just to wait for something to happen simply doesn't seem a sensible way to approach anything. I think your (3) is the only realistic option. I can't visualise in detail how this would be done, but I guess it could use Proc::Background as suggested by Anonymous Monk below. (However the 2 responses to that suggestion both involve the same kind of crazy loops as your choice (2)!)

      I became diverted away from this problem, hence the very late response to you, and I now find I cannot devote any more time to it. I'll finish writing my application without trying to display a Perl/Tk window in parallel with another application's window, so this issue will no longer arise.

      Many thanks to everyone who has contributed to this.

      Ed

        the task of redrawing a window when it is revealed is down to the window manager, not the application
        When Firefox freezes (happens to me sometimes when running adobe flash plugin), its window becomes completely gray. I can switch to other applications, but Firefox does not update its windows. I fear you are not right here.
        لսႽ ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
        I am sure that the Firefox code doesn't have to contain things like sub-second checking loops just to redisplay the contents of its own window.

        You'd be wrong I'm afraid. And you can prove it to yourself. Find a website with a page that updates (say) once a minute. Cover the section that changes and wait 1 1/2 minutes then uncover it. Is what you uncover the same as it was 1/1/2 minutes ago? Or has it changed.

        Surely the task of redrawing a window when it is revealed is down to the window manager, not the application whose window it is?

        The best the window manager could do is cache the bits that you cover up and blit them back when you uncover it again; but that wouldn't then reflect any changes that have happened in the mean time. (Ask yourself: How could the window manager know what might have changed -- if anything -- without consulting the application?)

        But that isn't what happens. When the window uncovers, An 'update rectangle' that denotes the uncovered region is sent as part of an update message to the applications window procedure and it is responsible for redrawing that rectangle.

        That's a lightweight description of the process -- the real thing is far more complex (long ago I helped write and test the window manager used by OS/2's Presentation Manager) -- but close enough for discussion.

        The best applications that have dynamic window content, draw into an off-screen window buffer; and simply blit the appropriate part of it on-screen in response to update messages. This effectively decouples the drawing process from user events. My biggest beef with Tk (and many other GUI toolkits) is that they do not give you direct access to the window buffers, which effectively prevents using this optimum strategy.

        There have been attempts to move this functionality into some GUI toolkits, but with zoomable and scrollable windows, it means the application has to maintain the entire 'world content', even when large parts of it are off screen (and thus could be skipped for optimisation purposes), because the application is no longer in control of what is actually being displayed at any given time.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1014658]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (6)
As of 2014-09-21 19:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (175 votes), past polls