MPL does not have a backend that used “real” GPU rendering.
And it’s very hard to make one, due to the really low level nature of
OpenGL and similar APIs, and MPL’s rendering model.
You might try VisPy — it was designed for OpenGL from the start.
-CHB
Sent from my iPhone
On Jul 5, 2018, at 5:
On Mar 13, 2015, at 12:50 PM, Cyrille Rossant wrote:
> Exactly. Note that pushing data on the GPU is not that slow:
No -- and something has to be pushed to the video card at some point anyway.
But my experience is that if you need to push the data to the CPU,
that pretty much overwhelms the adv
Are there recent binaries for OS-X anywhere? There don't seem to be
any for recent releases on the MPL download page.
I know we had a discussion about this a whole back, but don't remember
the outcome. But I hope we'll continue to put them up-- macports and
friends really aren't the best solutions
On Fri, Aug 23, 2013 at 11:21 AM, Russell Owen wrote:
> Here are my old instructions (I deleted them when I started using Apple's
> libraries, but the wayback machine saves the day):
Thanks Russell -- this is helpful. A few comments:
> • If you plan to redistribute matplotlib, delete (o
On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry wrote:
> I'm banging away at installing MPL on top of python.org's python.
This is why binary installers are good idea!
> the libfreetype/freetype issue.
yeah, that's kind of uglyand where is doesn't "just work" for me...
> 1) install libpng[1] a
On Fri, Aug 16, 2013 at 3:41 PM, Hubert Holin wrote:
> Building for various architectures than one is on, on the
> Mac, is something I regretfully bought into (Apple in the beginning told us
> to go for it) but latter found out to be a useless hassle (Apple silently
> removing P
On Fri, Aug 16, 2013 at 7:32 AM, Michael Droettboom wrote:
> We actually discussed this very issue yesterday in our Google hangout about
> continuous integration. We're probably going to need to script a full setup
> from a clean Mac + XCode to a working matplotlib development environment in
> or
t now -- but I'll see what I can do.
-Chris
> Mike
>
> On 08/12/2013 01:55 PM, Chris Barker - NOAA Federal wrote:
>> On Mon, Aug 12, 2013 at 7:01 AM, Michael Droettboom wrote:
>>> I propose to fix this by turning on interactive only when
>>> running at an i
On Mon, Aug 12, 2013 at 7:01 AM, Michael Droettboom wrote:
> I propose to fix this by turning on interactive only when
> running at an interactive console.
I embed MPL more than other uses, and this sounds like a fine solution to me/
Thanks,
-Chris
--
Christopher Barker, Ph.D.
Oceanographe
On Jul 24, 2013, at 7:23 AM, Michael Droettboom wrote:
Part of this is due to the change to setuptools/distribute,
Even though I was the one who spearheaded the move
to setuptools, I'm wondering whether we shouldn't examine backtracking
on some of this for the 1.4.x release.
I don't think s
On Thu, May 30, 2013 at 11:29 PM, Nicolas Rougier
wrote:
>> I'm also concerned about the overhead of
>> ctypes, given that there are already so many required optimizations in
>> the matplotlib freetype wrapper to make it fast enough. But I'm willing
>> to hold judgement on that until some measur
On Thu, May 30, 2013 at 8:59 AM, Michael Droettboom wrote:
> I've drafted a MEP with a plan to improve some of the text and font handling
> in matplotlib.
>
> I'd love any and all feedback.
nice writ-up and thanks for workign on this.
One idea (alternative?) would be to put more effort into the
On Wed, May 29, 2013 at 5:54 PM, Michael Droettboom wrote:
> It looks like the ability to include pytz and other dependencies in
> binary distributions has been removed?
>
> It's really just that the matplotlib source no longer includes them.
> Binaries can be built however we want them to be. N
On Wed, May 29, 2013 at 2:19 PM, Russell E. Owen wrote:
> I guess we could serve the associated packages (pytz, dateutil and six),
> or if they can be installed by pip, ask users to install those. But
> users using binary installers may not even have pip available, so it's a
> big initial hurdle.
On Mon, Dec 3, 2012 at 4:16 PM, Nathaniel Smith wrote:
> Yeah, this is a general problem with the Python file API, trying to
> hook it up to stdio is not at all an easy thing. A better version of
> this code would skip that altogether like:
>
> cdef void write_to_pyfile(png_structp s, png_bytep d
On Mon, Dec 3, 2012 at 12:24 PM, Chris Barker - NOAA Federal
wrote:
>>>> but some of that complexity could be reduced by using Numpy arrays in place
>> It would at least make this a more fair comparison to have the Cython
>> code as Cythonic as possible. However,
On Mon, Dec 3, 2012 at 2:21 PM, Nathaniel Smith wrote:
> For the file handle, I would just write
>
> cdef FILE *fp = fdopen(file_obj.fileno(), "w")
>
> and be done with it. This will work with any version of Python etc.
yeah, that makes sense -- though what if you want to be able to
read_to/wri
On Mon, Dec 3, 2012 at 11:59 AM, Michael Droettboom wrote:
>>> but some of that complexity could be reduced by using Numpy arrays in place
>>> of the
>>> image buffer types that each of them contain
>> OR Cython arrays and/or memoryviews -- this is indeed a real strength of
>> Cython.
>
> Sure,
On Sat, Dec 1, 2012 at 6:44 AM, Michiel de Hoon
>
> Since the Python/C glue code is modified only very rarely, there may not be
> a need for regenerating the Python/C glue code by developers or users from a
> Cython source code.
True.
> In addition, it is much easier to maintain the Python/C
On Fri, Nov 30, 2012 at 6:06 AM, Michael Droettboom wrote:
> If you read between the lines of what I was saying, that is basically
> where I fall as well. There seems to be a lot of desire to use Cython
> to make the code more accessible,
I'll add a beat to that drum -- I'm a big Cython fan.
>
20 matches
Mail list logo
