matplotlib-devel Mailing List for matplotlib

On Wed, Jul 27, 2011 at 10:57 AM, Benjamin Root <ben...@ou...> wrote:
> I have come across an odd layering issue with errorbars. The errorbar caps
> are not drawn at the same layer as the errorbar itself. Also, the line
> connecting multiple errorbars are plotted on a completely different layer
> than the errorbars. I am attaching an example demonstrating this. Note the
> green caps are showing up on top of the red errorbar, meanwhile, the red
> errorbar is drawn on top of the green errorbar. Also notice that the thin
> red line connecting the red errorbars is showing up on top of the green cap
> for lambda = 1.
>
> I am not exactly sure how this should be fixed. It is most likely an issue
> with the fact that the caps are drawn as markers instead of a line (I am
> guessing so that the marker would then be sized based on width in points
> instead of data). When an axes' child objects are z-sorted, the objects
> that do not declare a z-order are loaded in the order of their creation (or
> is it in some arbitrary order based on the type of collection?).
>
> Cheers,
> Ben Root
>
Just for the record, I filed issue #409 here:
https://github.com/matplotlib/matplotlib/issues/409
Ben Root

Have you tried running it in the Python profiler? I find this script 
[1] in combination with kcachegrind to be very useful in answering these 
kinds of questions.
[1] http://codespeak.net/pypy/dist/pypy/tool/lsprofcalltree.py
Mike
On 07/28/2011 07:16 AM, Nicolas Rougier wrote:
>
>
> I've created a fork at: 
> https://github.com/rougier/matplotlib/tree/gl-backend
>
> The name of the backend is glut (it requires OpenGL) and does not 
> display anything, it only measures fps.
>
> It seems to be stuck at 100fps with the following test script:
>
> import matplotlib
> matplotlib.use('glut')
> from pylab import *
> plot([1,2,3])
> show()
>
> while the same do-nothing window directly in pyOpenGL is around 
> 2000fps on the same machine.
>
> I would like to understand why this is so slow and if it can be fixed.
>
>
>
> Nicolas
>
>
>
>
>
>
> On Jul 27, 2011, at 3:28 PM, Benjamin Root wrote:
>
>>
>>
>> On Wednesday, July 27, 2011, Nicolas Rougier 
>> <Nic...@in... <mailto:Nic...@in...>> wrote:
>> >
>> >
>> > Hi all,
>> >
>> > I've been testing various idea around the idea of a GL backend, and 
>> I would have a few questions.
>> > First, I tried to use the backend template to quickly test an empty 
>> pyglet backend and I've been quite surprised by the bad 
>> performances. Without drawing anything, I can hardly reach 100FPS and 
>> I wonder if I did something wrong ? (The backend is 
>> available backend_pyglet.py 
>> <http://www.loria.fr/~rougier/tmp/backend_pyglet.py 
>> <http://www.loria.fr/%7Erougier/tmp/backend_pyglet.py>> and the test 
>> file is at test_backend_pyglet.py 
>> <http://www.loria.fr/~rougier/tmp/test_backend_pyglet.py 
>> <http://www.loria.fr/%7Erougier/tmp/test_backend_pyglet.py>>)
>> >
>> > Second, I've been experimenting with proper anti-alias technics 
>> (using shaders) and the results are not so bad so far (IMHO) :
>> > Antialiased line with thickness varying by 0.1 pixels:
>> > http://www.loria.fr/~rougier/tmp/aa-line.png 
>> <http://www.loria.fr/%7Erougier/tmp/aa-line.png>
>> > (don't paid attention to the cap, it's not done yet)
>> >
>> > Antialiased circles (small circles position is increased by 0.1 pixels)
>> > http://www.loria.fr/~rougier/tmp/aa-circle.png 
>> <http://www.loria.fr/%7Erougier/tmp/aa-circle.png>
>> > (I can post source code if anyone is interested)
>> > I don't know yet if all matplotlib artists can be drawing using 
>> these technics.
>> >
>> > My question relates to the cairo backend that now seems to support 
>> gl and shaders. Does anyone know the status of the gl-backend and how 
>> it would improve performances of matplotlib ? (I had a hard time 
>> finding any information).
>> >
>> > Nicolas
>>
>> Nicolas,
>>
>> I want to immediately encourage you to continue on your efforts. 
>> PLEASE make a fork on github so that we may be able to experiment 
>> better.
>>
>> Cheers!
>> Ben Root 
>
>
> ------------------------------------------------------------------------------
> Got Input? Slashdot Needs You.
> Take our quick survey online. Come on, we don't ask for help often.
> Plus, you'll get a chance to win 100ドル to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

 Hi,
I would like to report some issues in python basemap package and 
easy-fixes for
some of them. We would really appreciate if there was somebody who could 
look
on this and consider important bugs to be fixed.
These bugs was found by Coverity scan and we have ran it on Fedora 15
packages (srpm). There was some findings in python basemap package also. 
Coverity
is proprietary software but we can give its result to community (if 
interrested),
possibly we can re-run some tests on srpms on demand.
Patch for next three obvious bugs (plaintext cov. output) is attached:
Error: OVERRUN_STATIC:
basemap-0.99.4/src/pj_gridlist.c:252: overrun-local: Overrunning static 
array "name", with 128 elements, at position 128 with index variable 
"end_char".
Error: UNINIT:
basemap-0.99.4/src/mk_cheby.c:42: var_decl: Declaring variable "T" 
without initializer.
basemap-0.99.4/src/mk_cheby.c:150: uninit_use: Using uninitialized value 
"T".
basemap-0.99.4/src/mk_cheby.c:151: uninit_use: Using uninitialized value 
"T->mu".
basemap-0.99.4/src/mk_cheby.c:152: uninit_use: Using uninitialized value 
"T->cu".
basemap-0.99.4/src/mk_cheby.c:154: uninit_use: Using uninitialized value 
"T->mv".
basemap-0.99.4/src/mk_cheby.c:155: uninit_use: Using uninitialized value 
"T->cv".
basemap-0.99.4/src/mk_cheby.c:163: uninit_use: Using uninitialized value 
"T".
Error: NO_EFFECT:
basemap-0.99.4/src/PJ_sconics.c:52: self_assign: Assignment operation 
"*del = *del" has no effect.
__________________________
But there is more defects (or coding style issues) and some of them are not
so obvious. There could be potential problems -- need to be consulted, e.g.:
Error: EVALUATION_ORDER:
basemap-0.99.4/src/PJ_stere.c:232: write_write_order: In "P->phits = 
(pj_param(P->params, "tlat_ts").i ? P->phits = pj_param(P->params, 
"rlat_ts").f : 1.5708)", "P->phits" is written in "P->phits" (the 
assignment left-hand side) and written in "pj_param(P->params, 
"tlat_ts").i ? P->phits = pj_param(P->params, "rlat_ts").f : 1.5708" but 
the order in which the side effects take place is undefined because 
there is no intervening sequence point.
Error: FORWARD_NULL:
basemap-0.99.4/src/emess.c:29: var_compare_op: Comparing "fmt" to null 
implies that "fmt" might be null.
basemap-0.99.4/src/emess.c:51: var_deref_model: Passing null variable 
"fmt" to function "vfprintf", which dereferences it.
Error: FORWARD_NULL:
basemap-0.99.4/src/pj_gridinfo.c:505: var_compare_op: Comparing "gp" to 
null implies that "gp" might be null.
basemap-0.99.4/src/pj_gridinfo.c:512: alias_transfer: Assigning null: 
"lnk" = "gp".
basemap-0.99.4/src/pj_gridinfo.c:512: var_deref_op: Dereferencing null 
variable "lnk".
Error: FORWARD_NULL:
basemap-0.99.4/src/pj_ell_set.c:30: var_compare_op: Comparing 
"start->next" to null implies that "start->next" might be null.
basemap-0.99.4/src/pj_ell_set.c:92: var_deref_op: Dereferencing null 
variable "start->next".
Coverity test was done on:
http://sourceforge.net/projects/matplotlib/files/matplotlib-toolkits/basemap-0.99.4/basemap-0.99.4.tar.gz
..so svn version is little different (line numbers) but it can be handy for
finding hidden bugs. I can send you full plain-text log if you want.
Pavel

