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
>
|
Not Categorized, Please Help
|
|
