1. Bug in ed
I posted a message a while ago about programs that do nothing at all. People
suggested that I had forgotten to call my main routine and to try with trace.
I had already checked both of these and I later found out when browsing that
the culprit file had size 0 bytes. This added to the commotion, and I
eventually dismissed it as one of those "strange" things and thought it must
have been me fiddling with ed.ex. A couple of months later, I had the same
problem. This time I had an unbutchered ed.ex and I opened my "saved" file in
another window. Empty. I tried several times and ed ensured me the file had
saved OK, but it was clearly empty. When I ran a dos prompt I discovered that
my floppy disk was full. Apparently ed does not account for this.
I have just started investigation dcuny's textgui editor. It runs horribly
slowly on my 386, unlike ed which might as well be compiled it is so quick. I
noticed that ee redraws the entire text screen every time you go down a line.
This leads me to two possible conclusions :
1. David has not had time to optimise it yet
or
2. Euphoria needs built-in text/graphics scrolling routines.
By (2) I mean that rather than redrawing every line, you say scroll(whatever)
and then print out the new line/pixels. If a screen is vector drawn then this
means only the new area has to be redrawn in Euphoria code which should give a
significant speed gain..
What do you all think ?
Daniel
2. Re: Bug in ed
Daniel writes:
> I have just started investigation dcuny's textgui editor. It runs
> horribly slowly on my 386, unlike ed which might as well
> be compiled it is so quick. I noticed that ee redraws the
> entire text screen every time you go down a line.
> This leads me to two possible conclusions :
> 1. David has not had time to optimise it yet
> or
> 2. Euphoria needs built-in text/graphics scrolling routines.
> By (2) I mean that rather than redrawing every line, you say
> scroll (whatever)
> and then print out the new line/pixels. If a screen is vector drawn
> then this
> means only the new area has to be redrawn in Euphoria code
> which should give a significant speed gain..
See scroll() in library.doc.
ed.ex uses scroll() when it has to shift the
text on the screen up or down a line. It can then
display just one new line of text at the top or bottom of
the screen using puts().
scroll() works in text or graphics modes.
David Cuny's editor is quite fast on my 486. It can
keep up with the repeat rate of my keyboard while
scrolling up or down. I hope you aren't running his
editor in graphics mode.
Regards,
Rob Craig
Rapid Deployment Software
3. Re: Bug in ed
Euphoria does not need specific routines for something like this, the
built-in can be used quite fast, when used right.
But who in earth is trying to optimize a program when it runs at such speed
on his computer (like on mine) that you cann't even time most routines. His
Editor runs like super-fast, althrough when I am a t the menus, and hold
left or right, I do not see all menus, due to speed (and pictures frames
sticking in your eyes).
The MS_Dos editor does do this at such speed that you see all menus.
But honiestly, updating the whole screen, is bad-programming. If you were
looking at it from the graphics development side.
He could use GFX for this also. (text-screens and text-modes are supported!)
Only sprites will look very weird, cause the color of the first pixel (of
every set of 2) will set the character that is used at that position, at the
second of the set of 2, should have the attribute.
The attribute can be a value between 0 and 255, and as I believe holds the
color values for that character.
But I am not sure about this.
If things get screwed up, you can still use the VS_TYPE_IMAGE, which works
with a two-dimensional sequence.
That would speed it up, but not that much, I think.
It was optimized on my P60 8-)
And there the rule that more code doesn't have to be slower than code
definately exists.
And I think, this rule doesn't work on the slower machines.
Example: Claming to Micheal Packards results it is very slow on his 486.
But to some1 else (sorry forgot your name 8-( ) it goes like a blazzerd on
his P200.
And to Graphics Mode editing, well, the problem is most graphics library
(read: new asm-optimized libraries) don't like other modes than MCGA.
My GFX routines just call the normal built-in routine, so althrough their
interface do all the stuff very efficient, the speed of the drawing routines
of Euphoria are just two slow.
I believe Pete Eberlein is working on a SVGA-library, but I am not sure...
It should be as fast as it could get, unless some1 comes up with a better
technique then command lists.
Ralf
>Daniel writes:
>
>> I have just started investigation dcuny's textgui editor. It runs
>> horribly slowly on my 386, unlike ed which might as well
>> be compiled it is so quick. I noticed that ee redraws the
>> entire text screen every time you go down a line.
>> This leads me to two possible conclusions :
>> 1. David has not had time to optimise it yet
>> or
>> 2. Euphoria needs built-in text/graphics scrolling routines.
>> By (2) I mean that rather than redrawing every line, you say
>> scroll (whatever)
>> and then print out the new line/pixels. If a screen is vector drawn
>> then this
>> means only the new area has to be redrawn in Euphoria code
>> which should give a significant speed gain..
>
>See scroll() in library.doc.
>ed.ex uses scroll() when it has to shift the
>text on the screen up or down a line. It can then
>display just one new line of text at the top or bottom of
>the screen using puts().
>scroll() works in text or graphics modes.
>
>David Cuny's editor is quite fast on my 486. It can
>keep up with the repeat rate of my keyboard while
>scrolling up or down. I hope you aren't running his
>editor in graphics mode.
>
>Regards,
> Rob Craig
> Rapid Deployment Software
>
4. Re: Bug in ed
Hi, Daniel:
I wrote my editor on my 386sx, and attempted to optimize it for that
environment. It will run fairly quickly. However, there *are* some things
that slow it down:
1. Graphics mode. You should ONLY run the editor in text mode!
2. Syntax coloring. Turn it off for a signifigant speed increase.
3. Selecting regions.
The code in XLE.E handles Single Line Edits (SLEs) and Multiple Line Edits
(MLEs). The editor is basically one big MLE. Of all the controls, the MLE
is the most graphic intensive ('cos it writes multiple lines, duh). But it
*is* optimized for speed.
After handling an edit key, the following items are checked for changes:
- leftmost column has changed (full screen scrolled left or right)
- top line has changed (page has scrolled)
- local redraw flag has been set (internal to function)
- global redraw flag has been set (set by user)
In the case of any of these being true, the full screen will be redrawn.
The local redraw flag is typically triggered by an area being
selected/deselected. The logic with selected regions gets complex, and
often I'll just bail and refresh the whole screen. Even then, there are
some cases where you get this "leftover" selected text garbage on your
screen.
But most of the time, only the current line gets redrawn. For example,
moving the cursor one line at a time will *not* cause anything but the
current lines to be refreshed.
Scrolling up and down a single line is also optimized, with the routines
move_up() and move_down():
------------------------------------------------------------------------
-----
function move_down( sequence mle )
-- move down by one line
if mle[ITEM] < mle[DEEP] then
-- is there a line to scroll to?
if current_line( mle ) < length( mle[ITEMS] ) then
-- move to next line
mle[ITEM] = mle[ITEM] + 1
-- draw the line we moved from
draw_mle_item( mle, mle[ITEM] - 1 )
end if
else
-- can we scroll?
if mle[TOP_LINE]+mle[DEEP]-1 < length( mle[ITEMS] ) then
if VGA_MODE then
-- force redraw
mle[TOP_LINE] = mle[TOP_LINE] + 1
else
-- physical scroll
mle_scroll( mle, -1 )
-- adjust settings
mle[TOP_LINE] = mle[TOP_LINE] + 1
-- draw the line we moved from
draw_mle_item( mle, mle[ITEM] - 1 )
-- prevent redraw of screen
oldFirstLine = mle[TOP_LINE]
end if
end if
end if
-- return mle
return mle
end function
------------------------------------------------------------------------
-----
If the VGA-mode flag is not set (read: in text mode), the routine
mle_scroll() is used to draw the screen. mle_scroll() uses
save_clean_image() and display_clean_image(), which are defined in
TEXTMODE.E. These are low-level calls that turn the mouse off and on before
doing their work - somthing not needed anymore, now that I've seperated the
VGA and SVGA code into seperate modules.
As a side note, I initially tried using the Euphoria function scroll(), but
the way it handles the left- and right-most columns is funky (and
undocumented. mild grrrrr...).
You may have noticed that it's also slower than ed in loading files. That's
because it converts tabs into spaces, and strips off the line feed at the
end of the line.
So:
1. The editor code is optimized, but I'm sure it could be done better.
2. There is a built in scroll() routine in Euphoria, but you probably are
better off using save_text_image() and display_text_image() instead.
Hope this answered your questions!
-- David
5. Re: Bug in ed
David Cuny writes:
> You may have noticed that it's also slower than ed in
> loading files. That's because it converts tabs into spaces,
> and strips off the line feed at the end of the line.
I did a time profile on ee while it loaded a large file.
The profile indicated that printing the current number of lines
to the screen consumes about 30% of the
load time (counting all the statements involved in that process).
It's hard to measure exactly, because you have to
exit ee as soon as possible after loading the file,
which only takes a few seconds on my Pentium.
Converting the tabs and removing the \n only accounted
for 4%. ed also converts tabs (for .e and .ex files only).
int_to_bits() consumed a lot too, but I think
that's in the loop where ee waits for a key to be pressed,
so it doesn't matter.
Regards,
Rob Craig
Rapid Deployment Software
