nanogui: Re: linking nano-x problem and performance enh.
Subject:
Re: [nanogui] linking nano-x problem and performance enh.
From:
"Greg Haerr" ####@####.####
Date:
10 Feb 2005 22:56:27 +0000
Message-Id: <0c0a01c50fc3$862506a0$0300a8c0@RDP>
> there is the make variable LDLIBS, which
is set to the standard libraries. This variable appears at the end of the
command line (thanks for pointing it out ;-o) . So I've added this to all
the makefiles in microwindows.. (argh..).
Let me know when you get this all working, we can then look to
see how the microwindows make system should be modified.
> There is just two errors left, as you can see from the output below. Seems
something is missing definewise..
Looks like GsSelect isn't defined... This usually happens if you
don't have LINUX or UNIX defined, look at nanox/srvmain.c
and make sure that the proper GsSelect() function you desire is
in fact getting compiled when using the compile options you've
added to Arch.rules.
> When I get microwindows to compile and run OK, I may get the make
adaptation added to the uClinux source tree, so that folks out there doing
embedded systems can use the newest microwindows code -
Are you using the microwindows-src-snapshot.tar.gz, which is a copy
of the near-latest CVS? This uses a modified build mechanism from
v0.90. If you're going to make uClinux mods, you should be using
this latest tree.
> A more interesting question. How much performance gain do you think one
would achieve by implementing the basic drawing primitives in hardware, like
the plot x,y
and the straight line drawing functions ? When I test microwindows in the
TCP/IP client/server configuration (never manged to get the server linked to
the app in the older version), I see something like a factor 10 difference
in straight line drawing performance (on the main widow), compared to a
dedicated (non-OS'ed) C program doing the same thing and drawing lines using
plot x,y function.
You really need to get the LINK_APP_INTO_SERVER option compiled
in order to judge this. when running client/server there are context
switches
and many things that can slow down the system, a complete explanation
is complicated, let me know if you need more details.
> Performance is alfa and omega when you are restricted to a 50-150 Mhz
range CPU and want nice graphics looks for MMI aplications where often you
have a lot of image updates to do - and perhaps all the time (like in a
VU-meter for example).
Personally I think the biggest hw speedups would be image display (blit)
and area clears.
Regards,
Greg
