Optimized Window Refreshing - Revision history

Costel Mincea: Text replacement - "" to ""

2025-01-26T19:04:39Z

Text replacement - "<syntaxhighlight>" to "<syntaxhighlight lang="C" line>"

← Older revision		Revision as of 19:04, 26 January 2025
Line 307:		Line 307:
	the following:		the following:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct RastPort dataRP;		struct RastPort dataRP;
	struct RastPort clrRP;		struct RastPort clrRP;
Line 463:		Line 463:
	= Optimrefresh.c =		= Optimrefresh.c =

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	;/* Optimrefresh.c - Execute me to compile me with SAS/C 6.56		;/* Optimrefresh.c - Execute me to compile me with SAS/C 6.56
	sc NMINC STRMERGE STREQ MCCONS COMNEST UNSCHAR NOSTKCHK SAVEDS IGNORE=73 optimrefresh.c		sc NMINC STRMERGE STREQ MCCONS COMNEST UNSCHAR NOSTKCHK SAVEDS IGNORE=73 optimrefresh.c

Steven Solie at 18:22, 19 June 2013

2013-06-19T18:22:57Z

← Older revision		Revision as of 18:22, 19 June 2013
Line 586:		Line 586:
	PGA_Top, 0,		PGA_Top, 0,
	PGA_NewLook, TRUE,		PGA_NewLook, TRUE,
	~~TAG_DONE~~))		TAG_END))
	{		{
	/* initialize data used by the backfill hook */		/* initialize data used by the backfill hook */
Line 616:		Line 616:
	\| IDCMP_VANILLAKEY,		\| IDCMP_VANILLAKEY,
	WA_BackFill, &refreshHook,		WA_BackFill, &refreshHook,
	~~TAG_DONE~~))		TAG_END))
	{		{
	/* initialize our document structure */		/* initialize our document structure */
Line 753:		Line 753:
	PGA_Total, numLines,		PGA_Total, numLines,
	PGA_Top, topLine,		PGA_Top, topLine,
	~~TAG_DONE~~);		TAG_END);
	}		}

Steven Solie: /* Refreshing a Sizable Window */

2013-06-05T17:19:59Z

Refreshing a Sizable Window

← Older revision		Revision as of 17:19, 5 June 2013
Line 366:		Line 366:
	applications suffer from this problem.		applications suffer from this problem.

			The second problem occurs when the application is waiting for input from Intuition, such as in the middle of an EasyRequest() call. If the user clicks on the sizing gadget of the application's window while the requester is up, the system will enter a deadlock. When the user clicks the sizing gadget, Intuition sends the IDCMP_SIZEVERIFY message and waits for a reply. Because the application is already waiting for the EasyRequest() to return, the application cannot send back the reply. Many applications suffer from this problem.
	The second problem occurs when the application is waiting for input
	from Intuition, such as in the middle of an EasyRequest() call. If
	the user clicks on the sizing gadget of the application's window
	while the requester is up, the system will enter a deadlock. When
	the user clicks the sizing gadget, Intuition sends the
	IDCMP_SIZEVERIFY message and waits for a reply. Because the
	application is already waiting for the EasyRequest() to return, the
	application cannot send back the reply. Many applications suffer
	from this problem.

			Intuition avoids these deadlocks. Intuition will time out the sizing operation if the application does not process the IDCMP_SIZEVERIFY message within a given time period. Although the user can no longer deadlock the system, this situation
	As of Release 2, Intuition has adapted and avoids these deadlocks.
			can still confuse the user because clicking on the window's sizing gadget no longer sizes the window. That does not mean an application should rely upon Intuition to avoid the deadlock. An application should always avoid these conditions.
	Intuition will time out the sizing operation if the application does
	not process the IDCMP_SIZEVERIFY message within a given time period.
	Although the user can no longer deadlock the system, this situation
	can still confuse the user because clicking on the window's sizing
	gadget no longer sizes the window. That does not mean an application
	should rely upon Intuition to avoid the deadlock. An application
	should always avoid these conditions.

	In general, it is simpler and safer for the application to lock a		In general, it is simpler and safer for the application to lock a

