acmfiu@serss0.fiu.edu (ACMFIU) (02/14/91)
what's the fastest way to update a window. actually, all i want to do is scroll it x number of lines. it just seems too slow at present. i use ScrollRect to do it. I heard from someone before that i could create a rectangle off the screen and copy it there, scroll it, then copy it back. that seems like too much work, though, just for a simple scroll. i could understand if you needed to update more things in your window, though. albert
bazyar@ernie (Jawaid Bazyar) (02/14/91)
In article <2445@kluge.fiu.edu> acmfiu@serss0.fiu.edu (ACMFIU) writes: >what's the fastest way to update a window. actually, all i want to do >is scroll it x number of lines. it just seems too slow at present. i use >ScrollRect to do it. I heard from someone before that i could create a >rectangle off the screen and copy it there, scroll it, then copy it back. >that seems like too much work, though, just for a simple scroll. i could >understand if you needed to update more things in your window, though. Something that will help will be to make sure SHR shadowing is on. This is done thru setting the "FastPort aware" bit in the QDStartUp call. -- Jawaid Bazyar | "I'm sure K&R have never heard of Mike." Senior/Computer Engineering | bazyar@cs.uiuc.edu | "That's okay. I'm sure Mike's never heard of K&R". Apple II Forever! | (discussion about Orca/C)
mdavis@pro-sol.cts.com (Morgan Davis) (02/15/91)
In-Reply-To: message from acmfiu@serss0.fiu.edu The fastest way to scroll a window is to calculate the actual video RAM locations for its content, and then use a fast 65816 routine to do the pixel shifting on your own, preferably by using a table of offsets, or even faster, by generating code at runtime that moves pixels in an unrolled loop of load-store instructions. Takes up a bit of RAM, but can result in blindingly fast scrolls, albeit against the rules. UUCP: crash!pro-sol!mdavis AOL, BIX: mdavis ARPA: crash!pro-sol!mdavis@nosc.mil GEnie: m.davis42 INET: mdavis@pro-sol.cts.com ProLine: mdavis@pro-sol
gwyn@smoke.brl.mil (Doug Gwyn) (02/16/91)
In article <7566@crash.cts.com> mdavis@pro-sol.cts.com (Morgan Davis) writes: >The fastest way to scroll a window is to calculate the actual video RAM >locations for its content, and then use a fast 65816 routine to do the >pixel shifting on your own, preferably by using a table of offsets, or even >faster, by generating code at runtime that moves pixels in an unrolled loop >of load-store instructions. Takes up a bit of RAM, but can result in >blindingly fast scrolls, albeit against the rules. This is basically the technique that the developers of AT&T's "Blit" terminal ended up using to implement the fundamental operation "bitblit". (The processor was an MC68000 but the principles were the same.) Details were published in some issue of Software - Practice and Experience, if I recall correctly.
bazyar@ernie (Jawaid Bazyar) (02/16/91)
In article <7566@crash.cts.com> mdavis@pro-sol.cts.com (Morgan Davis) writes: >In-Reply-To: message from acmfiu@serss0.fiu.edu > >The fastest way to scroll a window is to calculate the actual video RAM >locations for its content, and then use a fast 65816 routine to do the >pixel shifting on your own, preferably by using a table of offsets, or even >faster, by generating code at runtime that moves pixels in an unrolled loop >of load-store instructions. Takes up a bit of RAM, but can result in >blindingly fast scrolls, albeit against the rules. It's VERY against the rules. I recommend to anyone out there writing GS software to go by the book. I heard a rumor (from a very reliable source) that someone is making a VGA quality graphics board for the GS. Doing anything against the rules (i.e. not using QuickDraw for everything) will, guaranteed, make your program incompatible with this board. (This isn't the TurboRez, this is a new attempt by different people). -- Jawaid Bazyar | "I'm sure K&R have never heard of Mike." Senior/Computer Engineering | bazyar@cs.uiuc.edu | "That's okay. I'm sure Mike's never heard of K&R". Apple II Forever! | (discussion about Orca/C)
gwyn@smoke.brl.mil (Doug Gwyn) (02/16/91)
In article <1991Feb15.212254.10659@ux1.cso.uiuc.edu> bazyar@cs.uiuc.edu (Jawaid Bazyar) writes: >Doing anything against the rules (i.e. not using QuickDraw for everything) >will, guaranteed, make your program incompatible with this board. And having your application run too slow may make it unusable too. The tradeoffs have to be carefully considered. While I'm a big fan of portability, that is just one aspect of whether or not software meets certain general goals. The other aspects are important too.
MQUINN@UTCVM.BITNET (02/16/91)
On Sat, 16 Feb 91 05:17:29 GMT Doug Gwyn said: >In article <1991Feb15.212254.10659@ux1.cso.uiuc.edu> bazyar@cs.uiuc.edu (Jawaid > Bazyar) writes: >>Doing anything against the rules (i.e. not using QuickDraw for everything) >>will, guaranteed, make your program incompatible with this board. > >And having your application run too slow may make it unusable too. >The tradeoffs have to be carefully considered. While I'm a big fan >of portability, that is just one aspect of whether or not software >meets certain general goals. The other aspects are important too. Here's something I've thought of doing before: Have an option in the Application called FAST/RELIABLE or something to that affect. What it would do is switch between using fast, unreliable, technieques to using routines that follow the rules that would be more reliable. Then, people that have a graphics board could use the GS's native mode for speed or the graphics board for higher resolution & colors. And, of course, tell the user of the advantages and dissadvantages of both modes and when and when not to use them. Would that be practical or not? ---------------------------------------- Michael J. Quinn University of Tennessee at Chattanooga BITNET-- mquinn@utcvm pro-line-- mquinn@pro-gsplus.cts.com