| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1107.1 | Use XGetImage but only if you have to it's slow | STAR::BMATTHEWS | | Fri Jul 14 1989 13:59 | 8 |
| The only way to ensure that the draw has actually reached the frame buffer
is to do an XGetImage call for say one pixel in the window.
To sync the two windows you need to communicate between the 2 apps. What has
already been queued to the window system will still be processed however.
Bill
|
| 1107.2 | Wait for expose | GVRIEL::SCHOELLER | Who's on first? | Fri Jul 14 1989 14:27 | 15 |
| Q1
Mapping the window and synching does not guarantee that the operation will be
done in time for some other operation. Instead, they should map, WAIT FOR
THE EXPOSE EVENT and then notify the other process. That way the other process
will not even be notified until after the window is visible.
Q2
I am not sure but I think that you are right. Once the commands are sent
to the server, it has no way to know about the priorities of the client
programs. In theory, situations in which two clients have similar rates of
interaction with the server AND ARE RUNNING ON THE SAME HOST will allow priority
to have the effect you desire. Otherwise, I suspect that you are SOL.
Dick
|
| 1107.3 | | SDSVAX::SWEENEY | Honey, I iconified the kids | Fri Jul 14 1989 18:27 | 18 |
| re: .0
More basic issues: the "synchronization" in the X Window System is with
respect to a clients connection to the server. Synchronization with
the server means that the server will send all the "server side" data
to the client before processing the next client message. The "server
side" data is typically errors and input for that client.
The is no way to impose synchronization on all the other clients of the
server. Philosophically, it seems unfair to me for one client to impose
it on another without agreement.
Stacking order (which window is on top of another) doesn't need to
depend on creation order: the first window can always XRaiseWindow
itself to assert that it is on top of the stacking order whenever it
needs to.
|
| 1107.4 | Use MapNotify events for problem #1 | DECWIN::KLEIN | | Mon Jul 17 1989 12:41 | 32 |
| >> 1) They have been having dificulties syncronizing two seperate
>> processes that need to put up windows in sync. Basically they have one
>> process that needs to put up a background window this process askes
>> DECwindows to put up the first window and calls the sync routine (they
>> didn't give me the name of the call but its part of the X or decwindows
>> toolkit X$SYNC??). They then send a message to the other process and
>> tell it that it is ok to put up the other (foreground) window. For
>> some reason the foreground window typically ends up displaying first.
>> If they add a wait inside the program of the first process between the
>> time it puts up its window and tells the second program to put up the
>> foreground window everything works. However, they don't feel
>> comfortable with having to have a wait x parameter in their program and
>> would like to know why the xwindow sync routine is not working.
The problem here is that the window manager is causing the window map
request to be redirected. The solution is to solicit and wait for a
MapNotify event associated with the first (background) window before sending
the "ok" message to the foreground process.
The redirection of the MapWindow request essentially forks a thread from
the requesting process into the window manager. The X$SYNC request
only waits for the MapWindow request to have been received by the server
and forwarded to the window manager. It does not wait for the window
manager to reissue the request. In fact, it can take quite a while
for the window manager to get around to it.
Only when the "background" process receives the MapNotify event for the
background window can it know for sure that the window is mapped and
only then can the "foreground" process be started.
-steve-
|