[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::amiga_v1

Title:AMIGA NOTES
Notice:Join us in the *NEW* conference - HYDRA::AMIGA_V2
Moderator:HYDRA::MOORE
Created:Sat Apr 26 1986
Last Modified:Wed Feb 05 1992
Last Successful Update:Fri Jun 06 1997
Number of topics:5378
Total number of notes:38326

1783.0. "Slow Response" by HYSTER::DEARBORN (Trouvez Mieux) Mon Oct 17 1988 15:10

    Ever notice that the drop down menus are sluggish when the Amiga
    is running in Hi-Res?  I notice it when running Aegis Draw Plus
    and Professional Page.
                         
    Why is this?  I thought that the co-processors were intended to
    make things like this fast.  
                         
    I find it irritating.          
T.RTitleUserPersonal
Name
DateLines
1783.1Hi-res Blues...RAVEN1::EVERHARTMon Oct 17 1988 18:2515
    Yes, the co-processors DO make things like this fast.  After all,
    these babies are busy with the screen.  And menus just make the
    load harder.  In hi-res mode, the custom chips sometimes steal clock
    cycles from the 68000, which I'm pretty sure must have a hand in
    the menus.  Also, if the custom chips must steal clock cycles, they
    are VERY busy as it is, and menus are going to have to be slowed.
    Now, if you didn't have custom chips, the 68000 would be trying
    to do all of this.  Menus would be kind of like a C64 1541 disk
    drive.  I'd like to see the Mac do interlaced mode with fast menus.
    
     - Chris
    
    * Someone PLEASE correct me if I'm wrong.  I don't want to remain
    ignorant.
    
1783.2LEDS::ACCIARDIDukakis should pluck his eyebrowsMon Oct 17 1988 23:2139
    
    With a 640 x 400 16 color screen active, there is 4X as much video to
    be managed as a standard Workbench screen.  It therefore stands to
    reason that it will take 4X longer to move that stuff around. 
    
    Randy, I believe that you have a 1 meg A2000, no?  If so, you still
    don't have any 'real' expansion memory, which would speed things
    up noticeably.  Even though you have an extra 512K, that memory
    is still on the custom chip buss, where it contends with the processor
    for clock cycles.
    
    I may be imagining things, but I believe that my CMI 14.32MHz processor
    accelerator speeds up things like menus, windows etc.  This is because
    the board (supposedly) reads all the system graphic routines at
    the faster speed.  Then again, I have 2 megs of genuine expansion
    memory, and my hi-res screens always had excellent response.
    
    Relief can be had in several ways...
    
    1.  Wait for v 1.4 when all the ROM graphic routines get overhauled.
        (Assumes we're all still alive by then)
    
    2.  Buy some extra memory.
    
    3.  Buy a CMI processor accelerator ($170)
    
    4.  Buy a Hurricane or CSA or GVP 68020 accelerator $$$$$$$
    
    5.  Buy some Valium so that reality will appear to speed up with
        respect to your frame of reference.  :^)
        
    It's funny, but I noticed the same effect on my brother-in-law's
    $10,000+ Mac II system.  Apple increased the throughput of this
    beast by a factor of 4 over a Mac SE, then (with 640 x 480 x 256
    colors), increased the video overhead by a factor of 12!  The result
    is window response that is quite poor.  Of course, if you cut back
    to 16 colors, it moves pretty quickly.
    
    Ed. 
1783.3TLE::RMEYERSRandy MeyersMon Oct 17 1988 23:2222
Re: .0

One effect is that the speed that a menu is rendered is proportional to
the amount of screen memory that the blitter needs to move.

Thus, it takes the system twice as long to draw into a 640 x 200 x 4 bitplane
screen as it does to draw into a 640 x 200 x 2 bitplane screen.  Do the
programs you mentioned use a lot of different colors as well as high
resolution?

As .1 points out, certain graphics modes cause cycle stealing to occur.
This causes further slowdown.  Note that because the Amiga's 400 line
mode is interlaced, there is never more cycle stealing in 400 line mode
than in 200 line mode.  It is the number of bitplanes combined with the
horizontal resolution that causes cycle stealing.  The maximum cycle
sealing occurs in 640 pixel by 16 color mode.

A third possibility: A program can tell the system to ask for the program's
permission before the system displays menus for that program.  This allows
the program to make sure it is ready to process menu commands before it
receives them.  For example, Draw may want to finish drawing a part before
allowing you a crack at the menus.
1783.4It's those pesky bitplanesTLE::RMEYERSRandy MeyersMon Oct 17 1988 23:5521
Re: .2
    
>    With a 640 x 400 16 color screen active, there is 4X as much video to
>    be managed as a standard Workbench screen.  It therefore stands to
>    reason that it will take 4X longer to move that stuff around. 

It turns out that it only takes twice as long to render a menu into a
640 x 400 x 4 bitplane (16 colors) screen than a 640 x 200 x 2 bitplane
(4 color workbench-like screen).

The reason is that the resolution doesn't matter.  Program usually don't
scale the size in pixels of their menus to match the resolution of the
screen.  A program just says, I want a menu is a 64 pixel by 80 pixel
box.  Thus, a program's menus look bigger in a low res screen than in
a high res screen.  Those of you who use Deluxe Paint are use to seeing
the same menus looking huge in low res and small in high res.

However, the number of bit planes do affect the amount of memory that
needs to be blitted in displaying a menu.  All the "extra" bitplanes
need to be cleared when displaying the menu, and thus extra time is
taken.
1783.5WJG::GUINEAULost in the B-ZoneTue Oct 18 1988 08:117

The "Amiga System Programmers Guide", noted elsewhere in this conference,
has a good explination of this. It diagrams the cpu/blitter cycles ofer a scan
line time.

John
1783.6HYSTER::DEARBORNTrouvez MieuxTue Oct 18 1988 11:019
    Well, Professional Page is a Black and White display, with shades
    of gray.  Draw Plus is 16 color.
    
    The effect is seen when dragging the mouse across the pull down
    menus.  It acts sluggish.  I've never seen this happen on a MAC.
    And the MAC doesn't even have co-processors.
    
    Randy
    
1783.7SUBSYS::BUSCHDave Busch at NKS1-2Tue Oct 18 1988 13:275
When using D-Paint II I've noticed a considerable slowdown if I have MachII and 
VirusX running in the background. It takes forever for the program to sample 
where the mouse is to connect/draw lines.

Dave
1783.8RAVEN1::EVERHARTTue Oct 18 1988 17:5412
    re .6
    The MAC doesn't have color.  Each byte on a MAC can hold 8 pixels.
    In 16 color mode hi-res on the Amiga, each byte holds only 2 pixels.
    Therefore, the Amiga must process four times as much as the MAC.
    In addition, I believe the resolution on the MAC is less than 640
    x 400.  So, if the coprocessors only tripled the speed of graphics,
    you'd still get a slow down.  It would be interesting to see a MAC
    attempt such operations with color. (And I don't mean the cruddy
    dithered type)
    
     - Chris
    
1783.9Menus in a black and white Amiga screen are very fastTLE::RMEYERSRandy MeyersTue Oct 18 1988 18:1427
Re: .6

>    Well, Professional Page is a Black and White display, with shades
>    of gray.  Draw Plus is 16 color.

Each shade of gray counts as a color.  Determine the total number of
colors (or shades) that can be displayed.  Take the logarithm to base
2 of the number of colors.  That number is the "memory burden" of
drawing the menu.

The MAC (except for the MAX II) can only display two colors:  Black and
white, no shades of gray.  Its memory burden is 1.

The Amiga Workbench screen can display 4 colors.  Its memory burden is 2.

The Draw Plus screen displays 16 colors.  Its memory burden is 4.

Thus, the Amiga must do twice the amount of work to display an menu
in the Draw Plus screen than the Workbench screen.  The Amiga must do
four times the work to display a menu in the Draw Plus screen than in
a Mac-like two color screen.

>I've never seen this happen on a MAC. And the MAC doesn't even
>have co-processors.

It is also doing one-forth the work.  A color MAC SE, if Apple ever
produces such a beast, will draw menus much slower than an Amiga.
1783.10LEDS::ACCIARDIDukakis should pluck his eyebrowsTue Oct 18 1988 19:3721
    
    I suggest trying a Mac II with a 16 colors active and again with
    256 colors active.  In 16 color mode, it seems to display menus
    about as fast as an Amiga 4 color screen.  Moving a window seems
    slower.  Neither system moves the entire window contents, only it's
    outlines.
    
    When in 256 color mode, the entire system slows to a crawl.  I ran
    SuperPaint something-or-other with 8 bit color selected, and loaded
    up a gorgeous picture of a frog.  (It's amazing how many shades
    of green you can generate from a 16 million color pallette).
    
    When scrolling the screen (the bit map was actually 1024 x 860)
    the lag between input and response was several seconds.  Cutting
    a brush and dragging it felt like running through bearing grease
    on a cold day.
    
    The moral here is that lots of colors, regardless of the name on
    the box, will slow you down.
    
    Ed.
1783.11HYSTER::DEARBORNTrouvez MieuxWed Oct 19 1988 11:135
    I give up.  We have a MAC II with a 19 inch Color monitor running
    in 256 mode.  Seems pretty fast to me.  The drop down menus seem
    just as fast as a B+W machine.  As for scrolling around pictures
    and windows, that's another matter.
    
1783.12RAVEN1::EVERHARTWed Oct 19 1988 14:528
    Hmmmm.  Maybe we now know why Apple decided to wait until the MAC
    II came out before they put color in.  They were rumored to have
    developed a color system for the MAC +, but dropped the idea of
    marketing it because of some unknown problem.  Could that problem
    have been speed?
    
     - Chris
    
1783.13UPDATEHYSTER::DEARBORNTrouvez MieuxWed Oct 19 1988 15:527
    Professional Page has a true B+W mode.  I tried it.  Guess what?
    A significant speed up of the menus.
    
    Maybe you guys ARE right...
    
    Randy