[linrad] Re: Windows graphics

[<leif@xxxxxxxxxx>]

> >No, I do not see any reason. Anyone capable of getting Linux
> >running should also be capable of installing svgalib.....
> >
> >
> I was not referring to SVGALIB, I was saying that programming a
> graphical user interface for an application program under XWindows of
> Linux, or under Micro$oft Windows has the same level of complexity.
> Linux is not simpler.
Sorry, I have a very narrow focus and that is to make the functionality
of Linrad available to amateurs who do not want to install Linux.
I have no interest in the XWindows for the simple reason that
Linrad is easily available under Linux without XWindows.

Linux is much simpler than Windows because it has a terminal mode
with graphical support through svgalib.

> I was referring to a broader level of event-driveness (does such a word
> exist ?). Events are caused not only by the logic of your application,
> they can come also from the operating system in an unexpected way. If
> you want to produce an application really integrated with the opsys
> (Linux or Windows), you must be prepared to the fact that the opsys
> opens another window above yours, masking part of it.
I can not se how that changes anything. The problem is the obscenly slow
SetPixel function into a memory buffer.

> When that window
> is closed by the opsys, it simply asks you to refresh that portion of
> your window that has been corrupted by the foreign window. And you must
> be prepared to cope with such a request, which can arrive at
> unpredictable times.
Sure. The correct data is present in the memory bitmap at all times
so it is trivial to update the screen whenever a request arrives.

> This logic is the same under Linux or Windows, both have the same model.
> A possible way out would be to code what in Windows parlance is called a
> console application, and there you can use a simple graphical library,
> like what I suggested you in the past, the WinBGI.
OK. This is exactly what I am trying to do. I was unable to make WinBGI
work under mingw32 and therefore I have written such a library myself.
WinBGI uses SetPixel so it is no better than the code I have up and
running now.


> Then your Windows
> application would be conceptually similar to Linrad. In Linrad you don't
> use the native graphical subsystem of Linux, XWindows, but you use
> SVGALIB, which is meant to work outside XWindows. In Windows you would
> be using WinBGI, which bears the same relationship to Windows as SVGALIB
> to Linux. It's just a matter of choice.
No, svgalib is extremely fast, WinBGI is extremely slow. That is the problem.
The Linrad code is identical under Linux and Windows with the exception
for a few os-related calls. Keyboard, text on screen, semaphores, and timers
work fine. I have not looked into sound devices yet but I can not imagine
they would present any problem. Currently I see only one problem: The
absolutely absurd slowness of SetPixel.


73

Leif  /  SM5BSZ




#############################################################
This message is sent to you because you are subscribed to
  the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>


LINRADDARNIL