•  Back 
  •  %I 
  •  Index 
  •  Tree View 
  •  Cross references 
  •  %Hilfe 
  •  Show info about hypertext 
  •  View a new file 
Topic       : Documentation for Thing
Author      : Arno Welzel/Thomas Binder/TransAction
Version     : thing.hyp 1.27E (23/8/1998)
Subject     : Documentation/Shells
Nodes       : 269
Index Size  : 6336
HCP-Version : 4
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : %I
@help       : %Hilfe
@options    : +g -i -s +y +zz -t4 -d10
@width      : 75
@hostname   : THING   
View Ref-FileFAQ - Why does Thing need so much memory?                             Thing

Q: Why does Thing need so much memory?

A: Thing currently requires around 700-750Kb main memory if you're using 
   the standard colour icons supplied. Some users may find this rather 
   high -- after all Thing doesn't include an integrated command shell 
   like Gemini and no|Desk. It's even worse with colour modes with 265 or 
   more colours -- one can soon reach the 1MB limit!

   If memory is an issue look carefully at your icon usage and adjust your 
   ICONS.RSC to suit.
 
   The main factor responsible for high memory usage are the colour icons.
   Depending on the resolution Thing reserves up to 3Kb buffer space per 
   icon, which is needed to provide device-independent bitmaps (simple 
   calculation: 32*32*24/8=3072 bytes for each 32*32 pixel icon at 24 bit 
   per pixel resolution).

   To save memory one can also use the monochrome icons from MONOICON.RSC, 
   which must be renamed to ICONS.RSC, or create your own mono-only 
   ICONS.RSC and use that instead.

   A further reason for the high memory usage is the newly added complete 
   3D-look. This has been urgently requested by the majority of users, so 
   one has to bite the sour apple and accept the 'side-effects'.
 
   And one more reason: A lot of the program coding in Thing is not 
   optimised  -- several routines appear repeatedly in slightly different 
   forms. Although I try to improve this little by little, it can't always 
   be done without a lot of effort. Thus for example there are separate 
   routines for Drag&Drop of desktop, directory and group objects, 
   although they are very similar to each other and in principle could be 
   lumped together. Unfortunately this would require much effort with a 
   high risk for errors, so that I haven't been willing to take this on so 
   far. Incidentally this is also the reason why Thing today still does 
   not offer 'spring folders', which in my arrogance I really wanted to 
   build in immediately after taking charge of the sources from Arno...