Having enjoyed using Tcl/Tk and iWidgets, I question why I'm plowing 
through the XForms toolkit.

http://xforms-toolkit.org/

Actually, I'm just updating a FreePascal port I updated before. I really 
like Freepascal for many reasons, mostly I can read it. But I learn a 
lot, so what you say makes sense to me.

When the framebuffer first came out, I used Freepascal to draw lines and 
circles in colors on the framebuffer, /dev/fb0. Pretty nice until the 
text console insisted on sharing the screen, so I knew it was too big a 
project for me.

The problem with X seems to be all the queues. It draws when it wants to 
draw. I really don't know all the modern graphics cards stuff.

Perhaps I'm stuck in the instrumentation era. All these new child 
hardware devices like Arduino are sensational appendages to the linux 
management hardware host. Any uncertainty in display response is a 
potential glitch.


Iznogoud wrote:
> I never met anyone who actually physically had a PDP11. At Minnesota State in
> the 90s we emulated it (what a concept!) Hey, at least you still have hair!
>
>> Personally, I'm disappointed the Direct Framebuffer guys seemed to give
>> up. I don't want another desktop, X and KDE are already spectacular. I
>> want real time hardware access, not "requests" and "hints."
>>
> It is still there (in Linux). Back in the day (circa 2002) I had to jump
> through a lot of hoops to get OpenGL hardware accelerated stuff to work on X
> running over a Voodoo 3Dfx card. Back then, 3D accelerated graphics in X was
> just giving a "viewport" to the native 3Dfx drivers. So it was the same type
> of calls made to the graphics hardware if you were on X or a tty (console) on
> the machine. If it went bad... I had to log in from another computer and simply
> restart the system. No. You want the X server to do whatever possible to
> talk to the hardware on your behalf. It has worked really well for over a
> decade now. You can get incredible framerates too. I assure you that you want
> constants sent to the hardware. That is how SGI designed OpenGL over X at the
> infancy of OpenGL.
>
> has anyone tried doing 3D accelerated graphics over the network? That is where
> OpenGL over X really shines. On the client side there is a lot passed over
> the network when you send the graphics, so you want to be using display lists
> or the more contemporary vertex buffer objects, vertex arrays, etc. One you
> get those over the network, they stay on the server side, and only short
> messages go across the network (usually TCP). That is _if_ the software is
> written properly. Great design if you ask me.
>
> Also, in the context of an application running on a "desktop" or a workstation,
> the command line would not be popular. There are ergonomic and market reasons
> for needing a windowing system. People want their email reader on the same
> desktop as their high-performance graphics.
>
> You will find arguments for and against what you are talking about. I err on
> the side of "hardware is fast enough for what I need to use Xlib" and I stick
> with it. Go with it and thank me later.
>
> Most people write software for Qt, Tcl/Tk, Motif, etc. There is no choise
> there.
> _______________________________________________
> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
> tclug-list at mn-linux.org
> http://mailman.mn-linux.org/mailman/listinfo/tclug-list
>