Forcing redraw of a window from a background process
Locked
Forcing redraw of a window from a background process
 
|
A forked process
with priority 'Processor userInterruptPriority' sends a 'display'
to a window to force
it being redrawn.
But the foreground
processes need a big amount of CPU time and thus the
window is sometimes
redrawn, sometimes not.
I tested already
also with damageRepairIsLazy: true/false, didn't help.
The 'display' method
at the end sends 'displayOn: self graphicsContext' to the
window.
Is it possible to
really force the redraw of the window ?
Karl
________________________________________________________________
Karl-Albert Breith
AREVA NP GmbH FEEC - G Freyeslebenstrasse 1 91058 Erlangen
|
Re: Forcing redraw of a window from a background process
|
|
Hey Karl,
Instead of directly sending the display message, have you considered creating dependencies between the represented objects and your value models; I admit, I didn't take enought time to figure out what could be going wrong in your case (and neither do I have VW available here....), but I usually find it easier to use the features of the available framework than to try to implement my own logic. I remember the class AspectAdaptor implements the method subjectSendsUpdate: aBoolean. Again, I am not in front of VW, so there might be typos, but I think you'll be able to understand what I mean. OK, now... if already know all this and are absolutely sure the best way to proceed is by sending a display message to the window, my recommendation would be for you to check the priorities of you proccesses. The main proccess you mentioned (the one taking all the CPU)... under which priority is it running? hoping to help, Ricardo On 5/18/06, BREITH Karl-Albert FEEC-G (AREVA NP GmbH) <[hidden email]> wrote:
|
Re: Forcing redraw of a window from a background process
|
|
Karl,
the interactively started process is fork at which priority? what kind of views do you have in the window? I am assuming they represent something that is changed on the cpu consuming process, thus the need to keep it in the foreground, am I right? obs: try to send your replies to the list (1-so that more people can help you 2-so that the archive can help someone else with a similar problem some other day) regards, Ricardo On 5/18/06, BREITH Karl-Albert FEEC-G (AREVA NP GmbH) <[hidden email]> wrote:
|
RE: Forcing redraw of a window from a background process
|
|
In reply to this post by BREITH Karl-Albert (AREVA)
Karl If you are using VW 7.1 or later you
should never update a window from a process that is not the ui process of
the window’s window manager. Look through the documentation and read up
on WindowManager and DeferredEvent. You want to do something like; [window refresh] uiEventFor: window. #refresh will force the entire window to
be redisplayed. Terry From: BREITH
Karl-Albert FEEC-G (AREVA NP GmbH) [mailto:[hidden email]] A forked process with priority 'Processor
userInterruptPriority' sends a 'display' to a window to force it being redrawn. But the foreground processes need a big amount of CPU time
and thus the window is sometimes redrawn, sometimes not. I tested already also with damageRepairIsLazy: true/false,
didn't help. The 'display' method at the end sends 'displayOn: self
graphicsContext' to the window. Is it possible to really force the redraw of the window ? Karl ________________________________________________________________ Karl-Albert Breith
mail to: [hidden email]
|
Re: Forcing redraw of a window from a background process
|
|
In reply to this post by Ricardo Birmann
hmmm... maybe someone who understands a bit more about the process framework could help...
one last question: what is not being repaired when the window is brought to front? the whole window, or just your view? if it is the later you could send it an invalidate message right after bringing the window to front, if it is the former... I cant help you right now (would have to take a look at the code) Hopefully someone else will promptly enlighten you with the solution Regards, Ricardo On 5/18/06, BREITH Karl-Albert FEEC-G (AREVA NP GmbH) <[hidden email]> wrote:
|
RE: Forcing redraw of a window from a background process
|
|
In reply to this post by BREITH Karl-Albert (AREVA)
Use aBlockThatUpdatesTheWindow uiEvent(Now)(For: aWindow)
Anything that updates a window should (=”must” if you want things to work reliably!) be done from the WindowManager’s UI baseProcess. The #uiEvent* methods ensure that, and the ones with “For: aWindow” ensure that VW uses the right WindowManager (otherwise it guesses!). More details are in the manuals: search index.pdx for uiEvent.
HTH, Steve
-----Original Message-----
A forked process with priority 'Processor userInterruptPriority' sends a 'display' to a window to force it being redrawn. But the foreground processes need a big amount of CPU time and thus the window is sometimes redrawn, sometimes not. I tested already also with damageRepairIsLazy: true/false, didn't help. The 'display' method at the end sends 'displayOn: self graphicsContext' to the window. Is it possible to really force the redraw of the window ?
Karl ________________________________________________________________ Karl-Albert Breith
mail to: [hidden email]
|
AW: Forcing redraw of a window from a background process
|
|
Thanks for all your recommendations and
remarks.
After all that I assume I have to rewrite my logic
completely to get what I want.
Karl
________________________________________________________________
Karl-Albert Breith
AREVA NP GmbH FEEC - G Freyeslebenstrasse 1 91058 Erlangen
|
Re: Forcing redraw of a window from a background process
|
|
Karl,
It hasn't been long since I realized that, on visual works, if I find myself doing something really complicated to get something really simple working it is always because my own code is not using the provided frameworks correctly. Nowadays, if I think it is happening again, I just stop and go for the documentation On most languages it is annoyingly often to need complex logic to get simple things done... GO SMALLTALK! :-) Ricardo On 5/18/06, BREITH Karl-Albert FEEC-G (AREVA NP GmbH) <[hidden email]> wrote:
|
RE: Forcing redraw of a window from a background process
|
|
In reply to this post by BREITH Karl-Albert (AREVA)
Yes, sorry – I didn’t read the priority carefully in your first email. What are you trying to do?
If you want a long-running process to update the window occasionally, you might consider a different approach, e.g. RefreshingDisplayPolicy in the public store. That puts the long-running process in a low-priority background process, but makes the window ignore new input events (clicks and key presses), which might be what you were trying to achieve with having the long-running block in a high priority process.
HTH, Steve
-----Original Message-----
I have tried now uiEventNowFor: and uiEventFor: Both don't update the window. I assume they have to wait, because the interactive process needs up the CPU. The whole window is not refreshed.
Karl
________________________________________________________________ Karl-Albert Breith
mail to: [hidden email]
|
RE: Forcing redraw of a window from a background process
|
|
Karl I suspect that [window refresh] uiEventNowFor:
window does not update the window because the refresh
does an invalidate which ends up posting another event to the
event queue. Try the following; [window
refresh. window windowManager
processOutstandingEvents] uiEventNowFor: window. Terry From: Steven Kelly
[mailto:[hidden email]] Yes, sorry – I didn’t read the priority
carefully in your first email. What are you trying to do? If you want a long-running process to update the window
occasionally, you might consider a different approach, e.g.
RefreshingDisplayPolicy in the public store. That puts the long-running process
in a low-priority background process, but makes the window ignore new input
events (clicks and key presses), which might be what you were trying to achieve
with having the long-running block in a high priority process. HTH, Steve -----Original Message----- I have tried now uiEventNowFor: and
uiEventFor: Both don't update the window. I assume
they have to wait, because the interactive process needs up the CPU. The whole window is not refreshed. Karl ________________________________________________________________ Karl-Albert Breith
mail to: [hidden email]
|
Re: Forcing redraw of a window from a background process
|
|
In reply to this post by Steven Kelly
I have an application that takes about an hour or so every time it runs,
either using cpu directly or waiting on i/o (tens of thousands of disk accesses, invoking external programs, etc.). My solution was to move all the real work to background processes so the UI process was just handling events. This way the UI remained responsive both to damage display and to user input, such as clicking the 'Cancel' button. If there is only one busy forked process whose priority is higher than the ui process, it's true that it can choose between #uiEventFor: and #uiEventNowFor:, depending on whether or not it wants the update to happen immediately. However, damage events initiated outside the application (temporarily obscuring the application with some other window) will *always* have to wait for the forked high-priority process to idle or block before redisplay can happen in the ui process. Therefore, I recommend running your work process at Processor userBackgroundPriority, even if there is only one. If there are multiple forked work processes, it is even more imperative to ensure their priority is lower than the ui process. Otherwise, #uiEventNowFor: will block that work process until all the forked work processes are idle or blocked; only then can the ui process handle the event and free up the blocked work process. Making the work processes lower priority than the ui process means the system naturally handles ui events promptly, then returns immediately to the "real" work. If there are some ui features that should not be available while the forked work is being done, then disable those widgets until the work processes are finished. Dave Steven Kelly wrote: > Yes, sorry – I didn’t read the priority carefully in your first email. > What are you trying to do? > > > > If you want a long-running process to update the window occasionally, > you might consider a different approach, e.g. RefreshingDisplayPolicy in > the public store. That puts the long-running process in a low-priority > background process, but makes the window ignore new input events (clicks > and key presses), which might be what you were trying to achieve with > having the long-running block in a high priority process. > > > > HTH, > > Steve > > > > -----Original Message----- > *From:* BREITH Karl-Albert FEEC-G (AREVA NP GmbH) > [mailto:[hidden email]] > *Sent:* 18 May 2006 16:50 > *To:* Steven Kelly > *Subject:* AW: Forcing redraw of a window from a background process > > > > I have tried now uiEventNowFor: and uiEventFor: > > Both don't update the window. I assume they have to wait, because the > > interactive process needs up the CPU. > > The whole window is not refreshed. > > > > Karl > > > > ________________________________________________________________ > > Karl-Albert Breith > *AREVA NP GmbH* > FEEC - G > Freyeslebenstrasse 1 > 91058 Erlangen > > Phone: > > > > +49 (0) 9131 18-97393 > > Fax: > > > > +49 (0) 9131 18-94045 > > mail to: [hidden email] > <mailto:[hidden email]> > An AREVA and Siemens company > > > > > > ------------------------------------------------------------------------ > > *Von:* Steven Kelly [mailto:[hidden email]] > *Gesendet:* Donnerstag, 18. Mai 2006 15:42 > *An:* [hidden email] > *Cc:* BREITH Karl-Albert FEEC-G (AREVA NP GmbH) > *Betreff:* RE: Forcing redraw of a window from a background process > > Use aBlockThatUpdatesTheWindow uiEvent(Now)(For: aWindow) > > > > Anything that updates a window should (=”must” if you want things to > work reliably!) be done from the WindowManager’s UI baseProcess. The > #uiEvent* methods ensure that, and the ones with “For: aWindow” > ensure that VW uses the right WindowManager (otherwise it guesses!). > More details are in the manuals: search index.pdx for uiEvent. > > > > HTH, > > Steve > > > > -----Original Message----- > *From:* BREITH Karl-Albert FEEC-G (AREVA NP GmbH) > [mailto:[hidden email]] > *Sent:* 18 May 2006 15:20 > *To:* [hidden email] > *Subject:* Forcing redraw of a window from a background process > > > > > > A forked process with priority 'Processor userInterruptPriority' > sends a 'display' > > to a window to force it being redrawn. > > But the foreground processes need a big amount of CPU time and thus the > > window is sometimes redrawn, sometimes not. > > I tested already also with damageRepairIsLazy: true/false, didn't help. > > The 'display' method at the end sends 'displayOn: self > graphicsContext' to the > > window. > > Is it possible to really force the redraw of the window ? > > > > Karl > > ________________________________________________________________ > > Karl-Albert Breith > *AREVA NP GmbH* > FEEC - G > Freyeslebenstrasse 1 > 91058 Erlangen > > Phone: > > > > +49 (0) 9131 18-97393 > > Fax: > > > > +49 (0) 9131 18-94045 > > mail to: [hidden email] > <mailto:[hidden email]> > An AREVA and Siemens company > > > |
| Free forum by Nabble | Edit this page |