🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.windows.x
Article #23917

Re: graphicsexpose handling

#23917
From: Paul Asente
Date: Thu, 20 Jun 1991 18:45
54 lines
3162 bytes
In article <25529@well.sf.ca.us> jef@well.sf.ca.us (Jef Poskanzer) writes:

	[about problems with GraphicsExpose events]

Handling GraphicsExpose events correctly is a little complex.  When you do a
CopyArea, put the change that you made into a list.  When you get a
GraphicsExpose, look at the entire list to figure out where the area you're
exposing has been moved to.  When you get a GraphicsExpose with count 0 or a
NoExpose, you can remove the oldest list entry.

Example:
	Do a CopyArea that moves everything up 10; put (10, 0) in the list.
	Do a CopyArea that moves everything up 20; add (20, 0) to the list.
	Do a CopyArea that moves everything 30 to the right; add (0, 30) to
		the list.
	Get a GraphicsExpose with count 0 indicating that bottom 10 pixels
		of your window need redisplay.  Skip the first list entry,
		add the remaining ones to discover that you need to offset the
		area in the expose event by (20, 30) to get its current
		position.   Remove the (10, 0) from the list since you got an
		event with count 0.
	Etc.

>Does anyone know what I'm talking about?  I looked inside Xt and it's
>doing something weird with expose events, but I'm not sure whether it's
>to solve this problem or just an optimization or something else.

You have 2 options with Xt.  One is not to specify XtExposeGraphicsExpose in
your compress_exposure field and to specify translations for GraphicsExpose
and NoExpose in your translations.  This means your action procedures will
get all the GraphicsExpose and NoExpose events and can handle them as above.
You might want to use XtAddExposureToRegion to do your own exposure
compression.

The other option is to specify XtExposeGraphicsExpose in the
compress_exposure field.  In this case GraphicsExpose events will be
dispatched to your expose procedure.  If you want exposure compression, use
XtExposeCompressSeries; using XtExposeCompressMultiple or
XtExposeCompressMaximal will prevent you from seeing all the count=0 events
and from keeping your list up to date.  Also, do not use
XtExposeGraphicsExposeMerged since that will merge GraphicsExpose and regular
Expose events, again preventing you from seeing all count=0 events.  You
probably also want to specify XtExposeNoExpose so that NoExpose events also
go to your expose procedure and you can handle all the list updating in one
place.  If you don't specify XtExposeNoExpose you need a translation for
NoExpose as above.

	-paul asente
		asente@adobe.com	...decwrl!adobe!asente

    Ratz put a bucket of liquid in front of me.
   "I wanted a glass of docs, Ratz.  What the hell is this?" I barked.
   "Motif don't fit in a glass anymore," he barked back.
    I looked at the liquid.  It was totally opaque to me.
Technical Details
Message-ID: <16726@adobe.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!adobe!asente
References: <25529@well.sf.ca.us>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!adobe!asente
From: asente@adobe.com (Paul Asente)
Newsgroups: comp.windows.x
Subject: Re: graphicsexpose handling
Message-ID: <16726@adobe.UUCP>
Date: 20 Jun 91 18:45:48 GMT
References: <25529@well.sf.ca.us>
Sender: news@adobe.COM
Organization: Adobe Systems Inc.
Lines: 54