SciTech Software, Inc. announced it has released SciTech MGL 5.0 R10 for multiple operating systems including Linux, under a dual-license structure. Developers can now use SciTech MGL under the LGPL, or through SciTech’s commercial software license for those seeking to offer closed source solutions. Both versions come complete with source code and more than 1600 pages of online documentation. SciTech MGL comes with direct support for VGA, VESA VBE and DirectX compatible graphics cards out of the box via the SciTech SNAP Graphics device driver architecture.
X is really showing its age, any windows 3.0 and up cursors will beat X’s cunterpart
Ok, you’ve decided that X is now showing it age. Well, its nice to see you’ve volunteered to write a complete replacement for it, plus also volunteered to port all the applications from X to your “New Idea”(tm).
When should we expect to see a working replacement for X and the above? I don’t want to wait for ever. I want it done in 6months!
whine whine whine whine whine
There’s no such thing as free lunch – God
Tsk tsk. It was only an opinion, and I share exactly the same. X-Win is way too bulky and inconvenient for a desktop OS. Then again, it might be really difficult to make an alternative… but I believe we’ll have to if we want Linux, FreeBSD or any OSS project to compete against Microsoft and Apple
Typical response. You dare criticize open source software? It is your duty to quit your job, learn to program, and hack on it 23 hours a day until the application is up to par. Or in reality, use a program that doesn’t have said issues. Whatever.
“but I believe we’ll have to if we want Linux, FreeBSD or any OSS project to compete against Microsoft and Apple”
We seem to presently be doing well enough that Ballmer is cashing in his frequent flyer miles. Why “fix” what isn’t any more or less broke than anyone elses solution?
Got a problem with OpenSource? then grab your wallet and buy the bloody commercial solution that is apparently superior or would that actuallt require moving out of your parents basement, get a job and actually be responsible for something once in your misserable and pathetic little life.
OpenSource are started BY volunteers for people who WANT t use it. If you don’t bloody like it, tough titty. Grow some knackers and get over it. Until YOU can provide a solution that is superior to what is available, keep to the cheap seats.
RE: Wrawrat (IP: —.130-201-24.mtl.mc.videotron.ca)
No, it wasn’t an opinion, it was a piece of cheap rhetoric made by some little brat who thinks the whole world revolves around him and that all and sundry should be at his beckening call. Until this little brat pays for some programmers to make what HE wants, he should keep to what he does best, basically doing nothing and complaining about everything.
This has nothing to do with X. Read the article:
“…SciTech MGL is designed for applications written to run in a window on an existing graphical desktop, or in a simple full screen mode. The latest release of SciTech MGL includes full support for running in a window on the Windows platforms, and our developers are working to add this same flexibility for X11 on the Linux platform” said Kendall Bennett, CEO of SciTech Software.”
This is going to be an extension to X, not a complete replacement. It has nothing to do with whether or not X is viable.
-gc
why bother, I will use Windows as GUI and SSh to linux box for the shell part for some piping, samba mounting, etc.
If I feel Mardona is old, do I have to make her looks younger? If so, you tell me how, and I might or might not do it 8-)))))
To be fair, I DON’T want Linux/OSS to compete against anybody. I’m happy with a certain number of open standards, otherwise I don’t care who runs what.
To Anonymous: Win3.0 cursors could beat modern 4.3 X cursors? Guess what. The ones I use are translucent red with a drop shadow. Plenty advanced for me. Windows still does that half-ass.
Read the OSNews threads about the XFree fork a couple months back. They had much more interesting conversation than here, mostly because people suggested actual ideas rather than “X sux0r lets replace it.” I for one use the client-server X model all the time, for example to administer my headless box.
Like those people who really hate the filesystem layout of Linux and think it should be destroyed. Yah, then I would certainly move to FreeBSD or Minix or something, because there ARE reasons for it being this way that I use all the time.
Since Scitech employees read this so often, could you comment on why we would think of using this instead of X or DirectFB?
How do end users get the software to use apps written for MGL?
Can a runtime be included with the app?
How bad is the 3D support? It seems to be MESA only on Linux at the moment.
For small scale distribution, how much does it cost to include this in a distro?
Thanks,
Mutiny
“Typical response. You dare criticize open source software? It is your duty to quit your job, learn to program, and hack on it 23 hours a day until the application is up to par.”
Speaking of typical response. What he/she was getting at is that people argue from a weak position about X (usually because they don’t understand it). Then they suggest all this “work” (do you realize how much is REALLY involved in both a replacement AND getting people to convert?) that needs to be done to fulfil what they thing the OSS world needs.i.e beat Microsoft usually.
“Or in reality, use a program that doesn’t have said issues. Whatever.”
I recommend one of the commercial X servers and a light-weight Window manager.
Hmm, let’s see… To be better than their solutions?
“cheap rhetoric made by some little brat who thinks …”
zealots are pretty user firendly ????
“Removes Need for X on Linux” is part of the title
extension doesn’t remove the need for the base element.
Read the OSNews threads about the XFree fork a couple months back. They had much more interesting conversation than here, mostly because people suggested actual ideas rather than “X sux0r lets replace it.” I for one use the client-server X model all the time, for example to administer my headless box.
I didn’t read that thread, but IMO, the majority ain’t needing the client-server X model. They should make one version without it and one version with it at the loss of some features (like 3D acceleration and resolution change). I know that the lastest versions of XFree are incorporating those features even with the cli-srv model, but they don’t seem to be efficient (well, that’s what I think).
released SciTech MGL 5.0 R10 for multiple operating systems
the title pointed to one possibility:
Removes Need for X on Linux
If X is perfect, the above wouldn’t be a catchy sentence
What exactly is wrong with the X protocol? The only thing that I can think of is that I wish that there was more documentation available, especially related to building widgets with xlib.
“I didn’t read that thread, but IMO, the majority ain’t needing the client-server X model. ”
And this “majority” is?
Well, I agree with you. What someone suggested in that thread is that the client-server model be turned upside down, since the majority doesn’t use it. I.E, that the base be some sort of direct videocard interface, and that client-server be built on top more or less transparently (and optionally). That is something I would support; having a graphics subsystem use 8% of my CPU is ridiculous.
And people who needlessly use duplicate ? and ! taken seriously? when a person uses ??? and !!! the troll-o-metre on my desk spins around at 1000kilometres and hour.
If I want to re-enforce a fact I’ll either underline it, make it bold or use a duplicate of both. Sometimes use all caps can also be used for re-enforcement of key words.
Again, if you have a problem with X, provide a replacement. XFree86 is developed by volunteers. If you seem to have a problem, why don’t YOU volunteer like the XFree86 programmers and do something about it?
Well, in theory, one should not programme using xlib but instead using a higher abstraction such as a widget toolkit as provided by GTK+, Qt or Motif.
RE: Greg (IP: —.lsanca1.dsl-verizon.net)
There was a debate a while back related to pushing more of the processing from the server side onto the client. The rationale made by many of the XFree86/X developers was the fact that computers now are powerful enough to handle that sort of process load and there for, there is little reason for having the large amount of the processing done at the server end.
If this is how in the future they can improve the speed and realiability of XFree86, then I am all for it, however, what I don’t see as the solution is the radical, simplistic throwing the baby out with the bath water senario some people assuming would fix the problem.
one example:
you run a remote X session and a VNC session you will notice the difference.
latest genome etc uses alpha blending extensively, which requires an X server send back its bitmap back to X client for processing then the new bitmap is shown again on the X server’s display. This round trip processing would be very slow on a low bandwidth network link like a home DSL connection with the upload link typically limited to around 128kbps.
In the VNC session, the X server and X client are on the same remote computer and only processed bitmap was shown to the VNC client.
As another example, if the X server has limited features, like those latest extensions, most state of the art features in X is useless, like Render extension, Video extension etc.
Why would you use VNC? if you had some knowledge you’d pipe the bastard (X) through OpenSSH and use the compression to your advantage.
As for X extensions, what is wrong with XRender? Xft uses is quite nicely. If you want to bitch about performance, blame the video card companies who insist on being 007 secret squirl by not giving out the required specifications to write a stable and functional driver that can use all the extensions available on XFree86.
I’m a bit confused. Do you mean the traditional client-server model or the X server-client model? In this case the client would be the remote machine, not the local.
RE: Re: What’s wrong with X
X is known for its network transparency. Seems to work fine on my DSL line, much faster than VNC (especially if you use SSH w/compression to tunnel), plus remote programs can be shown side-by-side with local ones, while VNC has to render a whole desktop.
About majorities and Windows:
The majority:
– does not use the command line. Let’s remove it.
– does not use Wordpad. Let’s remove it.
– does not use Netscape. Let’s remove it.
– does not use the Management Console. Let’s remove it.
– does not use IIS. Let’s remove it.
– does not use Start-Help. Let’s remove it.
– does not use Help-About. Let’s remove it.
– does not read the license terms. Let’s remove them.
And what is the real problem with X? If I can use it very well on my P350, how can speed be a problem on all those modern computers which are five times faster?
Actually, I have used X on a 486/33, and with Fvwm95 it worked fine. I have also used X on a Pentium 100, and it was not the speed of X that was the problem, no, it was that the computer did not have enough memory to launch StarOffice or Netscape without swapping very much.
And to Greg: 8% for your X-server? How bad yours is! I know, quality of them differs. Mine uses about 0.5% CPU time, and uses 3 MB of memory. I know a friend, at whose computer X takes 30 MB.
However, there are some applications that do not behave correctly, mostly GV and KGhostView. They load the entire page into the X server to provide smooth scrolling, but when zooming in 20 times or so, this becomes a bit large… then my X-server also starts using 30 MB or more. If this would be solved, and transparency would be added, I see no real problems with X.
Different people have different preference in terms of emphasising a point
If I feel X is too broken, I can also use Windows for the fun GUI part.
Pointing out one of X’s weakness doesn’t mean I have no respect for their creators. If that were the case, I wouldn’t bother to criticize the slow progress in X development. And I hope most of us here know why there is an XFree86 fork.
More X-SERVER-side processing would also be nice, not more CLIENT(=application)-side. Sending a request to the server “Draw a button HERE” can go much faster by network than “Draw a line. Draw another line (…) Draw an anti-aliased line here. Fill it.”
I disagree. This would completely screw over the LTSP and dickless-workstation people, since they usually use 486s. If it’s to be X it can’t use much server-side processing.
I run a PC based X server on a dual monitor under windows
A KDE/Genome session of this X server claimed two monitors’ space, while with VNC, I can specify -geometry 960×720 to run the remote X desktop in a window.
The X’s way of client/server architecture means a weak server might not utilize client’s full potential
And I am not criticising you for having issues with X, however, I do take issues with those who have problems with something, yet, they do nothing about it and expect Joe and Jane Volunteer programmer to do all the heavy lifting.
RE: Greg (IP: —.lsanca1.dsl-verizon.net)
Right now we have a server-client model. Everything is rendered on the server and spat back to the client which then displays what it receives. Instead of the connection being over a network, it mearly works via localhost.
What I was saying is less should be done on the server side. Why not let the anti-aliasing be done by the client rather than the server? why not let the server spit the raw stuff to the client and then simply let he client add the nice things like anti-aliasing and alpha-blending on, using the clients processing. This should fix the speed up. This was the whole reason for dumping XFS (X Font Server) in favour of what we have today. Yes, some distros still load XFS, however, it is no longer necessary.
Well, VNC is intended for this (you could have set X to use a different resolution). Nothing’s stopping you from using both.
(it’s GNOME not genome–the GNU Network Object Model Environment)
Greg, there you have a point. It is just that here at home we also have a Celeron 667 laptop with an 1,2 mbit USB network adapter, and X/Kde goes quite slow through it, so more CPU-load and less network-load would make things faster there.
On a 486 with 10 or 100 mbit, the opposite is the case, indeed.
It seems you cannot please both sides…
I use PPTP vpn using a linux box as the server and linux or windows clients, which is much more flexible than SSH tunneling – as I can do ssh tunneling over the pptp vpn again. Additionally, pptp vpn can deal with UDP traffic.
To avoid confusion, let me clarify the X “server-client” model. The server displays the window on the local machine. The client is on the remote machine and does all the processing. So it’s backwards. The client doesn’t need a video card or a screen.
The LTSP (Linux Terminal Server Project) takes old PCs, fixes them up, and connects them to a central app server (i.e. X client) that does all the processing. These people would be in trouble if it was necessary to do lots of processing locally, since these machines have very little processing power. That’s why this is a bad idea.
I think this should be more configurable, definitely, so it’s possible to please both sides. Don’t know how much that’s feasible programming-wise, though.
Apart from contributing to the actual X development, one can also encourage its development by not actively using it until such time as the desired features are implemented adequately for practical application.
While actual code contribution would be much more welcomed, the fact is that a particular project can’t handle too many contributors. Imaging that there are 50 thousands X users willing to contribute code for improvement, their willingness to act might make XFree86’s core team’s life miserable to integrate all those coding efforts, not to mention that much of those contributors’ effort would be in duplicated.
I think the ability to remove X is a great move forward. Not only does Scitech make a sort of java for drivers for video they can be used for almost any hardware device. Now I sort of like the idea of write once and run on many platforms and OS’s. X is ok but a bloated port to beos just to get a driver to work.
Sorry BR if I’m a bit late.
Let’s face it: the majority of the people isn’t using the network transparency of X. I don’t say we should scrap it (although I admit I sounded like that in my first post, hehe), but we should remove emphasis on it as the majority isn’t using that feature. That would probably provide a better desktop experience for everybody. I think the idea that Greg said is quite nice.
Btw Daan, I don’t say we should always listen to the majority, but it can be a good idea sometimes, especially when you want to gain market acceptance… And it’s not because you don’t use fancy stuff like like 3D accel or anti-aliasing that everybody in the world isn’t using it.
Got a problem with OpenSource? then grab your wallet and buy the bloody commercial solution that is apparently superior or would that actuallt require moving out of your parents basement, get a job and actually be responsible for something once in your misserable and pathetic little life.
Are you trolling? Yes. Try and control your fervor. This is not a religious debate, or a matter of life and death.
OpenSource are started BY volunteers for people who WANT t use it. If you don’t bloody like it, tough titty. Grow some knackers and get over it. Until YOU can provide a solution that is superior to what is available, keep to the cheap seats.
Please read what I wrote. Ask yourself where I said I don’t like Open Source Software. I don’t like people like yourselves who have attitude problems, and reply with personal attacks instead of a valid response. But hey, whatever floats your Linux boat.
Until OSS provides a viable desktop solution, MLdonkey and the likes will remain popular for a reason 😎
People make their choices mostly by their wallet and foot
I’m not a linux programmer, but could it be posible to mix X and directfb into an “smart server” who would use directfb or something like it for clients on the same computer and the normal X for clients on remote computers?
Lets just wait for Linux 2.6, if X still performs badly well lets continue to whinge.
Who gives a fuck? whoever is of the opinion that people should not whine about wanting a replacement should equally shut up. Why do they bother to waste time on such statements if in their opinion there is no need to change and they aren’t involved with either side really?
As for those who want to see more people migrate to Linux, BSD, etc: something not as clunky and hideous as X is one among many things which have to be changed in order to be competitive. the “don’t like it, don’T use it” response is what the majority actually does by staying on Windows.
Show a little love towards X
This post wasn’t about X or its use but about Sci Tech. In all the posts I have seen only one post that talks about Sci Tech.
If I were a moderator I would delete/move all your post as off topic.
Oh what shock it must be that I am using:
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
Sure, I am issues with some opensource programmes, but I certainly don’t air my dirty laundry in public in the hope of getting some attention.
Blame the idiot who made the first post and some how tried to relate it to X.
I mean, if Eugenia Loli-Queru posted an article on this site about Linux being used for quantum physics, I’ll guarantee you that there will be at least one loonie who will try to bring X into the discussion.
When the first X post is made, then there are 15 other people who label themselves so-called “usability experts” who couldn’t code their way out of a paper bag, giving advice from the cheap-seats on how XYZ can be improved through them doing nothing.
Strange how people say X performs badly. I don’t recall seeing this problem with anything but cards which have trashy driver support. My work machine is a radeon 9000 pro, my home machine has an original radeon 8500. I’ve also used gf3 & gf4 products, matrox cards, and in the past, banshee and voodoo3 cards with very good performance. All the other off brand cards I’ve seen, esp onboard video, have all been frankly very poor.
If there’s any complaints to be had about X11, it’s more about the snail’s pace which drivers are introduced, and that all GL development has been very tightly coupled with X11. However, with the recent shakeup with xfree86, I really think things might be getting better for the future.
These scitech things look interesting, but I’m not sure how well things will fly with it. The DirectFB folks seem to have a pretty good open solution available, even if it isn’t quite production quality yet. One thing we definitely need to encourage is for some manufacturer to help with good open source GL drivers or to help provide a smart way to do cross graphical environment (ie, X, DirectFB, GGI, etc.) drivers.
I’m honestly not sure where SciTech will end up in the Linux gui arena, hopefully it ends up being one choice among many.
We already have VI vs Emacs, Linux vs BSD, Gnome vs KDE, why not add Xfree vs ???
While its very fine and good that you think what you do, but the fact that you’re clearly wrong might give you pause. First of all, the client/server architecture isn’t a bottleneck. BeOS used a client/server architecture, OS X uses a client/server architecture, QNX uses a client server architecture. The QNX and BeOS GUIs were blazingly fast on my PII 300, so I highly doubt that client server architecture was holding them back.
Next, 3D on XFree is highly efficient *and* works within the client server framework. 3D applications in X use the GLX protocol. For local connections, the GLX protocol uses the DRI to send data to the graphics card. For remote connections, the GLX protocol can transparently send that data over an indirect link. The performance of this mechanism is top-notch. NVIDIA’s Linux drivers are every bit as fast and featureful as NVIDIA’s Windows drivers. Hell, they’re good enough that ILM has switched to NVIDIA and Linux for their artist desktops.
The vast majority of the problems with X GUIs come from less than intelligent redraw behavior in applications. In particular, there are some synchronization issues that make resizing a choppy operation. That means that unless you spend all day resizing windows, the “wiggle benchmark” is very misleading. Even then, there are lots of applications that pay very close attention to these synchronization issues, and work around them. The Qt toolkit in general does this. Thus, when you open up an application, even a very complex one, that consists mainly of built-in widgets (like Qt Designer, JuK, Kopete, Kate) they resize with zero (at least on a fast machine) flicker.
My personal gripe is that GUI coding (on all platforms) today is still so low level that app developers even need to bother with optimizing redraw. This will change in the future. EVAS, for example, is a canvasing library for X that automatically optimizes redraw behavior.
It should be noted that we do not view X as a bad *option* in fact it has proven its worth over and over again on millions of machines and continues to improve. What SciTech is working for is to provide options, options for end users and perhaps more importantly, options for developers.
blame the video card companies who insist on being 007 secret squirl by not giving out the required specifications to write a stable and functional driver that can use all the extensions available on XFree86.
An interesting point, fortunately we have been in a position to work with nearly all the “007 secret squirl’s” for the better part of the last 10 years and thanks to their willingness to support our efforts this fact has lead to the creation of some 200 SNAP graphics drivers – which are often faster and more stable than the OEM driver (sorry for the marketing bit – but its true)
My personal gripe is that GUI coding (on all platforms) today is still so low level that app developers even need to bother with optimizing redraw.
As always I continue to enjoy your no-non-sense posts – I encourage you to take a look at the SNAP SDK and MGL documentation/src/examples as I think you would be very impressed with the quality and the optimizations present in all the draw functions.
http://www.scitechsoft.com/docs/mgl/index.html
“If I were a moderator I would delete/move all your post as off topic.”
Apply for the job.
“An interesting point, fortunately we have been in a position to work with nearly all the “007 secret squirl’s” for the better part of the last 10 years and thanks to their willingness to support our efforts this fact has lead to the creation of some 200 SNAP graphics drivers – which are often faster and more stable than the OEM driver (sorry for the marketing bit – but its true) ”
Well NDA’s can be very helpful. Although I don’t think that’s the whole story. There have been OSS programmers who would agree to a NDA and the end result has still been nada. Birds of a feather I guess.
Lots of interesting posts, but not exactly related to SciTech MGL. The SciTech MGL is a portable, high performance graphics library and as such is not intended as a complete replacement for X. What it can do is allow you to write an application program that can run in a fullscreen console without needing X to be loaded. This is useful in two scenarios:
1. You are a game developer and need more power than X provides for your fullscreen game
2. You are an embedded systems developer and need a high performance graphics environment for your applications, but you do want the excess overhead of X.
The third scenario that everyone seems to be arguing over is for GUI applications. Although you can certainly write GUI applications with MGL (using the MegaVision or wxMGL toolkits), there is no advantage to writing a word processor in wxMGL instead of regular wxWindows that runs under X. If however the GUI is a front end to a high performance graphics application, game or embedded program, then there is a definate advantage since then you can use a mature toolkit as well as get direct access to the high performance features that MGL provides.
SciTech supports OSS and has made much of our own, one time proprietarty tools and code avalailable under various open source compatible licenses – Case in point the recent release of the SciTech SNAP SDK. As for the NDA’s acouple of the “007” types have agreed to allow us to open up *some* SciTech SNAP binaries which when combined with the SDK and the (soon to be released) DDK will allow OSS developers to fully accesss some very cool tools and technologies from SciTech.
Sorry I missed this earlier.
How do end users get the software to use apps written for MGL?
An app written with MGL would also include the runtime lib – so no further action would be/is required by the user. Feel free to finda copy of WinQuake™, Hexen II™ and give it a shot for yourself:)
Can a runtime be included with the app?
Answered in the above question.
For small scale distribution, how much does it cost to include this in a distro?
By “this” I assume you are more interested in the SciTech SNAP Graphics drivers, if this is not the case the rest of my responce is still valid;) This varies greatly depending on volume and features… If you need more information feel free to email me with specifics and I will do my best to give you a clearer picture
I don’t know why so many people are complaining X is slow. Maybe they don’t know how to set it up correctly.
Developers can now use SciTech MGL under the Lesser General Public License (LGPL), or through SciTech’s commercial software license for those seeking to offer closed source solutions.
The trouble I see with this approach is that it is perfectly legal for a proprietary app to link to LGPL’d libraries. A proprietary software company could easily “stiff” SciTech by using the LGPL’d version. That’s why Trolltech doesn’t offer Qt under the LGPL, to make sure that proprietary software companies cannot legally develop with Qt without paying for it.
We originally released the SNAP SDK and MGL under a dual GPL/proprietry license, but that didn’t work well for us due to compatibility issues with other libraries being used with the MGL code (ie: wxWindows).
As for begin ‘stiffed’ by a proprietary app linking to LGPL’ed libraries, that is a compromise that we made and if a proprietry developer is willing to abide by the requirements of the LGPL, then they are welcome to use our libraries (just don’t ask us for any support ;-).
“Removes Need for X on Linux” is part of the title
extension doesn’t remove the need for the base element.
MGL is fully capable of working with or without X being present, so to consider it as a simple extension of X is flawed.
because i don’t follow the development of xfree closely, can someone fill me in re what happened to keith packard and his planned fork, is he still with xfree, have the issues been worked out, means have the decision-making and the speed of progress been adressed?
a while ago, there was an interview with one of the developers of xfree, who said that they think about incorporating some 3d-stuff like in osx or longhorn into it-has work on that begun?
thx.
I am not sure what has been worked out at present. I do not believe there is a fork of XFree86 yet, and the XFree86 group has been working to address a lot of the concerns that people have had about XFree86.
Personally I hope the fork does not occur, but we will have to wait and see.
I tried to install this on RH9, with PII 350 and Intel 740 gfx card, but X just kept on restarting right after it shows the loging screen, and eventually it kicked me to console. I tried all the options in teh readme that I could think of, but I’m stuck as to why it doesn’t work. I tried checking the resolution and refresh rate stuff, and it tests just fine.
Any Ideas?
I’d really like to get this working, because the default Xfree 4.3 driver for I740 is aweful.
Thanks
I get an info that Greg of Microwindows have released NXLIB that enable X11 binaries to run unmodified under Microwindows environment. Have anyone tried this??
Actually, there is a fork, started by Keith Packard a few months ago. It’s kind of like the Reformation–the disgruntled elements leave and after they do the original organization fixes things up. Packard was a very important dev.