Eric Firing wrote:
> Mike,
>
> I made a quick test and took a quick look, and I certainly see a ripe
> mango within reach. I don't know what your constraints and strategy
> are, but I thought I would give you the off-the-cuff idea before I
> forget what I did.
>
> The test was pcolortest.py,
The STIX fonts are provided as OpenType wrappers around Adobe Compact
Font Format (CFF or Type 2) fonts (sometimes called OpenType CFF or
'OTTO' font, because of the header tag on these files). With the Agg
backend, this isn't a problem, since freetype supports these fonts
transparently. Howe
On 11/5/07, John Hunter <[EMAIL PROTECTED]> wrote:
> On 11/4/07, Eric Firing <[EMAIL PROTECTED]> wrote:
> > John, Fernando,
> >
> > Is it OK to remove the hack now? In pyplot.py:
> >
> > # a hack to keep old versions of ipython working with mpl after bug
> > # fix #1209354
>
> This was added in 20
Fernando Perez wrote:
> On 11/5/07, John Hunter <[EMAIL PROTECTED]> wrote:
>> On 11/4/07, Eric Firing <[EMAIL PROTECTED]> wrote:
>>> John, Fernando,
>>>
>>> Is it OK to remove the hack now? In pyplot.py:
>>>
>>> # a hack to keep old versions of ipython working with mpl after bug
>>> # fix #1209354
Darren Dale wrote:
> On Sunday 04 November 2007 9:04:15 am Michael Droettboom wrote:
>> I should also add -- it would be really nice to have STIX fonts working in
>> the upcoming stable release if possible. Hopefully tomorrow morning I can
>> assess how much work that will be and maybe delay taggi
Mike,
Thanks for the quick response.
I was wrong as usual: the masked array overhead in your original version
of the path initializer was actually small. I misinterpreted the
kcachegrind display. Rats! I was hoping for a big gain. It looks like
anything that makes a huge number of paths is
On Nov 6, 2007 1:05 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> This fontforge script seems to do the conversion quite well:
>
> #!/usr/bin/fontforge
> Open($1);
> Generate($1:r+".ttf");
> Quit(0);
>
> If there are no objections, I'll go ahead and do that an
John Hunter wrote:
> On Nov 6, 2007 1:05 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> This fontforge script seems to do the conversion quite well:
>>
>> #!/usr/bin/fontforge
>> Open($1);
>> Generate($1:r+".ttf");
>> Quit(0);
>>
>> If there are no objection
On Nov 6, 2007 1:36 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> There is, of course, some time and memory overhead to loading larger
> fonts, but it may not be significant.
>
> The other issue with subsetting the fonts before distributing them is
> just a matter of person-time: someone has
John Hunter wrote:
> On Nov 6, 2007 1:36 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>> There is, of course, some time and memory overhead to loading larger
>> fonts, but it may not be significant.
>>
>> The other issue with subsetting the fonts before distributing them is
>> just a matter
On Nov 6, 2007 2:09 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> No reason, other than the usual "hasn't been tested as much", and how
> that may affect the upcoming release. I anticipate more mis-mapped
> glyphs (I found some already, but I'm sure not all of them). But it
> won't get tes
Eric Firing wrote:
> Mike,
>
> Thanks for the quick response.
>
> I was wrong as usual: the masked array overhead in your original version
> of the path initializer was actually small. I misinterpreted the
> kcachegrind display. Rats! I was hoping for a big gain. It looks like
> anything t
Michael Droettboom wrote:
> Eric Firing wrote:
>> Mike,
>>
>> Thanks for the quick response.
>>
>> I was wrong as usual: the masked array overhead in your original
>> version of the path initializer was actually small. I misinterpreted
>> the kcachegrind display. Rats! I was hoping for a big g
Attaching benchmark.
from numpy.random import rand
import matplotlib
from matplotlib.pyplot import pcolor, savefig, show, ion, axis, draw, axes
import time
ion()
t = time.clock()
pcolor(rand(1000,100))
print "init: ", time.clock() - t
frames = 25.0
t = time.clock()
for i in xrange(int(frames))
I have been working on updating the trunk to provide enthought.traits version
2.6b1. backend_driver.py is running without exceptions using the traited
config package with the internal traits package.
Issues:
1) there are lots of absolute package imports scattered throughout traits'
code. I wor
Mike,
On my machine, with pcolor from the trunk:
[EMAIL PROTECTED]:~/test$ python pcolortest2.py
init: 2.0
fps: 0.287026406429
And substituting pcolormesh for pcolor:
init: 0.27
fps: 5.48245614035
Now that's more like it!
Using image can be another order of magnitude faster than pcolormesh
(
On Tue, Nov 06, 2007 at 09:00:23PM -0500, Darren Dale wrote:
> I have not committed my work to svn yet. I wanted to get some feedback on
> points 1 and 2 first. Is it acceptable to use traits internally, but not
> expose it to the end user? I think the answer is yes, and that this is even a
> be
17 matches
Mail list logo
