mbuf_update.c revision 943
943N/A/* Copyright (c) 1993, Oracle and/or its affiliates. All rights reserved. 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 multibuffers. 830N/A** Note: On every alias or mbufset change, we will report the following 830N/A** don't try to optimize change reporting. 830N/A** cache (nonviewable mbufs only) 830N/A** TODO: ISSUE: since an alias change occurs on every multibuffer frame, 830N/A** if we don't optimize for multibuffers this could add unwanted per-frame 830N/A** overhead. Is it significant? If so, we are forced to optimize alias 830N/A** change reporting. Composition changes are so infrequent that it still 830N/A** won't be worth optimizing the reporting of them. (Note: this issue 830N/A** doesn't apply to windows.) 830N/A** ENTRY ROUTINE FOR MULTIBUFFER UPDATE PHASE 830N/A * Before we get going check to make sure that composition changes 830N/A * have been noticed. If we don't and the number of multibuffers 830N/A * has increased bad things will happen. 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 /* the first thing we must change is the multibuffer state. 830N/A This may later 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 ** 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 /* 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: viewable mbuf never has bstore to sync up to */ 830N/A /* Note: we don't need to check the cacheseq here, because for 830N/A a nonviewable drawable the cache is the only thing to sync 830N/A so there will never be any reason for it to be out-of-sync 830N/A /* we're now all synchronized */ 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 to synchronize */ 830N/A /* Now that we know the current mbufset composition, we know the 830N/A number of multibuffers. if the real lock subject is beyond 830N/A this, treat it as a zombie */ 830N/A /* synchronize with any display buffer change */ 830N/A /* synchronize render buffer state (if necessary) */ 830N/A /* The window is no longer multibuffered. This multibuffer is a zombie */ 830N/A /* an mbufset change causes us to report changes to all attrs */ 830N/A** Determine effective lock subject for a multibuffered window. 830N/A /* see if there is buffer aliasing. Buffer aliasing 830N/A can only happen in copy flip mode */ 830N/A /* TODO Daryl Is this true? In document it talks about 830N/A * buffer aliasing with DGA_MBFLIP_VIDEO mode. */ 830N/A /* when the buffer is aliased, the effective lock subject is 830N/A always the main window */ 830N/A /* an alias change causes us to report changes on all attributes */ 830N/A** In addition to the mbufset-common types of derivative changes, 830N/A** we may also need to cause a clip change to be reported. 830N/A ** If we've switched from a viewable lock subject to 830N/A ** a nonviewable one (or vice versa) force a clip change even 830N/A ** if the clip of the current effective lock subject has not changed. 830N/A ** This is because the clips of nonviewable drawables are 830N/A ** always rectangular and those of viewable ones may not be. 830N/A** Current lock subject is a viewable multibuffer. Synchronize with changes. 830N/A /* Note: viewable multibuffers share the clip and cursor state 830N/A /* clip state of main window has changed? */ 830N/A /* cursor state of main window has changed? */ 830N/A /* Note: viewable multibuffers do not yet have backing store */ 830N/A** Current lock subject is a non-viewable multibuffer. Synchronize with changes. 830N/A /* don't try to synchronize if multibuffer is a zombie */ 830N/A /* first, see if the shared info is still valid */ 830N/A /* Note: a non-viewable multibuffer never has a cursor 830N/A or backing store. And it's clip is always constant. The 830N/A only thing that can change is the cache or devinfo state */ 830N/A /* Has the cache changed? */ 830N/A /* Has the dev_info changed? */ 830N/A /* synchronize change counts */ 830N/A /* synchronize change counts */