1. Suggestion for syntax-colored editors
I see syntax-coloring being used in MEditor, and in the IDE, and probably also
in other apps. I have a little suggestion.
Blitting bitmaps is faster than drawing text. Why not generate a large bitmap
and draw all the standard keywords in their appropriate color on this bitmap, and
then if you need to draw such a keyword, just blit it from the bitmap to the
editor? Wouldn't this make the syntax coloring faster?
--
tommy online: http://users.pandora.be/tommycarlier
2. Re: Suggestion for syntax-colored editors
On Tue, 18 May 2004 04:23:11 -0700, Tommy Carlier
<guest at RapidEuphoria.com> wrote:
>
>
>posted by: Tommy Carlier <tommy.carlier at pandora.be>
>
>I see syntax-coloring being used in MEditor, and in the IDE, and probably also
>in other apps. I have a little suggestion.
>
>Blitting bitmaps is faster than drawing text. Why not generate a large bitmap
>and draw all the standard keywords in their appropriate color on this bitmap, and
>then if you need to draw such a keyword, just blit it from the bitmap to the
>editor? Wouldn't this make the syntax coloring faster?
I pass. Post a demo which proves it faster. 
)
Maybe then I'll believe you.
I took on Mike's editor and have done very little with the core
innards, such as display, concentrated more on up-front additions.
To draw this to its logical conclusion, you need a bitmap for every
character in every colour, along with the several (standard keywords)
you mention side-by-side in one block, plus what next?- one for every
variable name in the current source perhaps?
MEditor is open source; feel free to modify it and just send the whole
kit and cabooble back; I'll sort it out no worries.
Yours, Still Somewhat Unconvinced,
Pete
3. Re: Suggestion for syntax-colored editors
Pete Lomax wrote:
>
> On Tue, 18 May 2004 04:23:11 -0700, Tommy Carlier
> <guest at RapidEuphoria.com> wrote:
>
> >
> >posted by: Tommy Carlier <tommy.carlier at pandora.be>
> >
> >I see syntax-coloring being used in MEditor, and in the IDE, and probably
> >also in
> other apps. I have a little suggestion.
> >
> >Blitting bitmaps is faster than drawing text. Why not generate a large bitmap
> >and
> draw all the standard keywords in their appropriate color on this bitmap, and
> then
> if you need to draw such a keyword, just blit it from the bitmap to the
> editor? Wouldn't
> this make the syntax coloring faster?
>
> I pass. Post a demo which proves it faster. )
> Maybe then I'll believe you.
It certainly is faster and it reduces flickering on slower machines. Have a
look at ex12.exw in the win32lib demo folder.
> I took on Mike's editor and have done very little with the core
> innards, such as display, concentrated more on up-front additions.
>
> To draw this to its logical conclusion, you need a bitmap for every
> character in every colour, along with the several (standard keywords)
> you mention side-by-side in one block, plus what next?- one for every
> variable name in the current source perhaps?
No you don't. You can use wPuts() and drawText() etc... on bitmaps (Pixmap)
just the same as on a Window. The thing is it draws all this text and
lines into RAM without rendering it on the display. When the RAM
image of a display is ready you can call repaintFG() of the display
window and its w32HPaint handler can call copyBlt() to blast it onto
the screen all at once. Very fast.
> MEditor is open source; feel free to modify it and just send the whole
> kit and cabooble back; I'll sort it out no worries.
If only I had time
--
Derek Parnell
Melbourne, Australia
4. Re: Suggestion for syntax-colored editors
Pete Lomax wrote:
> I pass. Post a demo which proves it faster. )
> Maybe then I'll believe you.
>
> I took on Mike's editor and have done very little with the core
> innards, such as display, concentrated more on up-front additions.
>
> To draw this to its logical conclusion, you need a bitmap for every
> character in every colour, along with the several (standard keywords)
> you mention side-by-side in one block, plus what next?- one for every
> variable name in the current source perhaps?
No, you don't. You just use bitmaps for the standard keywords. When rendering
the text, you use the traditional method of drawing text for all the normal text
(variables, comments, strings, ...), and only blit bitmaps for the standard
keywords. This way, you also have to switch text-color ( = create a new
Pen/Brush) a lot less.
>
> MEditor is open source; feel free to modify it and just send the whole
> kit and cabooble back; I'll sort it out no worries.
>
> Yours, Still Somewhat Unconvinced,
> Pete
--
tommy online: http://users.pandora.be/tommycarlier
5. Re: Suggestion for syntax-colored editors
On 19 May 2004, at 1:48, Tommy Carlier wrote:
>
>
> posted by: Tommy Carlier <tommy.carlier at pandora.be>
>
> Pete Lomax wrote:
> > I pass. Post a demo which proves it faster. )
> > Maybe then I'll believe you.
> >
> > I took on Mike's editor and have done very little with the core
> > innards, such as display, concentrated more on up-front additions.
> >
> > To draw this to its logical conclusion, you need a bitmap for every
> > character in every colour, along with the several (standard keywords)
> > you mention side-by-side in one block, plus what next?- one for every
> > variable name in the current source perhaps?
>
> No, you don't. You just use bitmaps for the standard keywords. When rendering
> the text, you use the traditional method of drawing text for all the normal
> text
> (variables, comments, strings, ...), and only blit bitmaps for the standard
> keywords. This way, you also have to switch text-color ( = create a new
> Pen/Brush) a lot less.
then you cannot copy/paste the text, because it's text + pictures.
Kat
6. Re: Suggestion for syntax-colored editors
Kat wrote:
> > No, you don't. You just use bitmaps for the standard keywords. When
> > rendering
> > the text, you use the traditional method of drawing text for all the normal
> > text
> > (variables, comments, strings, ...), and only blit bitmaps for the standard
> > keywords. This way, you also have to switch text-color ( = create a new
> > Pen/Brush) a lot less.
>
> then you cannot copy/paste the text, because it's text + pictures.
Like the editors (IDE/MEditor) are now, there is no text either: the visual part
of the editor is just a Pixmap. The actual text-data is in an underlying
sequence. This sequence is used to copy/paste the text. This underlying text
doesn't change with the new mechanism: it's just the method of RENDERING the text
that changes.
--
tommy online: http://users.pandora.be/tommycarlier
7. Re: Suggestion for syntax-colored editors
- Posted by Nickofurr at aol.com
May 20, 2004
-------------------------------1085087718
In a message dated 5/20/2004 3:46:42 AM Eastern Standard Time,
guest at RapidEuphoria.com writes:
Kat wrote:
> > No, you don't. You just use bitmaps for the standard keywords. When
rendering
> > the text, you use the traditional method of drawing text for all the
normal text
> > (variables, comments, strings, ...), and only blit bitmaps for the
standard
> > keywords. This way, you also have to switch text-color ( = create a new
> > Pen/Brush) a lot less.
>
> then you cannot copy/paste the text, because it's text + pictures.
Like the editors (IDE/MEditor) are now, there is no text either: the visual
part of the editor is just a Pixmap. The actual text-data is in an underlying
sequence. This sequence is used to copy/paste the text. This underlying text
doesn't change with the new mechanism: it's just the method of RENDERING the
text that changes.
You know, he is right. The same idea is used in LangWar, that comes with
Euphoria. It might be because LW is Graphics-based, but so is 'graphics.e',
which you must use to have color at all. However, the setback is it would take
slightly longer to load, and Mouse support would take a lot more code,
especailly on WIN32.
<HTML><HEAD>
<META charset=US-ASCII http-equiv=Content-Type content="text/html;
charset=US-ASCII">
<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY style="FONT-SIZE: 12pt; FONT-FAMILY: Arial; BACKGROUND-COLOR: #ff0000">
<DIV>
<DIV>In a message dated 5/20/2004 3:46:42 AM Eastern Standard Time, guest at
RapidEuphoria.com writes:</DIV>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: blue 2px
solid"><FONT face=Arial>posted by: Tommy Carlier <tommy.carlier at
pandora.be><BR><BR>Kat wrote:<BR>> > No, you don't. You just use bitmaps
for the standard keywords. When rendering<BR>> > the text, you use the
traditional method of drawing text for all the normal text<BR>> >
(variables, comments, strings, ...), and only blit bitmaps for the
standard<BR>> > keywords. This way, you also have to switch text-color ( =
create a new<BR>> > Pen/Brush) a lot less.<BR>> <BR>> then you cannot
copy/paste the text, because it's text + pictures.<BR><BR>Like the editors
(IDE/MEditor) are now, there is no text either: the visual part of the editor is
just a Pixmap. The actual text-data is in an underlying sequence. This sequence
is used to copy/paste the text. This underlying text doesn't change with the new
mechanism: it's just the method of RENDERING the text that
changes.</FONT></BLOCKQUOTE></DIV>
<DIV><FONT style="BACKGROUND-COLOR: #ff8040" face="Times New Roman"
color=#ffff00>You know, he is right. The same idea is used in LangWar, that
comes with Euphoria. It might be because LW is Graphics-based, but so is
'graphics.e', which you must use to have color at all. However,
the setback is it would take slightly longer to load, and Mouse support would
take a lot more code, especailly on WIN32.</FONT></DIV></BODY></HTML>
