Menu
▾
▴
visualpython-users
|
From: Bruce S. <Bru...@nc...> - 2009-11-17 02:22:46
|
Thanks. Can you pass along the program that generates this error? Bruce Sherwood Tim Smith (25121) wrote: > Hi, I’ve run into a problem with one of my models, I get the following > error (can’t paste text it crashes and won’t let me highlight text) > > <<crash.JPG>> > |
|
From: Tim S. (25121) <tk...@mi...> - 2009-11-17 03:23:45
|
Something I've noticed with vpython is speed doesn't seem to scale up. In my model I found 1000 points has a render time of 17, 10,000 points has a render time of 170, and 50,000 point has a render time of 445. Once I go over the 10,000 point mark performance starts to go down exponentially. What I'm wondering, is I'll potentially have to render 1,000,000 points for one of my projects, is vpython unsuitable for my task and is there a faster python 3d library out there? I've been really impressed with how fast vpython has enabled me to produce from very detailed models, how ever working with such slow objects is going to drive me a little batty eventually. ********************************************************************** IMPORTANT - This email and any attachments may contain confidential or privileged information intended solely for the intended recipient and / or copyrighted material. If you are not the intended recipient you must not use, interfere with, disclose, copy or take any action with reliance on this email or any part of it. If you have received this email in error please advise the sender via return email and delete or destroy all copies of this email and attachments. Any claim to confidentiality or privilege is not waived or lost by reason of mistaken transmission of this message. Any unauthorised use, copying or distribution is prohibited. Minara Resources Limited does not warrant that this email or any attachments are free of viruses and cannot guarantee the accuracy, reliability or completeness of this email and any attachments. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ********************************************************************** |
|
From: Bruce S. <Bru...@nc...> - 2009-11-17 03:48:52
|
I would say that your measurements clearly show that VPython is unsuitable for your task. The basic problem is that VPython is designed to facilitate the creation of navigable animations, which means that rendering must be done within a fraction of a second to permit responsive navigation with the mouse. Since this rendering is being done in C++, not in Python (though the Python objects must be referenced from the C++ code), it seems unlikely to me that some other engine would give you the interactivity you're looking for, but maybe someone reading this list can recommend an application that can do what you need. The only thing that can reduce the render time would seem to be to make the spheres extremely small, so that there is little to render. Sorry! Bruce Sherwood Tim Smith (25121) wrote: > Something I've noticed with vpython is speed doesn't seem to scale up. > In my model I found 1000 points has a render time of 17, 10,000 points > has a render time of 170, and 50,000 point has a render time of 445. > Once I go over the 10,000 point mark performance starts to go down > exponentially. > What I'm wondering, is I'll potentially have to render 1,000,000 points > for one of my projects, is vpython unsuitable for my task and is there a > faster python 3d library out there? I've been really impressed with how > fast vpython has enabled me to produce from very detailed models, how > ever working with such slow objects is going to drive me a little batty > eventually. > |
|
From: Guy K. K. <g....@ma...> - 2009-11-17 04:23:24
|
The weekend before last I gave a presentation at (the first) Kiwi PyCon on live data plotting and visualisation. I have mainly focused on (2D and 3D) plotting tools, but due to its unique features also included Visual Python into the mix. One of these unique features was speed. When it comes to the rendering of individual, unrelated objects, I have not seen anything faster than Visual. Some tools (maybe Mayavi) may be faster (or as fast) on structured data (that is e. g. vector fields in a cartesian array), but whenever I had to individually create and manage many data points, Visual was just the best in speed as compared with the other tools I'm familiar with. Having said that, Mayavi also provides an API that tries to be (somewhat) compatible to Visual (I think to Visual 3.x). But it wasn't nearly as fast as Visual. If you for example run the doublependulum.py example from both, you'll be amazed how speedy the pendulum swings by, and that's just with less than 10 rendered objects. But there also performance can be increased by setting the environment variable ETS_TOOLKIT=qt4 (to use the Qt4 backend, it's using "wx" by default). Still, speed is not nearly as fast, due to the fact that Mayavi goes through these abstraction layers: Python -> Traits -> VTKPython -> VTK -> OpenGL And Visual goes Python -> C++ -> OpenGL Of course, Mayavi has got grand additional nifty features due to that, but they do hinder execution speed quite significantly. My slides of the talk are here: http://www.slideshare.net/XEmacs/python-data-plotting-and-visualisation- extravaganza And a paper is soon to be available in The Python Paper Monograph Series issue for the Kiwi PyCon proceedings (see http://pythonpapers.org) Guy -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Pūtaiao o Mōhiohio me Pāngarau Massey University, Albany (North Shore City, Auckland) 473 State Highway 17, Gate 1, Mailroom, Quad B Building voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: Tim S. (25121) <tk...@mi...> - 2009-11-17 04:27:17
|
Hmm. Would I benefit from writing the application purely in c++ (not my preferred option)? I'm treading a line between speed and flexibility of pumping out various models, and speed of interpreting the model itself. If the model is frighteningly slow to interact with then I'm sunk, but if it takes me too long to produce a new model I'm also sunk. -----Original Message----- From: Bruce Sherwood [mailto:Bru...@nc...] Sent: Tuesday, 17 November 2009 11:49 AM To: Tim Smith (25121) Cc: vis...@li... Subject: Re: [Visualpython-users] speed I would say that your measurements clearly show that VPython is unsuitable for your task. The basic problem is that VPython is designed to facilitate the creation of navigable animations, which means that rendering must be done within a fraction of a second to permit responsive navigation with the mouse. Since this rendering is being done in C++, not in Python (though the Python objects must be referenced from the C++ code), it seems unlikely to me that some other engine would give you the interactivity you're looking for, but maybe someone reading this list can recommend an application that can do what you need. The only thing that can reduce the render time would seem to be to make the spheres extremely small, so that there is little to render. Sorry! Bruce Sherwood Tim Smith (25121) wrote: > Something I've noticed with vpython is speed doesn't seem to scale up. > In my model I found 1000 points has a render time of 17, 10,000 points > has a render time of 170, and 50,000 point has a render time of 445. > Once I go over the 10,000 point mark performance starts to go down > exponentially. > What I'm wondering, is I'll potentially have to render 1,000,000 points > for one of my projects, is vpython unsuitable for my task and is there a > faster python 3d library out there? I've been really impressed with how > fast vpython has enabled me to produce from very detailed models, how > ever working with such slow objects is going to drive me a little batty > eventually. > ********************************************************************** IMPORTANT - This email and any attachments may contain confidential or privileged information intended solely for the intended recipient and / or copyrighted material. If you are not the intended recipient you must not use, interfere with, disclose, copy or take any action with reliance on this email or any part of it. If you have received this email in error please advise the sender via return email and delete or destroy all copies of this email and attachments. Any claim to confidentiality or privilege is not waived or lost by reason of mistaken transmission of this message. Any unauthorised use, copying or distribution is prohibited. Minara Resources Limited does not warrant that this email or any attachments are free of viruses and cannot guarantee the accuracy, reliability or completeness of this email and any attachments. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ********************************************************************** |
|
From: Bruce S. <Bru...@nc...> - 2009-11-17 15:50:39
|
I'm pretty much out of my depth here, but Guy Kloss's nearly simultaneous and very interesting post about speed suggests that there is no royal road to speed + rapid creation. For that matter, there's only so much you can get out of today's graphics cards. For example, the NVIDIA Quadro FX 4600 (about $1400) is rated at 250 billion triangles per second (http://www.deskeng.com/articles/aaajxm.htm). Suppose a small sphere is approximated by 4 triangles facing you. Then the card would take a second to display 60 billion small spheres. To have good mouse navigation capabilities you would need to be able to redraw the scene in about a thirtieth of a second in response to a mouse move, which means that you could rotate and zoom only about 2 billion spheres. And that's assuming that no computation is being done: you generate the 2 billion spheres once, and then wait to react quickly to a change in camera position. A midrange card like the $600 Quadro FX 1700 does only 190 million triangles per second, which implies about 2 million navigable spheres. Bruce Sherwood Tim Smith (25121) wrote: > Hmm. Would I benefit from writing the application purely in c++ (not my > preferred option)? > I'm treading a line between speed and flexibility of pumping out various > models, and speed of interpreting the model itself. If the model is > frighteningly slow to interact with then I'm sunk, but if it takes me > too long to produce a new model I'm also sunk. > |
|
From: Bruce S. <Bru...@nc...> - 2009-11-18 01:16:50
|
I just realized that there is a factor of 2 inefficiency in Visual, actually. Visual attempts to apportion half the time to computation and half the time to rendering, as you can see if you set scene.show_rendertime = True. This is important: If the computational thread is starved, the objects don't get changed. If the rendering thread is starved, the scene doesn't reflect the computational changes. I think it's the case that Visual doesn't change this equal time sharing even if the computational thread has come to the end of the computation. So there could in principle be a factor of two improvement in the navigation of a scene whose objects are not changing, if this were implemented in Visual. Bruce Sherwood Bruce Sherwood wrote: > There is one other approach you could use. > > Make the scene invisible while you create the objects. Then make it visible. If > there are lots of objects, it will take a long time to render the scene, and you > certainly won't be able to navigate smoothly. But you could have a second window > with a rudimentary sampled version of the display. Let a click in the second > window toggle the visibility of the first (main) window. Click to make the first > window invisible, then navigate in the scene in the second window to get the > camera the way you want it, then use this information to modify the positioning > of the camera for the first window, and finally click in the second window to > make the first window visible with the new viewing angle. Something like that. > > The 1/3 factor you're seeing isn't necessarily inefficiencies in VPython's > having to get things from Python. The little calculation I did is only a rough > estimate. > > Bruce Sherwood > > Tim Smith (25121) wrote: >> That's very interesting Bruce, The quadro nvs285 I have in my >> workstation is only rated at 1.5 million triangles per second (I'm >> horrified btw, I asked our IT department what card was in this pc and I >> was told it was a fast quadro), meaning 29,000 sphere's would be the >> maximum I could render and have reasonably smooth motion, I'm finding I >> get 1/3 of that in actual fact when I do tests. >> >> -----Original Message----- >> From: Bruce Sherwood [mailto:Bru...@nc...] >> Sent: Tuesday, 17 November 2009 11:50 PM >> Cc: vis...@li... >> Subject: Re: [Visualpython-users] speed >> >> I'm pretty much out of my depth here, but Guy Kloss's nearly >> simultaneous and >> very interesting post about speed suggests that there is no royal road >> to speed >> + rapid creation. For that matter, there's only so much you can get out >> of >> today's graphics cards. >> >> For example, the NVIDIA Quadro FX 4600 (about $1400) is rated at 250 >> billion >> triangles per second (http://www.deskeng.com/articles/aaajxm.htm). >> Suppose a >> small sphere is approximated by 4 triangles facing you. Then the card >> would take >> a second to display 60 billion small spheres. To have good mouse >> navigation >> capabilities you would need to be able to redraw the scene in about a >> thirtieth >> of a second in response to a mouse move, which means that you could >> rotate and >> zoom only about 2 billion spheres. And that's assuming that no >> computation is >> being done: you generate the 2 billion spheres once, and then wait to >> react >> quickly to a change in camera position. >> >> A midrange card like the $600 Quadro FX 1700 does only 190 million >> triangles per >> second, which implies about 2 million navigable spheres. >> >> Bruce Sherwood >> >> Tim Smith (25121) wrote: >>> Hmm. Would I benefit from writing the application purely in c++ (not >> my >>> preferred option)? >>> I'm treading a line between speed and flexibility of pumping out >> various >>> models, and speed of interpreting the model itself. If the model is >>> frighteningly slow to interact with then I'm sunk, but if it takes me >>> too long to produce a new model I'm also sunk. >>> >> ------------------------------------------------------------------------ >> ------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and >> focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Visualpython-users mailing list >> Vis...@li... >> https://lists.sourceforge.net/lists/listinfo/visualpython-users >> >> ********************************************************************** >> IMPORTANT - This email and any attachments may contain confidential or privileged information intended solely for the intended recipient and / or copyrighted material. If you are not the intended recipient you must not use, interfere with, disclose, copy or take any action with reliance on this email or any part of it. If you have received this email in error please advise the sender via return email and delete or destroy all copies of this email and attachments. Any claim to confidentiality or privilege is not waived or lost by reason of mistaken transmission of this message. Any unauthorised use, copying or distribution is prohibited. Minara Resources Limited does not warrant that this email or any attachments are free of viruses and cannot guarantee the accuracy, reliability or completeness of this email and any attachments. >> >> This footnote also confirms that this email message has been swept by >> MIMEsweeper for the presence of computer viruses. >> >> www.clearswift.com >> ********************************************************************** > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users |
|
From: Tim S. (25121) <tk...@mi...> - 2009-11-18 01:51:03
|
In my case I could perform my computations on a faster remote server, and provide the computed dataset to the model. is changing this difficult? -----Original Message----- From: Bruce Sherwood [mailto:Bru...@nc...] Sent: Wednesday, 18 November 2009 9:17 AM To: Tim Smith (25121) Cc: vpusers Subject: Re: [Visualpython-users] speed I just realized that there is a factor of 2 inefficiency in Visual, actually. Visual attempts to apportion half the time to computation and half the time to rendering, as you can see if you set scene.show_rendertime = True. This is important: If the computational thread is starved, the objects don't get changed. If the rendering thread is starved, the scene doesn't reflect the computational changes. I think it's the case that Visual doesn't change this equal time sharing even if the computational thread has come to the end of the computation. So there could in principle be a factor of two improvement in the navigation of a scene whose objects are not changing, if this were implemented in Visual. Bruce Sherwood Bruce Sherwood wrote: > There is one other approach you could use. > > Make the scene invisible while you create the objects. Then make it visible. If > there are lots of objects, it will take a long time to render the scene, and you > certainly won't be able to navigate smoothly. But you could have a second window > with a rudimentary sampled version of the display. Let a click in the second > window toggle the visibility of the first (main) window. Click to make the first > window invisible, then navigate in the scene in the second window to get the > camera the way you want it, then use this information to modify the positioning > of the camera for the first window, and finally click in the second window to > make the first window visible with the new viewing angle. Something like that. > > The 1/3 factor you're seeing isn't necessarily inefficiencies in VPython's > having to get things from Python. The little calculation I did is only a rough > estimate. > > Bruce Sherwood > > Tim Smith (25121) wrote: >> That's very interesting Bruce, The quadro nvs285 I have in my >> workstation is only rated at 1.5 million triangles per second (I'm >> horrified btw, I asked our IT department what card was in this pc and I >> was told it was a fast quadro), meaning 29,000 sphere's would be the >> maximum I could render and have reasonably smooth motion, I'm finding I >> get 1/3 of that in actual fact when I do tests. >> >> -----Original Message----- >> From: Bruce Sherwood [mailto:Bru...@nc...] >> Sent: Tuesday, 17 November 2009 11:50 PM >> Cc: vis...@li... >> Subject: Re: [Visualpython-users] speed >> >> I'm pretty much out of my depth here, but Guy Kloss's nearly >> simultaneous and >> very interesting post about speed suggests that there is no royal road >> to speed >> + rapid creation. For that matter, there's only so much you can get out >> of >> today's graphics cards. >> >> For example, the NVIDIA Quadro FX 4600 (about $1400) is rated at 250 >> billion >> triangles per second (http://www.deskeng.com/articles/aaajxm.htm). >> Suppose a >> small sphere is approximated by 4 triangles facing you. Then the card >> would take >> a second to display 60 billion small spheres. To have good mouse >> navigation >> capabilities you would need to be able to redraw the scene in about a >> thirtieth >> of a second in response to a mouse move, which means that you could >> rotate and >> zoom only about 2 billion spheres. And that's assuming that no >> computation is >> being done: you generate the 2 billion spheres once, and then wait to >> react >> quickly to a change in camera position. >> >> A midrange card like the $600 Quadro FX 1700 does only 190 million >> triangles per >> second, which implies about 2 million navigable spheres. >> >> Bruce Sherwood >> >> Tim Smith (25121) wrote: >>> Hmm. Would I benefit from writing the application purely in c++ (not >> my >>> preferred option)? >>> I'm treading a line between speed and flexibility of pumping out >> various >>> models, and speed of interpreting the model itself. If the model is >>> frighteningly slow to interact with then I'm sunk, but if it takes me >>> too long to produce a new model I'm also sunk. >>> >> ------------------------------------------------------------------------ >> ------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and >> focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Visualpython-users mailing list >> Vis...@li... >> https://lists.sourceforge.net/lists/listinfo/visualpython-users >> >> ********************************************************************** >> IMPORTANT - This email and any attachments may contain confidential or privileged information intended solely for the intended recipient and / or copyrighted material. If you are not the intended recipient you must not use, interfere with, disclose, copy or take any action with reliance on this email or any part of it. If you have received this email in error please advise the sender via return email and delete or destroy all copies of this email and attachments. Any claim to confidentiality or privilege is not waived or lost by reason of mistaken transmission of this message. Any unauthorised use, copying or distribution is prohibited. Minara Resources Limited does not warrant that this email or any attachments are free of viruses and cannot guarantee the accuracy, reliability or completeness of this email and any attachments. >> >> This footnote also confirms that this email message has been swept by >> MIMEsweeper for the presence of computer viruses. >> >> www.clearswift.com >> ********************************************************************** > > ------------------------------------------------------------------------ ------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users |
|
From: Bruce S. <Bru...@nc...> - 2009-11-18 02:12:50
|
I don't expect any such change any time soon; a factor of 2 isn't going to make a big observable difference in the world of mouse responsiveness, nor is there someone available to make this change quickly. Your problems are with factors of 10 and 100, not 2. Bruce Sherwood Tim Smith (25121) wrote: > In my case I could perform my computations on a faster remote server, > and provide the computed dataset to the model. is changing this > difficult? > > -----Original Message----- > From: Bruce Sherwood [mailto:Bru...@nc...] > Sent: Wednesday, 18 November 2009 9:17 AM > To: Tim Smith (25121) > Cc: vpusers > Subject: Re: [Visualpython-users] speed > > I just realized that there is a factor of 2 inefficiency in Visual, > actually. > Visual attempts to apportion half the time to computation and half the > time to > rendering, as you can see if you set scene.show_rendertime = True. This > is > important: If the computational thread is starved, the objects don't get > > changed. If the rendering thread is starved, the scene doesn't reflect > the > computational changes. > > I think it's the case that Visual doesn't change this equal time sharing > even if > the computational thread has come to the end of the computation. So > there could > in principle be a factor of two improvement in the navigation of a scene > whose > objects are not changing, if this were implemented in Visual. > > Bruce Sherwood > > Bruce Sherwood wrote: >> There is one other approach you could use. >> >> Make the scene invisible while you create the objects. Then make it > visible. If >> there are lots of objects, it will take a long time to render the > scene, and you >> certainly won't be able to navigate smoothly. But you could have a > second window >> with a rudimentary sampled version of the display. Let a click in the > second >> window toggle the visibility of the first (main) window. Click to make > the first >> window invisible, then navigate in the scene in the second window to > get the >> camera the way you want it, then use this information to modify the > positioning >> of the camera for the first window, and finally click in the second > window to >> make the first window visible with the new viewing angle. Something > like that. >> The 1/3 factor you're seeing isn't necessarily inefficiencies in > VPython's >> having to get things from Python. The little calculation I did is only > a rough >> estimate. >> >> Bruce Sherwood >> >> Tim Smith (25121) wrote: >>> That's very interesting Bruce, The quadro nvs285 I have in my >>> workstation is only rated at 1.5 million triangles per second (I'm >>> horrified btw, I asked our IT department what card was in this pc and > I >>> was told it was a fast quadro), meaning 29,000 sphere's would be the >>> maximum I could render and have reasonably smooth motion, I'm finding > I >>> get 1/3 of that in actual fact when I do tests. >>> >>> -----Original Message----- >>> From: Bruce Sherwood [mailto:Bru...@nc...] >>> Sent: Tuesday, 17 November 2009 11:50 PM >>> Cc: vis...@li... >>> Subject: Re: [Visualpython-users] speed >>> >>> I'm pretty much out of my depth here, but Guy Kloss's nearly >>> simultaneous and >>> very interesting post about speed suggests that there is no royal > road >>> to speed >>> + rapid creation. For that matter, there's only so much you can get > out >>> of >>> today's graphics cards. >>> >>> For example, the NVIDIA Quadro FX 4600 (about $1400) is rated at 250 >>> billion >>> triangles per second (http://www.deskeng.com/articles/aaajxm.htm). >>> Suppose a >>> small sphere is approximated by 4 triangles facing you. Then the card >>> would take >>> a second to display 60 billion small spheres. To have good mouse >>> navigation >>> capabilities you would need to be able to redraw the scene in about a >>> thirtieth >>> of a second in response to a mouse move, which means that you could >>> rotate and >>> zoom only about 2 billion spheres. And that's assuming that no >>> computation is >>> being done: you generate the 2 billion spheres once, and then wait to >>> react >>> quickly to a change in camera position. >>> >>> A midrange card like the $600 Quadro FX 1700 does only 190 million >>> triangles per >>> second, which implies about 2 million navigable spheres. >>> >>> Bruce Sherwood >>> >>> Tim Smith (25121) wrote: >>>> Hmm. Would I benefit from writing the application purely in c++ (not >>> my >>>> preferred option)? >>>> I'm treading a line between speed and flexibility of pumping out >>> various >>>> models, and speed of interpreting the model itself. If the model is >>>> frighteningly slow to interact with then I'm sunk, but if it takes > me >>>> too long to produce a new model I'm also sunk. >>>> > ------------------------------------------------------------------------ >>> ------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day >>> trial. Simplify your report design, integration and deployment - and >>> focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Visualpython-users mailing list >>> Vis...@li... >>> https://lists.sourceforge.net/lists/listinfo/visualpython-users >>> >>> > ********************************************************************** >>> IMPORTANT - This email and any attachments may contain confidential > or privileged information intended solely for the intended recipient and > / or copyrighted material. If you are not the intended recipient you > must not use, interfere with, disclose, copy or take any action with > reliance on this email or any part of it. If you have received this > email in error please advise the sender via return email and delete or > destroy all copies of this email and attachments. Any claim to > confidentiality or privilege is not waived or lost by reason of mistaken > transmission of this message. Any unauthorised use, copying or > distribution is prohibited. Minara Resources Limited does not warrant > that this email or any attachments are free of viruses and cannot > guarantee the accuracy, reliability or completeness of this email and > any attachments. >>> This footnote also confirms that this email message has been swept by >>> MIMEsweeper for the presence of computer viruses. >>> >>> www.clearswift.com >>> > ********************************************************************** >> > ------------------------------------------------------------------------ > ------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day >> trial. Simplify your report design, integration and deployment - and > focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Visualpython-users mailing list >> Vis...@li... >> https://lists.sourceforge.net/lists/listinfo/visualpython-users |
|
From: Scott D. D. <Sco...@Ac...> - 2009-11-18 03:54:32
|
Bruce Sherwood wrote: > I don't expect any such change any time soon; a factor of 2 isn't going to make > a big observable difference in the world of mouse responsiveness, nor is there > someone available to make this change quickly. Your problems are with factors of > 10 and 100, not 2. > > Bruce Sherwood > > Tim Smith (25121) wrote: >> In my case I could perform my computations on a faster remote server, >> and provide the computed dataset to the model. is changing this >> difficult? My experience with exploratory display of too much data is that sampling the data down to smaller sizes actually works quite well. Pull in points with a probability of .001 if you have to; if it looks too sparse, back off. --Scott David Daniels Sco...@Ac... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X