1. Possible offensive msg
I know people are going to be upset at this
(I am) but why don't we just write a gui in
<gasp> C </gasp>, compile it, and call it from Euphoria?
Should be fast enough that way...
Irv
2. Re: Possible offensive msg
Irv wrote:
> I know people are going to be upset at this
> (I am) but why don't we just write a gui in
> <gasp> C </gasp>, compile it, and call it
> from Euphoria?
It's been done - something called Windows. 
How are we going to link the library from DOS? As far as I know, Pete's
version of Euphoria is not yet ready for prime time.
Finally, the speed of code written in Euphoria shouldn't be that bad - as
long as it's fairly carefully coded.
-- David Cuny
3. Re: Possible offensive msg
Irv Mullins writes:
> I know people are going to be upset at this
> (I am) but why don't we just write a gui in
> <gasp> C </gasp>, compile it, and call it
> from Euphoria?
I did some profiling recently using WATCOM's C profiling tool.
I was interested to know where the time goes when Euphoria
writes pixels in mode 18 (16 color VGA 640x480). (Pentium-150,
S3 video card)
I found that when you call Euphoria's pixel() routine to write
a single pixel, 80% of the time is spent in WATCOM's
library routine, and only 20% is spent in the Euphoria
interpreter setting up the call.
When you write a 200-pixel sequence, 75% is spent in
WATCOM's routine, and 25% is spent in the Euphoria
interpreter. (By the way, I was able to optimize this 25%
down to about 22%). In 256-color modes the Euphoria
overhead is even less.
My point is: Even if you rewrote your Euphoria code in
WATCOM C, you would only be able to reduce the
20 to 25% portion. You'd still be stuck with the 75 to 80%
portion that WATCOM's routine requires. Your C program
would *not* run that much faster than your Euphoria program.
As for Windows, most Windows programs spend most
of their time inside WIN32 API calls, popping up new windows,
dialogs etc.. It won't matter much if they are programmed
in a language somewhat slower than compiled C, if
(say) 80% of their time is spent inside Windows itself.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
4. Re: Possible offensive msg
- Posted by Adam Weeden <SkaMan325 at AOL.COM>
Nov 17, 1998
-
Last edited Nov 18, 1998
As much of a last resort this is I tend to agree. (Although that's probably
cause I'm still more knowledgeable with C than Euphoria, but that's besides
the point.
Adam Weeden
5. Re: Possible offensive msg
>
>As for Windows, most Windows programs spend most
>of their time inside WIN32 API calls, popping up new windows,
>dialogs etc.. It won't matter much if they are programmed
>in a language somewhat slower than compiled C, if
>(say) 80% of their time is spent inside Windows itself.
>
Which is why Visual Basic ( oops, a nughty word :-] ) is actually quite
fast as long as it's not doing difficult processing when not sitting
there waiting for an I/O event. All the hard stuff, text box
editing/scrolling etc etc is handled by Windows.
6. Re: Possible offensive msg
On Wed, 18 Nov 1998 10:16:27 -0000, Bown, John <John.Bown at UK.ORIGIN-IT.COM>
wrote:
>>
>>As for Windows, most Windows programs spend most
>>of their time inside WIN32 API calls, popping up new windows,
>>dialogs etc.. It won't matter much if they are programmed
>>in a language somewhat slower than compiled C, if
>>(say) 80% of their time is spent inside Windows itself.
>>
>Which is why Visual Basic ( oops, a nughty word :-] ) is actually quite
>fast as long as it's not doing difficult processing when not sitting
>there waiting for an I/O event. All the hard stuff, text box
>editing/scrolling etc etc is handled by Windows.
Thanks: this in a way clarifies my point:
If graphics, specifically user-interface graphics, can be fast
when run by basic / windows, why cannot DOS graphics - again,
user-interface graphics - running on the "bare metal", be at
least as fast? Windows is not known for being a fine example
of lean, clean coding, is it?
So, what do we have to do to build a fast gui "include"?
Regards,
Irv
7. Re: Possible offensive msg
>
>From: Irv Mullins[SMTP:irv at ELLIJAY.COM]
>
>Thanks: this in a way clarifies my point:
>If graphics, specifically user-interface graphics, can be fast
>when run by basic / windows, why cannot DOS graphics - again,
>user-interface graphics - running on the "bare metal", be at
>least as fast? Windows is not known for being a fine example
>of lean, clean coding, is it?
Not necessarily a 100% true statement; yes Windows is bloated, no you
can't get a Microsoft app installed without 10Mb of garbage and a lot of
apps are clunky and slow but ...
The graphics engines do seem [ to me ] to be incredibly well optimised
and exceedingly fast; visions of hordes of anorak clad programmers
beavering away on a Bit-Blat routine in a dark basement spring to mind -
Microsoft have those sort of resources. Of course the *universal*
graphics engine that works in all modes is probably exceedingly bloated
because it has been fine tuned to every known graphics mode - luckily
it's all split up into several .DLL's and .DRV's.
The conclusion is; yes MS-DOS graphics can be as fast and possibly
faster than windows but it needs a lot of effort putting in.
8. Re: Possible offensive msg
On Wed, 18 Nov 1998 15:44:47 -0000, Bown, John <John.Bown at UK.ORIGIN-IT.COM>
wrote:
>>
>>From: Irv Mullins[SMTP:irv at ELLIJAY.COM]
>>
>>Thanks: this in a way clarifies my point:
>>If graphics, specifically user-interface graphics, can be fast
>>when run by basic / windows, why cannot DOS graphics - again,
>>user-interface graphics - running on the "bare metal", be at
>>least as fast? Windows is not known for being a fine example
>>of lean, clean coding, is it?
>
>Not necessarily a 100% true statement; yes Windows is bloated, no you
>can't get a Microsoft app installed without 10Mb of garbage and a lot of
>apps are clunky and slow but ...
>
>The graphics engines do seem [ to me ] to be incredibly well optimised
>and exceedingly fast; visions of hordes of anorak clad programmers
>beavering away on a Bit-Blat routine in a dark basement spring to mind -
...
>The conclusion is; yes MS-DOS graphics can be as fast and possibly
>faster than windows but it needs a lot of effort putting in.
Now we're getting somewhere. Does that mean that there are no fast
packages available with - for example Watcom, or Borland C++, or
whatever? Packages that we could buy/steal/use or just learn from?
Irv
9. Re: Possible offensive msg
Irv wondered:
> Windows is not known for being a fine example
> of lean, clean coding, is it?
From what I've read, Windows gets a lot of hard-wired support from video
cards specifically designed to speed *Windows* BitBlt operations. If it
wasn't for that, the graphics would be slow as mud.
-- David Cuny
10. Re: Possible offensive msg
On Wed, 18 Nov 1998 09:36:44 -0800, Cuny, David <David.Cuny at DSS.CA.GOV>
wrote:
>Irv wondered:
>
>> Windows is not known for being a fine example
>> of lean, clean coding, is it?
>
>From what I've read, Windows gets a lot of hard-wired support from video
>cards specifically designed to speed *Windows* BitBlt operations. If it
>wasn't for that, the graphics would be slow as mud.
>
I think I have read something to that effect also.
However, how to use that support can't be too much of a secret:
Linux graphic apps seem to run as fast/faster than Windows
on the same machine. So - as they say on the X-Files
"the truth is out there".
Irv
