Hi, sorry for my poor english, here is my question:
I need to draw a graphic composed by serveral lines (there is a lot of
vertexs and currently i draw a line between the consecutive one's). I`m
using Harlequin LispWorks and the capi library. The problem is that the
drawing process is too slow and i know that can be done faster (Autocad
for example do it). Must i find another algorithm?, could i use OpenGl
or DirectX to render it?, is there another (and better) graphic library
for Lisp?
Thank you.
a <·@a.com> writes:
Must i find another algorithm?, could i use OpenGl
> or DirectX to render it?, is there another (and better) graphic library
> for Lisp?
Look in your examples\opengl directory. In there you should find
source code to an OpenGL interface which allows you to use CAPI
output-panes as OpenGL windows.
Carl Shapiro wrote:
> a <·@a.com> writes:
>
> Must i find another algorithm?, could i use OpenGl
> > or DirectX to render it?, is there another (and better) graphic library
> > for Lisp?
>
> Look in your examples\opengl directory. In there you should find
> source code to an OpenGL interface which allows you to use CAPI
> output-panes as OpenGL windows.
I have compiled the OpenGL code that comes with LispWorks and i can see the
window and the buttons, but i can't see the icosahedron (only appears a white
space for drawing). Any idea? Thank you.
I'm going for the record here for "least knowledge had while offering
help", but I've looked at hairy 3d libraries before and I do not recall
them being that easy to use. Yours might be an OpenGL question. I do
have an OPenGL book here, not open in front of me, but I recall reading
something about you build up an image as one step and have it rendered
as a different step. I might have the terminology backwards or
something. But one possibility is you need an additional call or two to
actually dump the image to the screen.
Is there a working ogl demo example in the package?
kenny
clinisys
Rafael Le�n Franco wrote:
>
> Carl Shapiro wrote:
>
> > a <·@a.com> writes:
> >
> > Must i find another algorithm?, could i use OpenGl
> > > or DirectX to render it?, is there another (and better) graphic library
> > > for Lisp?
> >
> > Look in your examples\opengl directory. In there you should find
> > source code to an OpenGL interface which allows you to use CAPI
> > output-panes as OpenGL windows.
>
> I have compiled the OpenGL code that comes with LispWorks and i can see the
> window and the buttons, but i can't see the icosahedron (only appears a white
>
> space for drawing). Any idea? Thank you.
a <·@a.com> writes:
> Hi, sorry for my poor english, here is my question:
>
> I need to draw a graphic composed by serveral lines (there is a lot of
> vertexs and currently i draw a line between the consecutive one's). I`m
> using Harlequin LispWorks and the capi library. The problem is that the
> drawing process is too slow and i know that can be done faster (Autocad
> for example do it).
How many of this vertexes do you want to print? What does too slow
mean, do you have to wait for the output? How complex is the
calculation behind it. Have you compiled the code?
>Must i find another algorithm?
Well you were as unspecific as can be. Too slow that, and I know it
can be faster. Well maybe. But why do you think it's to slow?
>could i use OpenGl
> or DirectX to render it?, is there another (and better) graphic library
> for Lisp?
LispWorks comes with bindings for OpenGL (see the examples
section). It is a bit work to get it running, but at least it seems to
work.
Friedrich
Friedrich Dominicus wrote:
> a <·@a.com> writes:
>
> > Hi, sorry for my poor english, here is my question:
> >
> > I need to draw a graphic composed by serveral lines (there is a lot of
> > vertexs and currently i draw a line between the consecutive one's). I`m
> > using Harlequin LispWorks and the capi library. The problem is that the
> > drawing process is too slow and i know that can be done faster (Autocad
> > for example do it).
> How many of this vertexes do you want to print? What does too slow
> mean, do you have to wait for the output? How complex is the
> calculation behind it. Have you compiled the code?
>
> >Must i find another algorithm?
> Well you were as unspecific as can be. Too slow that, and I know it
> can be faster. Well maybe. But why do you think it's to slow?
>
> >could i use OpenGl
> > or DirectX to render it?, is there another (and better) graphic library
> > for Lisp?
> LispWorks comes with bindings for OpenGL (see the examples
> section). It is a bit work to get it running, but at least it seems to
> work.
>
> Friedrich
Well, in fact what i want to print is a topographic map, a DXF file, of
10Mbytes, i supose you can imagine how many vertexes it can be (87000). Too
slow means that have to wait for almost 2 minutes, and i have to wait for the
output. The calculation is very simple, the vertexes are in memory and i only
have to print a line between each consecutive vertexes. I have compiled the
code, and i have made an executable, but it don't improve the time very much.
The goal is to print the map in less time (of course not so faster as AutoCad
does).
I have compiled the OpenGL code that comes with LispWorks and i can see the
window and the buttons, but i can't see the icosahedron (only appears a white
space for drawing). Any idea? Thank you.
Rafael Le�n Franco <····@albireo.lcc.uma.es> writes:
> Well, in fact what i want to print is a topographic map, a DXF file, of
> 10Mbytes, i supose you can imagine how many vertexes it can be (87000). Too
> slow means that have to wait for almost 2 minutes, and i have to wait for the
> output. The calculation is very simple, the vertexes are in memory and i only
> have to print a line between each consecutive vertexes. I have compiled the
> code, and i have made an executable, but it don't improve the time very much.
Perhaps CAPI is attempting to redraw the pane between each line you
draw. If you have a loop drawing lines between the vertices, wrap it
in a WITH-ATOMIC-REDISPLAY form.
--
Lieven Marchand <···@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Rafael Le�n Franco <····@albireo.lcc.uma.es> writes:
>
> Well, in fact what i want to print is a topographic map, a DXF file, of
> 10Mbytes, i supose you can imagine how many vertexes it can be (87000). Too
> slow means that have to wait for almost 2 minutes, and i have to wait for the
> output.
That seems really a bit too long. Have you considered to ask the
Xanalys support? Maybe they know what to do.
> I have compiled the OpenGL code that comes with LispWorks and i can see the
> window and the buttons, but i can't see the icosahedron (only appears a white
> space for drawing). Any idea? Thank you.
Depends on the system you're using. I tried my luck und Linux and with
some help from Jochen Schmidt I got it running. If you're running on
Windows, than I can't help
Regards
Friedrich
Friedrich Dominicus wrote:
> Rafael Le�n Franco <····@albireo.lcc.uma.es> writes:
>
> >
> > Well, in fact what i want to print is a topographic map, a DXF file, of
> > 10Mbytes, i supose you can imagine how many vertexes it can be (87000). Too
> > slow means that have to wait for almost 2 minutes, and i have to wait for the
> > output.
> That seems really a bit too long. Have you considered to ask the
> Xanalys support? Maybe they know what to do.
>
> > I have compiled the OpenGL code that comes with LispWorks and i can see the
> > window and the buttons, but i can't see the icosahedron (only appears a white
> > space for drawing). Any idea? Thank you.
> Depends on the system you're using. I tried my luck und Linux and with
> some help from Jochen Schmidt I got it running. If you're running on
> Windows, than I can't help
> Regards
> Friedrich
Yes i`m running on windows, but thank you very much for your interest.
Rafa.
a wrote:
> Hi, sorry for my poor english, here is my question:
>
> I need to draw a graphic composed by serveral lines (there is a lot of
> vertexs and currently i draw a line between the consecutive one's). I`m
> using Harlequin LispWorks and the capi library. The problem is that the
> drawing process is too slow and i know that can be done faster (Autocad
> for example do it). Must i find another algorithm?, could i use OpenGl
> or DirectX to render it?, is there another (and better) graphic library
> for Lisp?
How exactly do you draw it?
Do you draw it _directly_ to the window?
Do you use a background buffer that is then mapped in one step?
Have you profiled your code where the bottlenecks are?
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt wrote:
> a wrote:
>
> > Hi, sorry for my poor english, here is my question:
> >
> > I need to draw a graphic composed by serveral lines (there is a lot of
> > vertexs and currently i draw a line between the consecutive one's). I`m
> > using Harlequin LispWorks and the capi library. The problem is that the
> > drawing process is too slow and i know that can be done faster (Autocad
> > for example do it). Must i find another algorithm?, could i use OpenGl
> > or DirectX to render it?, is there another (and better) graphic library
> > for Lisp?
>
> How exactly do you draw it?
> Do you draw it _directly_ to the window?
> Do you use a background buffer that is then mapped in one step?
> Have you profiled your code where the bottlenecks are?
>
> ciao,
> Jochen
>
> --
> http://www.dataheaven.de
Hi, i'm the person who wrote the first question (yes, i'm 'a' it was because
my identity was not configured correctly). After this text yol will find the
drawing code we are using to paint the files (we are drawing a DXF file, it
is a topographic map of 10Mbytes). I have heard there are some specific
algorithms for drawing contour lines (i don't know if you can help me in
this). In the other reply's i have done you can find more information. I'm
sorry very much because i don't knows how the capi library really works.
Thank you
;;----------------------------------------------------------------------------
;; Definition of Mapa Pinboard-Object class
;;----------------------------------------------------------------------------
(Defclass Mapa (Capi:Pinboard-Object)
((Foreground :Accessor Foreground :Initform :orange :Initarg :Foreground)
(Polylineas :Accessor Polylineas :Initform Nil :Initarg Polylineas)))
;--------------------------------------------------------------------
;Create a map with the polylines list that compose it
;--------------------------------------------------------------------
(Defun Crea-Mapa (Polylineas)
(let
((Mapa (Make-Instance 'Mapa)))
(Capi:With-Geometry Mapa
(setf capi:%X% 0)
(setf capi:%y% 0)
(setf capi:%width% (/(- (Xmax *ventanaprincipal*)(Xmin
*ventanaprincipal*)) *divisorcarga*))
(setf capi:%height% (/(- (ymax *ventanaprincipal*)(ymin
*ventanaprincipal*)) *divisorcarga*))
(setf (polylineas Mapa) Polylineas))Mapa))
;-----------------------------------------------------------
;Write the map in the screen. Draw the lines one to one
;-----------------------------------------------------------
(Defmethod Capi:Draw-Pinboard-Object (Pinboard (Mapa Mapa) &Key)
(Capi:With-Geometry Mapa
(Dolist (Lineas (polylineas Mapa))
(Do
((Coordenadas Lineas (cdr coordenadas)))
((<= (length coordenadas) 1) Nil)
(Gp:Draw-Line Pinboard
(/(-(Caar Coordenadas)(Xmin *ventanaprincipal*))
*divisorcarga*)
(/(- (ymax *ventanaprincipal*) (Cadar Coordenadas))
*divisorcarga*)
(/(-(caadr coordenadas)(Xmin *ventanaprincipal*))
*divisorcarga*)
(/(- (ymax *ventanaprincipal*)(cadadr coordenadas))
*divisorcarga*)
:Foreground (Or (Foreground Mapa)
(Capi:Simple-Pane-Foreground Pinboard)))))))
;-------------------------------------------------------------
; This function really insert the map in the screen
;-------------------------------------------------------------
(Defun Inserta-Mapa (Mapa &Key (Ventana *ventanaprincipal*))
(Setf (Capi:Layout-Description (Salida21 Ventana))(Append
(Capi:Layout-Description (Salida21 Ventana)) (list Mapa))))
In article <·················@albireo.lcc.uma.es>, "Rafael Le�n Franco"
<····@albireo.lcc.uma.es> wrote:
> ;----------------------------------------------------------- ;Write the
> map in the screen. Draw the lines one to one
> ;----------------------------------------------------------- (Defmethod
> Capi:Draw-Pinboard-Object (Pinboard (Mapa Mapa) &Key)
> (Capi:With-Geometry Mapa
> (Dolist (Lineas (polylineas Mapa))
> (Do
> ((Coordenadas Lineas (cdr coordenadas))) ((<= (length coordenadas)
> 1) Nil)
^^^^^^^^^^^^^^
This line is a bad idea, each time you go to the next vertex, "length"
traverses the entire list... in other words your algorithm is O(n^2). All
you care about is that the list is not finished.
change (<= (length coordenadas) 1) to (or (not coordinadas) (not (cdr
coordinadas))) or perhaps (not (and coordinatas (cdr coordinatas))) a little
easier to understand.
"Daniel Lakeland" <········@silnospamcon.com> writes:
> In article <·················@albireo.lcc.uma.es>, "Rafael Le�n Franco"
> <····@albireo.lcc.uma.es> wrote:
>
> > ;----------------------------------------------------------- ;Write the
> > map in the screen. Draw the lines one to one
> > ;----------------------------------------------------------- (Defmethod
> > Capi:Draw-Pinboard-Object (Pinboard (Mapa Mapa) &Key)
> > (Capi:With-Geometry Mapa
> > (Dolist (Lineas (polylineas Mapa))
> > (Do
> > ((Coordenadas Lineas (cdr coordenadas))) ((<= (length coordenadas)
> > 1) Nil)
>
> ^^^^^^^^^^^^^^
> This line is a bad idea, each time you go to the next vertex, "length"
> traverses the entire list... in other words your algorithm is O(n^2). All
> you care about is that the list is not finished.
>
> change (<= (length coordenadas) 1) to (or (not coordinadas) (not (cdr
> coordinadas))) or perhaps (not (and coordinatas (cdr coordinatas))) a little
> easier to understand.
Nice catch. Bugs like this are quite common but often hard to notice.
I once suggested that LENGTH should have an optional max argument so
one could write (<= (length x 2) 1) in order to say "2 suffices to
mean infinity for what I will use this for", or else that there should
be a separate operator (length< x 2) which had the smarts not to go
too far. Actually, I had one other idea which was that there should be
a set of functions ZERO, ONE, TWO, THREE, etc. which were like FIRST,
SECOND, etc. but returned the NTHCDR instead of the N+1TH. It's not
obvious until you see it in context why this would be useful, but it
lets you write things like (not (one x)) or (if (one x) (first x)).
Kent M Pitman <······@world.std.com> wrote in message > > > > > > > > > > > > > > ((Coordenadas Lineas (cdr coordenadas))) ((<= (length coordenadas)
> > > 1) Nil)
> > ^^^^^^^^^^^^^^
> > This line is a bad idea, each time you go to the next vertex, "length"
> > traverses the entire list... in other words your algorithm is O(n^2). All
> > you care about is that the list is not finished.
>
> Nice catch. Bugs like this are quite common but often hard to notice.
I guess it's things like this that gives Lisp a bad name,
as in "Lisp programmers know the value of everything but the
[performance] cost of nothing" huh.
I wonder if there is anything in optimizing compiler technology
of the last decade [during which my impression is that there
was significant progress, although probably benefitting mainly
C/C++ and perhaps Java compilers, rather than Lisp compilers,
since hardcore cutting-edge compiler/processor architecture
people rarely if ever are Lisp people or have Lisp sensibilities]
that can detect and do something about this sort of
optimization opportunity.
··········@yahoo.com (Pratibha) writes:
> > > This line is a bad idea, each time you go to the next vertex, "length"
> > > traverses the entire list... in other words your algorithm is O(n^2). All
> > > you care about is that the list is not finished.
> >
> > Nice catch. Bugs like this are quite common but often hard to notice.
>
> I guess it's things like this that gives Lisp a bad name,
> as in "Lisp programmers know the value of everything but the
> [performance] cost of nothing" huh.
You can run into the same kinds of stuff in C as well. Its not a Lisp
issue at all.
Run the following once with STRLEN defined and again without,
observing the consequences- negligible for small buffers of course,
but substantial for larger ones.
=====================================================
#include <string.h>
#define STRLEN 1
#define BLEN 16384
int main(int argc, char **argv)
{
int i, lencalc;
char *buffer = malloc(BLEN);
memset(buffer,0xaa,BLEN);
buffer[BLEN-1]= 0;
lencalc = 0;
#ifdef STRLEN
for(i=0; i<strlen(buffer); i++)
{
lencalc = lencalc+1;
}
#else
for(i=0; buffer[i] > 0; i++)
{
lencalc = lencalc+1;
}
#endif
return 0;
}
// eof
======================================================
> I wonder if there is anything in optimizing compiler technology
> of the last decade [during which my impression is that there
> was significant progress, although probably benefitting mainly
> C/C++ and perhaps Java compilers, rather than Lisp compilers,
> since hardcore cutting-edge compiler/processor architecture
> people rarely if ever are Lisp people or have Lisp sensibilities]
> that can detect and do something about this sort of
> optimization opportunity.
This case isn't a compiler optimization question, its one of
appreciating the consequences of code in a particular context.
Gregm
Greg Menke wrote
> You can run into the same kinds of stuff in C as well. Its not a Lisp
> issue at all.
Right. Actually, my post was more of a longwinded way
of wondering aloud what the pace of progress (if any) is these days
in Lisp compiler technology vs. C/C++/Java compiler technology.
Are Lisp compilers a relatively stagnant research area
these days?
> This case isn't a compiler optimization question, its one of
> appreciating the consequences of code in a particular context.
I would say that it is (or could be considered to be) an
area for possible optimization, using a perhaps loose or
expanded definition of "compiler optimization", which doesn't
rule out a priori any kind of program analysis or
transformation intended to alleviate programmer
"failure" such as failure to "appreciate the consequences of code
in a particular context", or failure to, well, in general,
manually optimize/tune the code.
For example, isn't it conceivable that a compiler could
have the (artificial?) intelligence to realize that LENTH is
side-effect-free, that the actual result of LENGTH was not
important, only the result of its comparison with a constant
[1], and then generate code accordingly (in this case, code
that does not do unnecessary work)?
I don't know whether that kind of analysis is AI/expertsystem-ish,
but I guess that could be an interesting combination of
previously separate turfs: AI compilers.
>
> > This case isn't a compiler optimization question, its one of
> > appreciating the consequences of code in a particular context.
>
> I would say that it is (or could be considered to be) an
> area for possible optimization, using a perhaps loose or
> expanded definition of "compiler optimization", which doesn't
> rule out a priori any kind of program analysis or
> transformation intended to alleviate programmer
> "failure" such as failure to "appreciate the consequences of code
> in a particular context", or failure to, well, in general,
> manually optimize/tune the code.
But the environment is doing what you told it to do; a do loop which
tests the length of a list each time it checks the terminating case.
This is a very C-like approach, there are already a number of
functions in Lisp to efficiently iterate over a list.
>
> For example, isn't it conceivable that a compiler could
> have the (artificial?) intelligence to realize that LENTH is
> side-effect-free, that the actual result of LENGTH was not
> important, only the result of its comparison with a constant
> [1], and then generate code accordingly (in this case, code
> that does not do unnecessary work)?
But what if the code in the loop changed the list's length, or the
list (or some cdr of it) was addressable in some other thread & was
changed there? For the runtime Lisp environment to choose between a
length test into a test against a cached value, it would have to be
aware of and continuously monitor the run-time disposition of the
entire list and which portions of it are addressed by all loop
termination-test variables which point to it.
Gregm
Greg Menke wrote:
> But the environment is doing what you told it to do; a do loop which
> tests the length of a list each time it checks the terminating case.
I think of an optimizing compiler, in general (not necessarily in
today's state of the art, whereever that is), as one that is able to
Do What I Meant Not What I Said.
> But what if the code in the loop changed the list's length, or the
> list (or some cdr of it) was addressable in some other thread & was
> changed there? For the runtime Lisp environment to choose between a
> length test into a test against a cached value,
I don't think anyone is suggesting that the optimized code do that.
The suggestion is that in the optimized code, whether human or
compiler generated, the end-test form (<= ...) of the DO can
return its value---and the actual length of the list does not
have to be computed [or the length computation, if begun, does
not have to proceed to completion]---once it is determined that
the length is greater than one. No caching of the result of
LENGTH is being suggested.
As the original bug reporter suggested, one way to achieve
this optimization is to replace the end-test form (<= ...)
with an equivalent that does not use LENGTH. What I have
been wondering is whether a smart enough compiler could
do that static transformation; or something more runtime-ish
such as aborting the LENGTH computation.
Of course, the assumption in all of this is that LENGTH
takes O(n) time in the length of the list. In an implementation
where LENGTH is O(1), such as one which maintains the current list
length somewhere and in which LENGTH just accesses that stored
value, then the original bug would not have been a bug.
Again, the original bug analysis, which was more succinct
than any of my posts:
> (Defmethod Capi:Draw-Pinboard-Object (Pinboard (Mapa Mapa) &Key)
> (Capi:With-Geometry Mapa
> (Dolist (Lineas (polylineas Mapa))
> (Do ((Coordenadas Lineas (cdr coordenadas)))
> ((<= (length coordenadas) 1) Nil)
>
> This line is a bad idea, each time you go to the next vertex, "length"
> traverses the entire list... in other words your algorithm is O(n^2). All
> you care about is that the list is not finished.
··········@yahoo.com (Pratibha) writes:
> Greg Menke wrote
> > You can run into the same kinds of stuff in C as well. Its not a Lisp
> > issue at all.
>
> Right. Actually, my post was more of a longwinded way
> of wondering aloud what the pace of progress (if any) is these days
> in Lisp compiler technology vs. C/C++/Java compiler technology.
> Are Lisp compilers a relatively stagnant research area
> these days?
Well, which areas aren't stagnant research areas these days? When I
look at e.g. recent PLDI proceedings, it seems to me that the large
majority of compiler researchers are currently trying to find ways of
coping with Java design flaws (e.g. optimizing away the horrendous
per-object locking overhead, doing efficient FP arithmetic despite the
spec, JIT compiling JVM bytecodes, trying to recapture needed
information from JVM bytecodes that the compiler threw away, etc.), or
trying to find ways of efficiently compiling to VLIW machines.
Most of that stuff isn't applicable to languages which aren't broken
as designed, and the VLIW stuff looks to be usable by CL implementors,
should VLIW machines really take off.
Oh, and then there is some research in the FP community, which is
trying to come up with ways of efficiently compiling laziness, etc.
And then there is research into stuff which Lisp has had for many,
many years, but which is hard to obtain for languages that didn't
anticipate that need, i.e. things like incremental compilation,
linking, etc.
> I would say that it is (or could be considered to be) an
> area for possible optimization, using a perhaps loose or
> expanded definition of "compiler optimization", which doesn't
> rule out a priori any kind of program analysis or
> transformation intended to alleviate programmer
> "failure" such as failure to "appreciate the consequences of code
> in a particular context", or failure to, well, in general,
> manually optimize/tune the code.
If you have a programmer that fails to appreciate the consequences of
code in a particular context, then you have more pressing problems
than performance bugs to worry about. Would it be nice to have
AI-complete machines that _reliably_ recognized programmer faults and
corrected them? Maybe, but then I'd wonder why you needed programmers
at all. In any case I don't think there is any risk that we will see
such machines in the next couple of decades.
> For example, isn't it conceivable that a compiler could
> have the (artificial?) intelligence to realize that LENTH is
> side-effect-free, that the actual result of LENGTH was not
> important, only the result of its comparison with a constant
> [1], and then generate code accordingly (in this case, code
> that does not do unnecessary work)?
Oh, it is entirely possible to do this, in this particular case (it
isn't very hard to do, a simple source-to-source transformation
triggered by pattern-matching, something that most compilers will
support). The problem is that this is about as useful as a
spelling-checker that knows about 0.01% of commonly used vocabulary:
You can only really make use of such optimizations if you can rely on
them happening. But it is very hard to keep track of which particular
optimizations of that sort the compiler you use is doing, and which
not. And that's just for one compiler.
I really think that such a patchwork of optimizations with far
reaching consequences for algorithmic complexity (i.e. we are talking
about more than a constant factor here), only serves to make the
compiler seem non-deterministic from the POV of the programmer, which
seems a high cost to pay for accomodating programmers which don't
really know what they are doing.
And where is the end to that path? Should a compiler be allowed to
replace my use of a list with an array, if it thinks that this is the
more suitable data-structure? Does it replace a hash-table with a
balanced search tree?
I can see a programmer's assistant (apart from the compiler), that
tries to find such possible problem-areas, and gives advice on
improving the code, effectively replacing/augmenting c.l.l (or an
expert programmer's) advice. But I don't see this as something that a
compiler should be doing.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Greg Menke <··········@mindspring.com> writes:
> Run the following once with STRLEN defined and again without,
> observing the consequences- negligible for small buffers of course,
> but substantial for larger ones.
Without STRLEN, I get 0 in lencalc. No wonder it's fast! ;-)
In article <·················@Astalo.y2000.kon.iki.fi>
···@iki.fi "Kalle Olavi Niemitalo" writes:
>Greg Menke <··········@mindspring.com> writes:
>
>> Run the following once with STRLEN defined and again without,
>> observing the consequences- negligible for small buffers of course,
>> but substantial for larger ones.
>
>Without STRLEN, I get 0 in lencalc. No wonder it's fast! ;-)
I'm guessing that there is a thread on comp.lang.lisp and the
comp.lang.c cross-post has been added here. If so you need to include
more context so we can see what the heck you are talking about.
--
-----------------------------------------
Lawrence Kirby | ····@genesis.demon.co.uk
Wilts, England | ·········@compuserve.com
-----------------------------------------
* ··········@yahoo.com (Pratibha)
| I guess it's things like this that gives Lisp a bad name,
Absolutely anything can be used to excuse Lisp's bad name. In truth,
_every_ language has this kind of gotcha. Only Lisp gets a bad name
because someone who are ignorant of them run into them. If you want to
look for the reason behind the "bad name", you need to look much closer
to home than the language.
| I wonder if there is anything in optimizing compiler technology of the
| last decade [...] that can detect and do something about this sort of
| optimization opportunity.
Well, it certainly doesseem that constant folding is not performed
terribly often in Common Lisp compiler. For everything we can do with
the language, it is actually hard to know when an expression will always
return the same value.
For instance, (length foo) of a list foo _may_ change if any cons cell
reachable from foo is changed, and it is hard to prove that that cannot
occur. However, calling a function repeatedly with the same argument
that the _programmer_ does not think will change is not good style, and
since Common Lisp is a language that implicitly trusts the programmer,
philosophically quite distinct from most other language, if you do call
the same function with the same argument repeatedly, you probably have a
good reason to do so, and if you really did not mean to, you would not
have done it to begin with. This trust issue is important, because it
also means Common Lisp programmers need to trust their Common Lisp system
more than other language users need to trust theirs. We also have the
most trustworthy _standard_ in the whole industry, and most Common Lisp
programmers are exceptionally conscientious, with few notable exceptions,
and they are _actually_ programming in some other language, anyway.
To a good Common Lisp programmer, a construction in your code that in any
other language would be a common, boneheaded thing to do and _therefore_
subject to optimization, not criticism, by a much smarter compiler than
most of its programmers, would cause a Common Lisp programmer to ask why
you did it, the Common Lisp compiler to actually do what you told it to
do, and some wise guy to quip that (bad) Common Lisp programmers know the
cost of nothing. :)
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
Kent M Pitman wrote:
> "Daniel Lakeland" <········@silnospamcon.com> writes:
>
> > In article <·················@albireo.lcc.uma.es>, "Rafael Le�n Franco"
> > <····@albireo.lcc.uma.es> wrote:
> >
> > > ;----------------------------------------------------------- ;Write the
> > > map in the screen. Draw the lines one to one
> > > ;----------------------------------------------------------- (Defmethod
> > > Capi:Draw-Pinboard-Object (Pinboard (Mapa Mapa) &Key)
> > > (Capi:With-Geometry Mapa
> > > (Dolist (Lineas (polylineas Mapa))
> > > (Do
> > > ((Coordenadas Lineas (cdr coordenadas))) ((<= (length coordenadas)
> > > 1) Nil)
> >
> > ^^^^^^^^^^^^^^
> > This line is a bad idea, each time you go to the next vertex, "length"
> > traverses the entire list... in other words your algorithm is O(n^2). All
> > you care about is that the list is not finished.
> >
> > change (<= (length coordenadas) 1) to (or (not coordinadas) (not (cdr
> > coordinadas))) or perhaps (not (and coordinatas (cdr coordinatas))) a little
> > easier to understand.
>
> Nice catch. Bugs like this are quite common but often hard to notice.
> I once suggested that LENGTH should have an optional max argument so
> one could write (<= (length x 2) 1) in order to say "2 suffices to
> mean infinity for what I will use this for", or else that there should
> be a separate operator (length< x 2) which had the smarts not to go
> too far. Actually, I had one other idea which was that there should be
> a set of functions ZERO, ONE, TWO, THREE, etc. which were like FIRST,
> SECOND, etc. but returned the NTHCDR instead of the N+1TH. It's not
> obvious until you see it in context why this would be useful, but it
> lets you write things like (not (one x)) or (if (one x) (first x)).
Hi, i found the bug yesterday, but what i sent was the original code. No solution
for that bug improves the time (1 or 2 seconds), i think it isn't the bottleneck
of the code, instead i think the problem can be the way that the capi libray works
(i don't know) or the algorithm i'm using for drawing the topographic map (i have
heard there is many algorithms for doing it). Thank you.
Rafa.
On Fri, 19 Oct 2001 08:42:33 +0200, Rafael =?iso-8859-1?Q?Le=F3n?=
Franco <····@albireo.lcc.uma.es> wrote:
>
> Hi, i found the bug yesterday, but what i sent was the original code. No solution
> for that bug improves the time (1 or 2 seconds), i think it isn't the bottleneck
> of the code, instead i think the problem can be the way that the capi libray works
> (i don't know) or the algorithm i'm using for drawing the topographic map (i have
> heard there is many algorithms for doing it). Thank you.
>
> Rafa.
>
Massive graphic output to bitmap cards is usually slow unless you can
use double graphic buffers. This is because the actual writing occurs at
vertical (and sometimes horizontal too ) retrace of the electron beam.
I'm not sure how graphic boards that drive flat panels operate in this
respect.
Open GL (and other graphic subsystems) will detect if double buffers are
available but your application software will have to request double
buffering explicitly.
Also, be aware that standard pixel drawing is often very slow. Again,
this has little to do with Lisp or OpenGL (or CAPI).
Regards, Lars
In article <·················@albireo.lcc.uma.es>, "Rafael Le�n Franco"
<····@albireo.lcc.uma.es> wrote:
> Hi, i found the bug yesterday, but what i sent was the original code. No
> solution for that bug improves the time (1 or 2 seconds), i think it
> isn't the bottleneck of the code, instead i think the problem can be the
> way that the capi libray works (i don't know) or the algorithm i'm using
> for drawing the topographic map (i have heard there is many algorithms
> for doing it). Thank you.
Hi. At this point I can heartily recommend getting a profiler and running
it!
The one I use is called "metering" and is available as part of the CLOCC
distribution at clocc.sourceforge.net. You don't need the whole thing
(CLOCC), just the metering part, but I do find it (clocc) a pretty useful
library.
You might also want to look at the MK-defsystem available with clocc to
make loading your code easier.
anyway, read a little about the metering package, load it into your lisp
system, and then run your code while profiling it. Give us a dump of the
top 10 time hogs.
If you want to talk DXF files and drawing algorithms I'd be happy to do
it, but perhaps we should start a new thread, or move off c.l.l??
Since you're implementing this in lisp, I think it'd be fair to start a
new thread here.
-----------here's the summary from metering.txt-------------
3.2.1. Suggested Usage
The easiest way to use the METERING system is to load it and evaluate
either
(mon:with-monitoring (<name>*) ()
<form>*)
or
(mon:monitor-form <form>)
The former allows you to specify which functions will be monitored,
while the latter monitors all functions in the current package.
Both automatically produce a table of statistics. Variations on these
functions can be constructed from the monitoring primitives, which are
described in Section 3.2.2.
"Daniel Lakeland" <········@silnospamcon.com> writes:
> Hi. At this point I can heartily recommend getting a profiler and running
> it!
Always a good idea when optimizing.
> The one I use is called "metering" and is available as part of the CLOCC
> distribution at clocc.sourceforge.net.
Since he's using LWW, he can just use the one that comes with it:
<http://www.xanalys.com/software_tools/reference/lww41/lwuser/LWUG_80.HTM#HEADING80-0>
--
Pekka P. Pirinen
I have yet to see any problem, however complicated, which,
when you looked at it in the right way, did not become still
more complicated. - Poul Anderson
In article <···············@world.std.com>, "Kent M Pitman"
<······@world.std.com> wrote:
> "Daniel Lakeland" <········@silnospamcon.com> writes:
>
>> In article <·················@albireo.lcc.uma.es>, "Rafael Le�n Franco"
>> <····@albireo.lcc.uma.es> wrote:
>>
>> > ;----------------------------------------------------------- ;Write
>> > the map in the screen. Draw the lines one to one
>> > ;-----------------------------------------------------------
>> > (Defmethod Capi:Draw-Pinboard-Object (Pinboard (Mapa Mapa) &Key)
>> > (Capi:With-Geometry Mapa
>> > (Dolist (Lineas (polylineas Mapa))
>> > (Do
>> > ((Coordenadas Lineas (cdr coordenadas))) ((<= (length
>> > coordenadas) 1) Nil)
>>
>> ^^^^^^^^^^^^^^
>> This line is a bad idea, each time you go to the next vertex, "length"
>> traverses the entire list... in other words your algorithm is O(n^2).
>> All you care about is that the list is not finished.
>>
>> change (<= (length coordenadas) 1) to (or (not coordinadas) (not (cdr
>> coordinadas))) or perhaps (not (and coordinatas (cdr coordinatas))) a
>> little easier to understand.
>
> Nice catch. Bugs like this are quite common but often hard to notice. I
> once suggested that LENGTH should have an optional max argument so one
> could write (<= (length x 2) 1) in order to say "2 suffices to mean
> infinity for what I will use this for"
Yeah, I sometimes think in terms of "what does this mean" and sometimes in
terms of "how does this work". My guess is a short trip to a profiler
would have cought this easily. Lots of time would be spent in length.
for the original author: CLOCC is available at clocc.sourceforge.net if I
remember correctly, and it includes a profiling package that is written in
portable CL code...
also for the original author. How much did this optimization help?? Can you
give us some before and after timing info??
thanks,
Dan
Rafael Le�n Franco wrote:
>
>
> Jochen Schmidt wrote:
>
>> a wrote:
>>
>> > Hi, sorry for my poor english, here is my question:
>> >
>> > I need to draw a graphic composed by serveral lines (there is a lot of
>> > vertexs and currently i draw a line between the consecutive one's). I`m
>> > using Harlequin LispWorks and the capi library. The problem is that the
>> > drawing process is too slow and i know that can be done faster (Autocad
>> > for example do it). Must i find another algorithm?, could i use OpenGl
>> > or DirectX to render it?, is there another (and better) graphic library
>> > for Lisp?
>>
>> How exactly do you draw it?
>> Do you draw it _directly_ to the window?
>> Do you use a background buffer that is then mapped in one step?
>> Have you profiled your code where the bottlenecks are?
>>
>> ciao,
>> Jochen
>>
>> --
>> http://www.dataheaven.de
>
> Hi, i'm the person who wrote the first question (yes, i'm 'a' it was
> because my identity was not configured correctly). After this text yol
> will find the drawing code we are using to paint the files (we are drawing
> a DXF file, it is a topographic map of 10Mbytes). I have heard there are
> some specific algorithms for drawing contour lines (i don't know if you
> can help me in this). In the other reply's i have done you can find more
> information. I'm sorry very much because i don't knows how the capi
> library really works. Thank you
It is probably better to use a Pixmap-Port associated with an output-pane
instead of a pinboard-object. You then draw your lines onto the pixmap-port
instead of directly into the output-pane. If the drawing to the pixmap-port
is finished you copy the pixmap-port to the output-pane using
CAPI:COPY-PIXELS. It is probably a good idea to have a flag that shows if
the underlying line-data has changed - so that you only have to do a
CAPI:COPY-PIXELS on window-refresh if the data got not modified.
Another thing is that it is more efficient to draw concatenated lines at a
whole than line by line. So if you can feed the drawing engine with several
polygons instead of several lines it may be more efficient too.
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt wrote:
> It is probably better to use a Pixmap-Port associated with an output-pane
> instead of a pinboard-object. You then draw your lines onto the pixmap-port
> instead of directly into the output-pane. If the drawing to the pixmap-port
> is finished you copy the pixmap-port to the output-pane using
> CAPI:COPY-PIXELS. It is probably a good idea to have a flag that shows if
> the underlying line-data has changed - so that you only have to do a
> CAPI:COPY-PIXELS on window-refresh if the data got not modified.
>
> Another thing is that it is more efficient to draw concatenated lines at a
> whole than line by line. So if you can feed the drawing engine with several
> polygons instead of several lines it may be more efficient too.
>
> ciao,
> Jochen
>
> --
> http://www.dataheaven.de
Thank you very much for your idea, now the first time i draw the map the program
runs slowly, but the refresh works correctly. Now i have another problem, the
zoom. I can't have an infinite pixmap-port, and i think that every time the user
moves the scroll bar once the zoom is activated (the map can't be drawn
completely in the pixmap-port if the zoom is activated, only a portion of the
map can be in), i should draw the portion of the map that can be seen now in the
pixmap-port. This can be very slow. Do you have any idea?
Regards,
Rafa
> Thank you very much for your idea, now the first time i draw the map the
program
> runs slowly, but the refresh works correctly. Now i have another problem,
the
> zoom. I can't have an infinite pixmap-port, and i think that every time
the user
> moves the scroll bar once the zoom is activated (the map can't be drawn
> completely in the pixmap-port if the zoom is activated, only a portion of
the
> map can be in), i should draw the portion of the map that can be seen now
in the
> pixmap-port. This can be very slow. Do you have any idea?
Of course there is nothing you can do about this. Yes, if you want speed,
you should only draw what you need to.
I assume you have tried using capi:with-atomic-redisplay to defer
redisplaying after every drawing operation you do.
Your idea would to use OpenGL or DirectX to let the graphics hardware do the
zooming would work. All it takes is a reference and some (hard) work.
Wade
Wade Humeniuk wrote:
> > Thank you very much for your idea, now the first time i draw the map the
> program
> > runs slowly, but the refresh works correctly. Now i have another problem,
> the
> > zoom. I can't have an infinite pixmap-port, and i think that every time
> the user
> > moves the scroll bar once the zoom is activated (the map can't be drawn
> > completely in the pixmap-port if the zoom is activated, only a portion of
> the
> > map can be in), i should draw the portion of the map that can be seen now
> in the
> > pixmap-port. This can be very slow. Do you have any idea?
>
> Of course there is nothing you can do about this. Yes, if you want speed,
> you should only draw what you need to.
>
> I assume you have tried using capi:with-atomic-redisplay to defer
> redisplaying after every drawing operation you do.
>
> Your idea would to use OpenGL or DirectX to let the graphics hardware do the
> zooming would work. All it takes is a reference and some (hard) work.
>
> Wade
Do you work on CAD?, Do you know any technique for drawing an AutoCad DXF file
more eficiently?
Thank you
Rafa
>
> Do you work on CAD?, Do you know any technique for drawing an AutoCad DXF
file
> more eficiently?
Don't let the cadvision in my email address fool you. My ISP used to be a
CAD/CAM company.
No, I have never seem a DXF file. I assume its some sort of
plotting/drawing format. More efficiently than what?
Wade
> >
> > Do you work on CAD?, Do you know any technique for drawing an AutoCad DXF
> file
> > more eficiently?
>
If you can convert your DXF file to 3ds format, its reasonably
straightforward to parse and assemble a vector of triangles to draw.
The same may be true of DXF, but I've never tried parsing it.
The 3ds format is binary, so something like
http://ww.telent.net/cliki/Binary-types
would be a big help in reading it.
If you can get the vertices for your mesh assembled into a list of
triangles, then you might improve performance by indexing them and
only drawing the visible ones. If you can get your mesh arranged as a
series of triangles, it would also make rendering via OpenGL a bit
easier.
Gregm
On 24 Oct 2001 22:58:29 -0400, Greg Menke <··········@mindspring.com>
wrote:
>
>If you can convert your DXF file to 3ds format, its reasonably
>straightforward to parse and assemble a vector of triangles to draw.
>The same may be true of DXF, but I've never tried parsing it.
>The 3ds format is binary, so something like
>
>http://ww.telent.net/cliki/Binary-types
>
>would be a big help in reading it.
>
A quick look in Yahoo gave this page for graphics file formats:
http://www.dcs.ed.ac.uk/home/mxr/gfx/3d-hi.html
There are several other similar Internet pages of course. My
experience is that you often miss some information when converting
"graphic" files, other than the simplest. This is the problem that
standards such as IGES and STEP tried to solve, with varying success.
A topographic (2D?) map _ought_ to be simple, but even simple stuff
such as text, coloring etc can cause problems.
>
>If you can get the vertices for your mesh assembled into a list of
>triangles, then you might improve performance by indexing them and
>only drawing the visible ones. If you can get your mesh arranged as a
>series of triangles, it would also make rendering via OpenGL a bit
>easier.
>
Absolutely. Giving the graphic subsystem (OpenGL in this case) the
most suitable form of data structures will certainly help. I think we
may be getting nearer to the level where I thought the bottleneck
might be (in my previous response) - in the setup of the low-level
graphics driver.
This kind of stuff is built into any CAD system, as is the use of
double-buffering, if available. If not, the refresh rate may be slow
for these data volumes, even on a fast CPU.
Raphael, I think you will find reading some introductory material to
basic 2D/3D drawing techniques useful.
Lars
Rafael Le�n Franco wrote:
>
> ···············@telia.com wrote:
>
> > Absolutely. Giving the graphic subsystem (OpenGL in this case) the
> > most suitable form of data structures will certainly help. I think we
> > may be getting nearer to the level where I thought the bottleneck
> > might be (in my previous response) - in the setup of the low-level
> > graphics driver.
> >
> > This kind of stuff is built into any CAD system, as is the use of
> > double-buffering, if available. If not, the refresh rate may be slow
> > for these data volumes, even on a fast CPU.
> >
> > Raphael, I think you will find reading some introductory material to
> > basic 2D/3D drawing techniques useful.
> >
> > Lars
>
> I have read many books of graphics (3D graphics) and i know how to use
> OpenGL and directX. I know how to treat vertexes, sides and faces,
> including how and why it is convenient to use a doble or triple buffer. My
> problem is that i'm a C/C++ programmer and my only experience in LISP is
> the course i made 2 years ago (i didn't make graphics), and now i have to
> make 2D graphics on LISP, and it should work as well as AutoCad. If the
> maps i have to draw weren't so big (10Mbytes) perhaps i had found a
> solution easily. If i could run the OpenGL example that comes with
> LispWorks, it would be a great help. Thank you for your interest.
>
> Rafa.
Did you consider using any OpenGL binding (a Common Lisp interface to a
C-compiled OpenGL library, MesaGL probably)?
I programmed (within a group of students) a small OpenGL library too,
but it cannot be as fast as the former proposal...
--
--------------------------
Jonathan BAILLEUL
Doctorant au GREYC
ISMRA, Universit� de Caen