| Why do I have to drink a cup of tea when working with BareED? Or - in other words: why is BareED so slow, especially when operating with text highlighting applications? |
Let it explain me. A normal AmigaDOS-text editor can only operate on mono-spaced fonts (fixed in width). This, as a consequence, means, that all entered characters (letters) have the same width (in pixels); hence: Hello world! ...is a string with 12 characters. Using mono-spaced fonts you only need to multiply the amount of characters with the width of some character - in order to get the width of the string. Using non-mono-spaced fonts means: adding the individual width of each (used) character - in order to get the width of this string; here 12 additional additions would be required, but no multiplying. Because somewhere these widths are noted down, several operations have to be performed before you can find out the width of an individual character. Thus, it results again in a speed loss. Because BareED doesn't make use of special characters - surrounded in the normal text - or is otherwise restricted, all information are accumulated in real time. This, as consequence, has got the benefit that the file in memory matches exactly that one on disk, which could be used by third-party softwares in order to compile or assemble this text directly from BareED's text buffer. Unfortunately, this has the big disadvantage that no strings can be shown in a different colour - using escape sequences - for example. Because I wanted BareED to show strings in different colours, a mechanism was introduced to allow third-party applications operate up-on already by BareED shown strings. This was realized via the DAC-port of BareED - which is an interface between BareED and normal AmigaDOS applications. |
| There are three disadvantages that I want to mention here: |
Since BareED has already rendered the strings onto the display, you operate up-on already drawn strings - with the bad side effect, that several strings are rendered twice onto the display; once more, a speed loss. Because BareED shares with other components (DAC-applications) the display - and more important, those functions to render strings, a locking technique had to be introduced to guarantee exclusive use of these functions (either BareED or a DAC-application) in order to avoid corrupt displayed strings. For example, while BareED scrolls the display, DAC-applications may in no way render strings at the same time! In other words, while BareED performs some action, no DAC-application can use functions of BareED, which are responsible to show strings! But because BareED does not wait for DAC-applications to complete their task, colour faults may occur as well. For example, your DAC-application is drawing all lines in the display, starting with line 1. Your DAC-application has reached the middle of the display and suddenly BareED is forced to scroll the page (shame on user...). Since only these functions that are directly involved in rendering the strings are protected by the locking-mechanism - and your code computes a hash-value (which isn't protected), BareED grants BareED grand access and hence BareED scrolls the page. Hence, your code will render into the wrong page - starting at the middle of the new page... Of course, as soon as you request a new PageUpdateMsg you'll receive the indicator for a new page - and thus the entire page is rendered once more - and correctly, but the wrong rendered strings are not erased out of the display!!! In my opinion it's a good idea to surround your code by a pair of BlockInput / AllowInput, which ignores for the time your code is busy, any user action, and thus BareED... Unfortunately, it may happen then that BareED misses a release of the left or middle mouse button while it is blocked. Another (and in my opinion the best) solution can be the use of a double buffered message system - but this is discussed later in the function-section, because you need then the needed background information. Last but not least: In order to avoid string comparing at byte level (character by character) BareED offers you functions that can be used as alternatives. It's a simple, but effective and accurate 32-bit hash-algorithm (FNV-1). It's one of the fastest I've ever seen - but it requires anyway some CPU resources. It's of course a lot faster than comparing strings byte by byte, but it takes its time. So, to find an end, it's not as fast as directly poking the colour value for a string right in front of this string. Once more, BareED performs all actions in real time, it doesn't make use of help-variables or other stuff. To be said: BareED was not written for slow CPUs - for those, use instead one of the other text editors that can only deal with fixed-width fonts. |
By the way, BareED was entirely written in standard C - with only a minimum of a68k assembler code (less than 20 lines). Anyone who wants to port BareED to AROS? All texts and errors written 02/25/04 J.v.d.Loo |