win_update.c revision 943
965N/A/* Copyright (c) 1993, 1994, Oracle and/or its affiliates. All rights reserved. 550N/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. 965N/A** Routines of the update phase for windows. ** Note: for the sake of simplicity, we always report the following ** types of changes whenever an alias or mbufset composition change ** occurs. We could try to optimize the change reporting and only ** report an attribute change if we know that the attribute has definitely ** changed since the last lock. But this requires a lot of comparison ** between the current and previous lock subjects and the decision ** tree gets quite large. This method of "over reporting" may result ** in some redundant change reports. If we want to do this type of optimization ** in the future, we still can. But for now we keep it simple. ** These are the window changes that are automatically reported whenever ** an alias or mbufset composition change occurs. ** ENTRY ROUTINE FOR WINDOW UPDATE PHASE ** 1. The first thing we do in the update phase is to synchronize ** the client structure. When all pertinent client change ** counters match the server, we are synchronized. The ** reason we must do this in a loop is that some of the ** synchronizations require us to temporarily unlock and ** relock. While the drawable is unlocked, it can undergo ** more changes, so we may need to start the synchronization /* Determine sequence counts for state reported to client */ /* start accumulating changes */ /* repeat synchronization functions as needed through possible unlock/relocks */ /* first, see if the window shared info is still valid */ /* next, we must check the multibuffer state. This may alter the effective lock subject, whose type the other synchronization checks depend on */ /* synchronize with current changes to attributes of the effective lock subject -- depends on the type of the current lock subject */ /* 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? */