MagiC
General remarks about shutdown
The task-manager of MagiC
MagiC follows the philosophy that speed should not be obtained by brutal means such as graphics processors etc., but rather by applying a bit of thought. Above all, this includes only ever doing as much as necessary. While TOS on changing the current window, or on closing or moving it, has a predilection of redrawing the whole window or even quite innocent, non-participating windows, MagiC effectively avoids doing this. Though this unattractive TOS behaviour is not documented anywhere, unfortunately programs and libraries exist (perhaps those from the book 'Vom Anfänger zum GEM-Profi'), which use the feature that TOS always redraws the window when enlarging it.
An example of this: Let us assume that five columns fit in a window next to each other, which are also displayed. If the user now reduces the window so that only four columns fit in it, the user program re- sorts its data and subsequently itself causes a redraw of the window (since TOS does not redraw a window when it is reduced). On the other hand if the user enlarges the window to 7 columns wide, the program again re-sorts the data, but in this case does not cause a redraw of the window. Due to this behaviour, which should really be described as a failure of TOS to always completely redraw the window in this case, output will then take place.
MagiC now always redraws only the minimum required part of the window; when enlarging a window, that would be at most two rectangles at the right and bottom. For the programs that make use of the error in TOS described above, there will be a discrepancy between the logical and physical screen contents.
It would have been far simpler to just forgo distinguishing the case 'window larger or smaller than before' and always cause a redraw when re-sorting. As, even in TOS, the operating system always aggregates redraws, a possibly superfluous redraw never has any repercussions.
Incidentally, the described effect arises also when enlarging the window if the lowest line or rightmost column is displayed.
Here too an example: A 100-line text is displayed in a window with a height of 20 lines; as the scroll-bar is right at the bottom, lines 80 to 100 will be displayed in the window. If the window is now enlarged downwards so that there is room for around 30 lines, then one could actually only drag out a white area, since there are no further data below line 100. To avoid this, most programs scroll their data in this situation, in our example 10 lines upwards. As a result the program now displays the lines 70 to 100; but as this is based on a TOS error, it does not cause a redraw, which of course readily leads to confusion under MagiC.
Here too a general redraw of the window during re-sorting under TOS as well would not only be clean but also have no side-effects, as TOS too avoids unnecessary redraws in this case. In a direct comparison between 'Smart redraw' and 'TOS redraw', which are to be seen literally as opposites, the former shows itself to have appreciably faster, calmer and cleaner screen build-up that can compete favourably with the Macintosh system and which would not be possible in this form under TOS even with a blitter and 68040 processor. Therefore it is strongly recommended that you do not ruin this elegant solution by taking advantage of undocumented properties of TOS.
If you are using programs that exhibit the faulty behaviour described above, then you should proceed as follows:
See also: Switch Smart redraw on/off GEM Style guidelines
MagiC
General remarks about shutdown
The task-manager of MagiC