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