mbuf_update.c revision 919
/* 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, sublicense,
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* 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. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
* DEALINGS IN THE SOFTWARE.
*/
/*
**
** Routines of the update phase for multibuffers.
*/
#include <assert.h>
#ifdef SERVER_DGA
#endif /* SERVER_DGA */
#include "dga_incls.h"
#include "pix_grab.h"
#include "mbufsetstr.h"
/*
** 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.
**
** site
** clip
** curs
** bstore
** 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
*/
int
{
/*
* 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
** process over.
*/
/* Determine sequence counts for state reported to client */
/* start accumulating changes */
dgawin->changeMask = 0;
do {
/* first, see if the window shared info is still valid */
if (dgai_mbsmemb_syncZombie(dgawin)) {
break;
}
/* 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 */
} else {
/* should never happen */
assert(0);
}
/* 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,
** if possible.
*/
/* 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
shared info */
/* 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 */
return (dgawin->changeMask);
}
static void
{
} else {
}
}
/*
** Returns nonzero if we are still not synchronized
*/
static int
{
/* if a multibuffer change happened, we're still not done */
return (1);
}
return (0);
}
/* Note: viewable mbuf never has bstore to sync up to */
return (0);
}
/* 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
when we get here */
return (0);
}
/* we're now all synchronized */
return (1);
}
/*
** 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.
*/
static void
{
/* 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 */
return;
}
/* synchronize with any display buffer change */
/* synchronize render buffer state (if necessary) */
} else {
/* The window is no longer multibuffered. This multibuffer is a zombie */
return;
}
/* an mbufset change causes us to report changes to all attrs */
} else {
}
}
}
/*
** Determine effective lock subject for a multibuffered window.
*/
static void
{
/* 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.
*/
static void
{
int curViewable;
int prevViewable;
/* common changes */
/*
** 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.
*/
if ((curViewable && !prevViewable) ||
(!curViewable && prevViewable)) {
}
}
/*
** Current lock subject is a viewable multibuffer. Synchronize with changes.
*/
void
{
/* Note: viewable multibuffers share the clip and cursor state
of the main window */
/* 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.
*/
void
{
/* don't try to synchronize if multibuffer is a zombie */
return;
}
/* first, see if the shared info is still valid */
return;
}
/* 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? */
}
void
{
/* synchronize change counts */
}
}
void
{
/* synchronize change counts */
}
}