Steven Solie: /* Backfill Hook */

2013-06-05T17:18:34Z

Backfill Hook

← Older revision		Revision as of 17:18, 5 June 2013
Line 439:		Line 439:
	damaged regions. This is what layer backfill hooks are for.		damaged regions. This is what layer backfill hooks are for.

			A backfill hook is a custom function that an application attaches to a specific layer. Whenever damage occurs to a layer, the Layers library calls that layer's custom backfill hook. The Layers library passes the position and dimensions of the damage area to the backfill hook. The backfill hook can render into the damage area, refreshing it. Theoretically, the backfill hook can redraw a layer's damaged regions instead of clearing the damage area to color 0.
	Backfill hooks are a new Layers library feature added in Release 2.
	A backfill hook is a custom function that an application attaches to
	a specific layer. Whenever damage occurs to a layer, the Layers
	library calls that layer's custom backfill hook. The Layers library
	passes the position and dimensions of the damage area to the backfill
	hook. The backfill hook can render into the damage area, refreshing
	it. Theoretically, the backfill hook can redraw a layer's damaged
	regions instead of clearing the damage area to color 0.

	Unfortunately, refreshing a layer from a backfill hook can be quite		Unfortunately, refreshing a layer from a backfill hook can be quite

Steven Solie: /* Scrolling Your Life Away */

2013-06-05T17:17:51Z

Scrolling Your Life Away

← Older revision		Revision as of 17:17, 5 June 2013
Line 233:		Line 233:
	layer's damage region. If the layer already has damage when an		layer's damage region. If the layer already has damage when an
	application calls ScrollRaster(), the position of the damage region		application calls ScrollRaster(), the position of the damage region
	will move along with the data in the layer. ~~Note that prior to~~		will move along with the data in the layer.
	Release 2, ScrollRaster() did not scroll the layer's damage list.

	= Faster Rendering =		= Faster Rendering =

Steven Solie: /* Backfill Hook */

2013-06-05T17:13:25Z

Backfill Hook

Show changes

Steven Solie: /* BeginRefresh() and EndRefresh() */

2013-06-05T17:12:42Z

BeginRefresh() and EndRefresh()

← Older revision		Revision as of 17:12, 5 June 2013
Line 430:		Line 430:
	TRUE. See the Autodoc for BeginRefresh() and EndRefresh() for more		TRUE. See the Autodoc for BeginRefresh() and EndRefresh() for more
	information.		information.

			= Backfill Hook =

			Whenever a layer sustains damage, the damaged region is cleared to
			color 0. Clearing the region requires an often lengthy Blitter
			operation which is unnecessary if the application plans to redraw the
			damaged region anyway. Such an application can improve its
			performance by preventing the Layers library from clearing the
			damaged regions. This is what layer backfill hooks are for.

			Backfill hooks are a new Layers library feature added in Release 2.
			A backfill hook is a custom function that an application attaches to
			a specific layer. Whenever damage occurs to a layer, the Layers
			library calls that layer's custom backfill hook. The Layers library
			passes the position and dimensions of the damage area to the backfill
			hook. The backfill hook can render into the damage area, refreshing
			it. Theoretically, the backfill hook can redraw a layer's damaged
			regions instead of clearing the damage area to color 0.

			Unfortunately, refreshing a layer from a backfill hook can be quite
			difficult. The backfill hook code is usually called from a different
			task than the main application. If the backfill hook and the
			application do not properly arbitrate access to the application's
			data, dangerous race conditions can occur if the hook and the
			application try to access the same data. Another problem with
			rendering through the backfill hook is that no clipping is available.
			The backfill hook must do its own clipping to ensure that no
			rendering goes outside the dimensions specified when the hook is
			called, which in itself can be quite difficult.

			For many situations, the best use of a backfill hook is to have it do
			nothing. Whenever the hook is called, it simply returns without
			doing any rendering. This has the effect of eliminating the extra
			blit done to clear the damage region to color 0. This can speed
			layer operations quite a bit.

			There is one problem with a no-op backfill hook. If the application
			is busy doing some processing and damage occurs to its layer, the
			display will remain dirty until the application finishes its
			processing and notices that the layer is damaged. This damage can
			include remnants of system imagery, like window borders, which can
			confuse the user.

			One way to overcome this problem is to use a backfill hook that
			changes its behavior depending on the state of the application. If
			the application is not too busy to notice damage to its window's
			layer, the backfill hook does not erase the display. However, if the
			application is too busy to refresh its damaged window, the backfill
			hook clears the damaged portion of the display. Using this method,
			the backfill hook will not waste time erasing the damage when the
			application will update it immediately, but the backfill hook will
			erase the damage if the application can't refresh for a while.