I've created a fork at: https://github.com/rougier/matplotlib/tree/gl-backend
The name of the backend is glut (it requires OpenGL) and does not display anything, it only measures fps.
It seems to be stuck at 100fps with the following test script:
import matplotlib
matplotlib.use('glut')
from pylab import *
plot([1,2,3])
show()
while the same do-nothing window directly in pyOpenGL is around 2000fps on the same machine.
I would like to understand why this is so slow and if it can be fixed.
Nicolas
On Jul 27, 2011, at 3:28 PM, Benjamin Root wrote:
> 
> 
> On Wednesday, July 27, 2011, Nicolas Rougier <Nic...@in...> wrote:
> >
> >
> > Hi all,
> >
> > I've been testing various idea around the idea of a GL backend, and I would have a few questions.
> > First, I tried to use the backend template to quickly test an empty pyglet backend and I've been quite surprised by the bad performances. Without drawing anything, I can hardly reach 100FPS and I wonder if I did something wrong ? (The backend is available backend_pyglet.py <http://www.loria.fr/~rougier/tmp/backend_pyglet.py> and the test file is at test_backend_pyglet.py <http://www.loria.fr/~rougier/tmp/test_backend_pyglet.py>)
> >
> > Second, I've been experimenting with proper anti-alias technics (using shaders) and the results are not so bad so far (IMHO) :
> > Antialiased line with thickness varying by 0.1 pixels:
> > http://www.loria.fr/~rougier/tmp/aa-line.png
> > (don't paid attention to the cap, it's not done yet)
> >
> > Antialiased circles (small circles position is increased by 0.1 pixels)
> > http://www.loria.fr/~rougier/tmp/aa-circle.png
> > (I can post source code if anyone is interested)
> > I don't know yet if all matplotlib artists can be drawing using these technics.
> >
> > My question relates to the cairo backend that now seems to support gl and shaders. Does anyone know the status of the gl-backend and how it would improve performances of matplotlib ? (I had a hard time finding any information). 
> >
> > Nicolas
> 
> Nicolas,
> 
> I want to immediately encourage you to continue on your efforts. PLEASE make a fork on github so that we may be able to experiment better.
> 
> Cheers!
> Ben Root