Date: Thu, 2 Mar 2000 19:01:47 +0600 (LKT)
From: Kalum Somaratna aka Grendel <kalum AT crosswinds DOT net>
X-Sender: root AT darkstar DOT grendel DOT net
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: djgpp AT delorie DOT com
Subject: Re: Fastest bitblt?
In-Reply-To: <Pine.SUN.3.91.1000301120225.12637D-100000@is>
Message-ID: <Pine.LNX.4.10.10003021857320.652-100000@darkstar.grendel.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Wed, 1 Mar 2000, Eli Zaretskii wrote:

> 
> On Tue, 29 Feb 2000, Kalum Somaratna aka Grendel wrote:
> 
> > Well if you are so paranoid then enable nearptrs only before you execute
> > code that depends on it like blitting routines, and disable them
> > immediately afterwards. 
> 
> This would actually be a very bad idea: __djgpp_nearptr_enable invokes
> a costly DPMI call.  Calling it too frequently will completely destroy
> any hope for faster performance, which was the reason to use it in the
> first place.

I think you may have misunderstood me here Eli.

I was suggesting the above technique (enable nearptrs before the code that
requires it and disabling it afterwards) during the coding and beta
testing versions, which woould keep the memory protection intact in the
other (most) parts of the application. 

Once the debugging and testing is finished the nearptrs can be enabled
globally for the whole program, which would then avoid the problem you
mentioned above.

Grendel.

Hi, I'm a signature virus. plz set me as your signature and help me spread
:)