mbuf_update.c revision 830
/* Copyright 1993 Sun Microsystems, Inc. All rights reserved. * Use is subject to license terms. * Permission is hereby granted, free of charge, to any person obtaining a * copy of this software and associated documentation files (the * "Software"), to deal in the Software without restriction, including * without limitation the rights to use, copy, modify, merge, publish, * distribute, and/or sell copies of the Software, and to permit persons * to whom the Software is furnished to do so, provided that the above * copyright notice(s) and this permission notice appear in all copies of * the Software and that both the above copyright notice(s) and this * permission notice appear in supporting documentation. * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT * OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR * HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL * INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING * FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. * Except as contained in this notice, the name of a copyright holder * shall not be used in advertising or otherwise to promote the sale, use * or other dealings in this Software without prior written authorization * of the copyright holder. ** Routines of the update phase for multibuffers. ** Note: On every alias or mbufset change, we will report the following ** types of changes. See comment at start of win_update.c for reason why we ** don't try to optimize change reporting. ** cache (nonviewable mbufs only) ** TODO: ISSUE: since an alias change occurs on every multibuffer frame, ** if we don't optimize for multibuffers this could add unwanted per-frame ** overhead. Is it significant? If so, we are forced to optimize alias ** change reporting. Composition changes are so infrequent that it still ** won't be worth optimizing the reporting of them. (Note: this issue ** doesn't apply to windows.) ** ENTRY ROUTINE FOR MULTIBUFFER UPDATE PHASE * Before we get going check to make sure that composition changes * have been noticed. If we don't and the number of multibuffers * has increased bad things will happen. ** 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 */ /* the first thing we must change is the multibuffer state. This may later 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. ** 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 /* 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: viewable mbuf never has bstore to sync up to */ /* Note: we don't need to check the cacheseq here, because for a nonviewable drawable the cache is the only thing to sync so there will never be any reason for it to be out-of-sync /* we're now all synchronized */ ** 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 to synchronize */ /* Now that we know the current mbufset composition, we know the number of multibuffers. if the real lock subject is beyond this, treat it as a zombie */ /* synchronize with any display buffer change */ /* synchronize render buffer state (if necessary) */ /* The window is no longer multibuffered. This multibuffer is a zombie */ /* an mbufset change causes us to report changes to all attrs */ ** Determine effective lock subject for a multibuffered window. /* see if there is buffer aliasing. Buffer aliasing can only happen in copy flip mode */ /* TODO Daryl Is this true? In document it talks about * buffer aliasing with DGA_MBFLIP_VIDEO mode. */ /* when the buffer is aliased, the effective lock subject is always the main window */ /* an alias change causes us to report changes on all attributes */ ** In addition to the mbufset-common types of derivative changes, ** we may also need to cause a clip change to be reported. ** If we've switched from a viewable lock subject to ** a nonviewable one (or vice versa) force a clip change even ** if the clip of the current effective lock subject has not changed. ** This is because the clips of nonviewable drawables are ** always rectangular and those of viewable ones may not be. ** Current lock subject is a viewable multibuffer. Synchronize with changes. /* Note: viewable multibuffers share the clip and cursor state /* clip state of main window has changed? */ /* cursor state of main window has changed? */ /* Note: viewable multibuffers do not yet have backing store */ ** Current lock subject is a non-viewable multibuffer. Synchronize with changes. /* don't try to synchronize if multibuffer is a zombie */ /* first, see if the shared info is still valid */ /* Note: a non-viewable multibuffer never has a cursor or backing store. And it's clip is always constant. The only thing that can change is the cache or devinfo state */ /* Has the cache changed? */ /* Has the dev_info changed? */ /* synchronize change counts */ /* synchronize change counts */