mbsmemb_update.c revision 830
830N/A/* Copyright 1999 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 830N/A * copy of this software and associated documentation files (the 830N/A * "Software"), to deal in the Software without restriction, including 830N/A * without limitation the rights to use, copy, modify, merge, publish, 830N/A * distribute, and/or sell copies of the Software, and to permit persons 830N/A * to whom the Software is furnished to do so, provided that the above 830N/A * copyright notice(s) and this permission notice appear in all copies of 830N/A * the Software and that both the above copyright notice(s) and this 830N/A * permission notice appear in supporting documentation. 830N/A * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 830N/A * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 830N/A * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT 830N/A * OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR 830N/A * HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL 830N/A * INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING 830N/A * FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, 830N/A * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION 830N/A * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. 830N/A * Except as contained in this notice, the name of a copyright holder 830N/A * shall not be used in advertising or otherwise to promote the sale, use 830N/A * or other dealings in this Software without prior written authorization 830N/A * of the copyright holder. 830N/A** Routines of the update phase that apply equally to both types of 830N/A** multibuffer set members, windows and multibuffers. 830N/A** The update phase entry routine for mbufset members. 830N/A** Called if the master change count of the shared info 830N/A** differs from the last recorded count in the client structure. 830N/A /* check the real change count that we saved away */ 830N/A /* establish the new real lock subject */ 830N/A /* save last lock subject. This may be used later in the update phase */ 830N/A /* start out assuming we're not aliased. This may change if we detect 830N/A aliasing later in the update phase */ 830N/A /* the first thing we do is distinguish between locking a window 830N/A and a multibuffer. The update logic is different */ 830N/A /* save the real change count */ 830N/A /* For the MT case, make sure that this update function gets called 830N/A * the next time around, so overwrite the change count to make it 830N/A** See if the shared info of the main window is still valid. 830N/A** Nonzero is returned if it is no longer valid and has become 830N/A** The way we deal with any composition change is to destroy the old 830N/A** multibuffer set and establish a new one. 830N/A /* check to see if this is an actual composition change or simply 830N/A /* no change -- must be only a display change */ 830N/A /* this is a real composition change. Destroy the old mbufset (if any) 830N/A and create a new one */ 830N/A /* remember whether window was previously multibuffered. This is 830N/A used later in the update phase to determine the reason for the 830N/A /* destroy the old one */ 830N/A /* TODO: really the only way we have of responding to this is treat 830N/A it as a zombie. It's not ideal, but what else can we do? */ 830N/A** If a render buffer notification function has been registered 830N/A** and the current effective lock subject differs from the current 830N/A** write buffer, call the notification function to change the render 830N/A /* has client registered the notification function? */ 830N/A /* we only need to notify in single-address access mode */ 830N/A * Only notify if rend buf is different from what we want it to be 830N/A * Note: we treat the write buffer index as the render buffer and ignore 830N/A * the read buffer index. 830N/A /* update the shared info so both the server and other clients can 830N/A see and react to the change */ 830N/A** A derivative change is one which is dependent on changes discovered 830N/A** earlier in the update phase (i.e. the basic changes). We determine here which ones need 830N/A** to be reported. Derivative changes may be reported along with 830N/A** the basic changes. The derivative changes in common for mbufset 830N/A** members are: site change. 830N/A /* report both a site change and a clip for zombies. This is simply 830N/A more insurance that the client will sync up with the null clip. */ 830N/A /* check for first time */ 830N/A /* check for cache change */ 830N/A /* check for alias change */ 830N/A /* check for mbufset composition change */ 830N/A** If we can report any changes through notification, do so now. 830N/A /* report any mbufset change */ 830N/A /* there are no notify functions for the following: 830N/A clip, cursor, bstore, cache */ 830N/A /* check for window devinfo change */ 830N/A /* check for nonviewable mbuf devinfo change */ 830N/A /* Note: viewable mbufs don't have dev info */ 830N/A /* client must find out through dga_draw_sitechg */ 830N/A /* figure out reason for change */ 830N/A /* this might happen if the mbufset was activated and then, in 830N/A the same update phase, deactivated. In this case, allow it, 830N/A but just don't report any changes */ 830N/A /* client must find out through dga_draw_mbchg */ 830N/A /* client must find out through dga_draw_sitechg */