Steven Solie: /* Refreshing a Sizable Window */

2013-06-05T17:12:13Z

Refreshing a Sizable Window

← Older revision		Revision as of 17:12, 5 June 2013
Line 402:		Line 402:
	RefreshGList()) and other locks (i.e., LockIBase() and		RefreshGList()) and other locks (i.e., LockIBase() and
	LockLayerInfo()).		LockLayerInfo()).

			= BeginRefresh() and EndRefresh() =

			To improve the performance of repairing damage to simple and smart
			refresh windows, Intuition can put a window into a special refresh
			state using Intuition's BeginRefresh() function:

			VOID BeginRefresh(struct Window *window)

			While a window is in this state, the system restricts attempts to
			render into the window to the window's damaged regions. Because the
			system ignores rendering operations outside the window's damage
			regions, an application only refreshes the parts of a window that
			need refreshing. This can significant decrease the amount of time
			necessary to refresh the window. This also reduces the possibility
			of visual flicker that can happen if an application has to redraw the
			entire contents of a window.

			To end a window's special refresh state, use EndRefresh():

			VOID EndRefresh(struct Window *window, BOOL Complete)

			Compared to BeginRefresh(), EndRefresh() has an extra parameter, a
			boolean value. If this value is TRUE, Intuition assumes that all of
			the refreshing for this window is finished and removes all of the
			window layer's damaged regions. In most cases, this value should be
			TRUE. See the Autodoc for BeginRefresh() and EndRefresh() for more
			information.

Steven Solie: /* Using Multiple RastPorts */

2013-06-05T17:11:32Z

Using Multiple RastPorts

