DIRECTORY SF USING [Box, maxBox], Xl USING [Connection, nullWindow, Point, Window], XlBitmap USING [Bitmap]; XlBitmapWindow: CEDAR DEFINITIONS ~ BEGIN Handle: TYPE = REF HandleRep; HandleRep: TYPE = RECORD [impl: PRIVATE REF ImplRep]; ImplRep: TYPE; CreateHandle: PROC [] RETURNS [handle: Handle]; DestroyHandle: PROC [handle: Handle, destroyWindow: BOOL ¬ FALSE]; SetBitmap: PROC [handle: Handle, bitmap: XlBitmap.Bitmap, restrict: SF.Box ¬ SF.maxBox, origin: Xl.Point ¬ [0, 0], immediateRefresh: BOOL ¬ TRUE, retainRefreshs: BOOL ¬ FALSE]; SetWindow: PROC [handle: Handle, c: Xl.Connection ¬ NIL, w: Xl.Window ¬ Xl.nullWindow, immediateRefresh: BOOL ¬ TRUE, retainRefreshs: BOOL ¬ FALSE]; SetNoWindow: PROC [handle: Handle]; CancelRefreshs: PROC [handle: Handle]; Wait: PROC [handle: Handle, server: BOOL ¬ FALSE]; FlushSoon: PROC [handle: Handle]; RegisterReportRefreshs: PRIVATE PROC [handle: Handle, proc: PROC[SF.Box, REF], data: REF]; END. ΊXlBitmapWindow.mesa Copyright Σ 1988, 1989, 1990, 1991 by Xerox Corporation. All rights reserved. Created by Christian Jacobi, April 5, 1988 1:32:31 pm PDT Christian Jacobi, August 28, 1991 2:58 pm PDT Package which supports implementation of bitmap backed windows. For drawing, clients simply draw into a bitmap. Clients do not have to worry about locking or performance requirements of paint procedures to windows. Should any drawing procedure block, this may cause its particular windows not to display the requested drawing, but has no other consequences to any other window or the screen management. Clients get to know changes to the window by one of two means: 1) Clients do the changes themself. 2) Clients can get told by the X event mechanism. Window changes may happen completely asynchrounosly with any drawing. The client can allocate a new bitmap for backing the viewer's content and request this package to take notice of the new bitmap. Once a client hands over a bitmap to a bitmap window, the client must not change the structure of the bitmap anymore [size, bits per pixel, location of bitmap in memory...]. The client may however at all times change the bits without any synchronization. This package itself will never change neither bits nor structure of any bitmap handed to it. Creates a handle, does neither "set" the window nor the bitmap. Shuts down activities on handle Forces handle to display a new bitmap. Returns immediately, maybe before bits are painted. Positions origin of bitmap at position "origin" of window. Directs refreshs into window w. Returns immediately, maybe before bits are painted Assumes bitGravity = northWest w must not be destroyed until SetNoWindow is called and returned. Refreshs are not retained Cancels refresh requests queued but not yet sent to X server. Waits until all requests are "performed" server: TRUE: waits until server acknowledges having seen requests server: FALSE: waits until requests are removed from internal buffer Speed hack Registers callback procedure to be called each time when bits are moved to the server Parameters are rectangle painted and data passed through Called inside local locks and without catch phrase Κ@–(cedarcode) style•NewlineDelimiter ˜™Icodešœ ΟeœC™NKšœ6Οk™9K™-—šž ˜ Kšžœžœ˜Kšœžœ)˜1Kšœ žœ ˜—K˜KšΟnœžœž ˜!šœž˜K˜™—K™—K™βK™K™έK˜šœžœžœ ˜Kš œ žœžœžœžœ ˜5Kšœ žœ˜—K˜šŸ œžœžœ˜/K™@K˜—šŸ œžœ!žœžœ˜BK™ K˜—šŸ œžœ5žœžœ6žœžœžœžœ˜°K™]K™