[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: svgalib problems
- Subject: RE: svgalib problems
- Date: Mon, 6 Jan 2003 15:19:44 +0100
> To get svgalib to work on new hardware is indeed becoming a
> problem. I had
> to install an old video card to be able to use linrad recently. Even with
> an older card, to get things working reminded me of the old days when I
> had to configure X by brute force trial and error. Svgalib may become an
> obstacle for new users with new hardware.
> I'm not sure what would be involved, but it may be wise to prepare a
> migration path to some newer graphics API. Alternatives are X, SDL, Mesa,
> etc. X has its own overhead, but new API wrappers like Qt and GTK make
> things much, much easier. SDL and Mesa seems to be gaining popularity,
> specially among gamers and video players where frame rate performance is
> important. If the performance demands aren't that high, Qt or GTK may be
> a good compromise.
It would solve many problems but it is above what I can manage myself.
It seems to me the new APIs require some programming skills that I do not
have and that would be extremely difficult to accuire at my age.
I can do conceptually simple things like coding assembly to use the
smart multimedia instructions well even if it leads to complicated code.
I can not do conceptually difficult things like understanding C++ and
its generalised objects(???) even if it probably leads to simple code.
The thing is I am not a programmer. I work with computers like I work
with the soldering iron and the oscilloscope and spectrum analyzer.
Adding components one by one while constantly watching the resulting
waveforms and spectra.
> I have mentioned this before, but in order to simplify things in the long
> term, may be Linrad could become a headless application. The user
> interface would be an independent application communicating via some IPC.
I have no idea about the implications of this. I do not even know what
IPC stands for. I tried to read a little about SDL, Mesa and GTK.
> This would, probably, be a major software development project, but I
> believe Linrad deserves it. Another positive side effect is that Lief
> could focus on the Linrad DSP code get help from other programmers on user
> interface issues.
If it can be done - and if someone wants to assist - it would surely
make my life easier!
The speed of the graphics is very critical though. Not for weak
signal reception but Linrad has many other applications. High
speed waterfall graphs may be very interesting for example. svgalib
is not quite fast enough on my system and something that has a lot
more overhead is not attractive.
The oscilloscope function must be used with individual pixels
on my system, drawing lines between the pixels takes too much
time even with svgalib.
Maybe Linrad could have its own screen image, a memory area
where I can set pixels rapidly. Then some different application
would be responsible for fetching the entire data area something
like 10 times each second. 1024 * 768 * 8 * 10 = 63 megabit
per second. In case it is done with dma on some bus that is
not much used, it might not cause any problems at all to Linrad.
I am totally ignorant here but it seems to me the modern PC
has several busses(??)
Help and suggestions (that I have a chance to understand)
will be much appreciated.
Leif / SM5BSZ