← Older revision		Revision as of 17:11, 5 June 2013
Line 325:		Line 325:
	IGraphics->RectFill(&clrRPort,0,0,10,10);		IGraphics->RectFill(&clrRPort,0,0,10,10);
	</syntaxhighlight>		</syntaxhighlight>

			= Refreshing a Sizable Window =

			A sizable window is by far the trickiest to refresh correctly. The
			most important and often overlooked point is that an application
			needs to ensure the size of its window does not change while it is
			refreshing the window. If the application doesn't and the user
			changes the window size, the application will refresh the window at
			the window's old size rather than its new size. This can severely
			corrupt the appearance of the window.

			There are two main ways an application can keep the size of its
			window stable while refreshing the window. The first method is to
			keep the size of the window locked most of the time, unlocking the
			window only when the user tries to size the window. The other
			approach is to lock the window size only while rendering to the
			window.

			The first method is part of Intuition's IDCMP mechanism. To lock a
			window's size, an application sets the window's IDCMP_SIZEVERIFY
			IDCMP flag. When the user attempts to size the window by clicking on
			the window's sizing gadget, Intuition notifies the application by
			sending an IDCMP_SIZEVERIFY message to the window's IDCMP port.
			Intuition will keep the window's size locked until the application
			returns the IDCMP_SIZEVERIFY message.

			In general this scheme works well, but it does have two problems.
			First, if the application is busy doing some processing, such as
			recalculating a spreadsheet, it may not notice that the message
			arrived until it is done with its current processing. The result is
			the user will not be able to size the window until the application is
			finished processing, which might more time than the user wants.

			The second problem occurs when the application is waiting for input
			from Intuition, such as in the middle of an EasyRequest() call. If
			the user clicks on the sizing gadget of the application's window
			while the requester is up, Intuition will wait for the system will
			enter a deadlock. Intuition will wait for the application to send
			back will not see the IDCMP_SIZEVERIFY event until the user satisfies
			the EasyRequest(). The result will be a system deadlock. Many
			applications suffer from this problem.

			The second problem occurs when the application is waiting for input
			from Intuition, such as in the middle of an EasyRequest() call. If
			the user clicks on the sizing gadget of the application's window
			while the requester is up, the system will enter a deadlock. When
			the user clicks the sizing gadget, Intuition sends the
			IDCMP_SIZEVERIFY message and waits for a reply. Because the
			application is already waiting for the EasyRequest() to return, the
			application cannot send back the reply. Many applications suffer
			from this problem.

			As of Release 2, Intuition has adapted and avoids these deadlocks.
			Intuition will time out the sizing operation if the application does
			not process the IDCMP_SIZEVERIFY message within a given time period.
			Although the user can no longer deadlock the system, this situation
			can still confuse the user because clicking on the window's sizing
			gadget no longer sizes the window. That does not mean an application
			should rely upon Intuition to avoid the deadlock. An application
			should always avoid these conditions.

			In general, it is simpler and safer for the application to lock a
			window only during the rendering process. The application can do
			this by surrounding all rendering operations with calls to the Layers
			library functions LockLayer() and UnlockLayer(). LockLayer() locks
			the size and position of a layer. While a window's layer is locked,
			an application can safely look at the window's current size and
			render to it without any danger of the size changing. Once the
			application finishes rendering, it unlocks the window's layer by
			calling UnlockLayer(). When using this method, an application must
			not set the window's IDCMP_SIZEVERIFY bit. Be careful which system
			functions an application calls while it has a layer locked. Only use
			the Graphics library rendering functions and the simple Intuition
			rendering functions (i.e., PrintIText(), DrawImage(), etc.). In
			particular, avoid calls that deal with gadgets (including
			RefreshGList()) and other locks (i.e., LockIBase() and
			LockLayerInfo()).

Steven Solie: /* Faster Rendering */

2013-06-05T17:10:54Z

Faster Rendering

← Older revision		Revision as of 17:10, 5 June 2013
Line 284:		Line 284:
	ScrollRaster() doesn't move data on the display, it still needs to go		ScrollRaster() doesn't move data on the display, it still needs to go
	through all the layer's clipping regions, which can be time consuming.		through all the layer's clipping regions, which can be time consuming.

			= Using Multiple RastPorts =

			A RastPort specifies attributes needed to perform many rendering
			operations. These include the RastPort's foreground, background, and
			drawing mode. The Graphics library functions SetAPen(), SetBPen(),
			and SetDrMd() set each of these attributes, respectively.

			Although these functions appear to have fairly simple purposes in
			life, the SetAPen(), SetBPen(), and SetDrMd() are quite CPU intensive
			routines. These functions require recalculating values that the OS
			caches in private parts of the RastPort. If an application only
			requires a few different combinations of foreground/background/draw
			mode, it can improve its performance by using a different RastPort
			structure for each combination. An application sets the attributes
			of several RastPorts only once which is generally more efficient that
			setting the attributes of one RastPort every time the rendering
			attributes change.

			Assume an application has a window in which it renders all of its
			data in pen 1, and clears any part of its display using color 0.
			Such an application can improve its rendering performance by doing
			the following:

			<syntaxhighlight>
			struct RastPort dataRP;
			struct RastPort clrRP;

			dataRP = *window->RPort;
			IGraphics->SetAPen(&dataRP,1);
			IGraphics->SetBPen(&dataRP,0);

			clrRP = *window->RPort;
			IGraphics->SetAPen(&clrRP,0);

			/* renders to the window's RastPort in color 1 */
			IGraphics->Text(&dataRP,"hello",5);

			/* clears a section of the window's RastPort in color 0 */
			IGraphics->RectFill(&clrRPort,0,0,10,10);
			</syntaxhighlight>