win_update.c revision 830
98N/A/* Copyright 1994 Sun Microsystems, Inc. All rights reserved. 98N/A * Use is subject to license terms. 98N/A * Permission is hereby granted, free of charge, to any person obtaining a 98N/A * copy of this software and associated documentation files (the 98N/A * "Software"), to deal in the Software without restriction, including 98N/A * without limitation the rights to use, copy, modify, merge, publish, 98N/A * distribute, and/or sell copies of the Software, and to permit persons 98N/A * to whom the Software is furnished to do so, provided that the above 98N/A * copyright notice(s) and this permission notice appear in all copies of 98N/A * the Software and that both the above copyright notice(s) and this 98N/A * permission notice appear in supporting documentation. 98N/A * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 98N/A * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 98N/A * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT 98N/A * OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR 98N/A * HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL 98N/A * INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING 98N/A * FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, 98N/A * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION 98N/A * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. 98N/A * Except as contained in this notice, the name of a copyright holder 98N/A * shall not be used in advertising or otherwise to promote the sale, use 98N/A * or other dealings in this Software without prior written authorization 98N/A * of the copyright holder. 98N/A** Routines of the update phase for windows. 98N/A#
endif /* SERVER_DGA */ 98N/A** Note: for the sake of simplicity, we always report the following 183N/A** types of changes whenever an alias or mbufset composition change 183N/A** occurs. We could try to optimize the change reporting and only 183N/A** report an attribute change if we know that the attribute has definitely 183N/A** changed since the last lock. But this requires a lot of comparison 183N/A** between the current and previous lock subjects and the decision 98N/A** tree gets quite large. This method of "over reporting" may result 98N/A** in some redundant change reports. If we want to do this type of optimization 98N/A** in the future, we still can. But for now we keep it simple. 98N/A** These are the window changes that are automatically reported whenever 98N/A** an alias or mbufset composition change occurs. 98N/A** ENTRY ROUTINE FOR WINDOW UPDATE PHASE 98N/A ** 1. The first thing we do in the update phase is to synchronize 98N/A ** the client structure. When all pertinent client change 156N/A ** counters match the server, we are synchronized. The 156N/A ** reason we must do this in a loop is that some of the 98N/A ** synchronizations require us to temporarily unlock and 98N/A ** relock. While the drawable is unlocked, it can undergo 98N/A ** more changes, so we may need to start the synchronization 98N/A /* Determine sequence counts for state reported to client */ 156N/A /* start accumulating changes */ 98N/A /* first, see if the window shared info is still valid */ 98N/A /* next, we must check the multibuffer state. 98N/A This may alter the effective lock subject, whose type the 98N/A other synchronization checks depend on */ 98N/A /* synchronize with current changes to attributes of 98N/A the effective lock subject -- depends on the type 98N/A of the current lock subject */ 98N/A /* should never happen */ /* Note: whether we need to sync again depends on the type too */ /* Check if the devinfo has changed */ ** 2. The foregoing synchronization step has determined whether ** any attribute changes have occurred. We must now determine ** if there are any derivative changes to report. ** Currently, the only derivative changes for a window or viewable ** multibuffer are those in common with all mbufset members. ** 3. Next, we must report changes through notification functions, /* report any changes that we can through notification */ ** 4. Lastly, indicate that we are fully synchronized and get out. /* the dgawin client structure is now fully synchronized with the ** 5. If this is an overlay window, then we need to tell the ** server that we may have modified the opaque shape. /* if there are still any changes that were not notified through notification functions, DGA_DRAW_MODIF will return nonzero (the client is supposed to call this routine immediately following the lock). This will cause a well-behaved client to synchronize with the remaining unreported changes */ ** Returns nonzero if we are still not synchronized /* if a multibuffer change happened, we're still not done */ /* Note: there's no need to check cacheseq because the effective lock subject of a window can only be a window or viewable multibuffer. Neither of these are cached */ /* Note: viewable mbuf never has bstore to sync up to */ /* should never happen */ /* we're not synchronized; need to go around the loop again */ ** Called at window lock time when we have detected an mbufset change. ** At the return of this routine, dgawin->eLockSubj indicates the member ** drawable for which subsequent changes are to be detected. /* react to enable and composition changes */ /* if window is multibuffered we may need synchronization */ /* synchronize with any display buffer change */ /* synchronize render buffer state (if necessary) */ /* an mbufset change causes us to report changes to all attrs */ /* should never happen */ ** Determine effective lock subject for a multibuffered window. /* see if there is window aliasing. Window aliasing can only happen in video flip mode */ /* when the window is aliased, the effective lock subject is the currently displayed buffer */ /* an alias change causes us to report changes on all attributes */ ** Current lock subject is a window. Synchronize with changes. /* clip state has changed? */ /* cursor state has changed? */ /* backing store state has changed? */