[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] pygame.pixelcopy.array_to_surface(Dest, Src) not working



On 27 December 2016 at 18:51, Ian Mallett <ian@xxxxxxxxxxxxxx> wrote:
 
Most interesting that 1. method with buffer write seems to be always faster
than others, by ca. 5%. Not a big win, but still interesting...
And if I try it with FORTRAN order, it becomes 2 times slower!
​I'm not sure I fully parse what you're doing here. As long as it's safe, copying buffers should be slightly faster since it's 1D--maybe the buffer API is smart enough to step in larger chunks that might potentially straddle a scanline, and you also have one fewer loop variable. When you try it with FORTRAN order, to produce a buffer of the same format would require an allocation and then a copy, so that's probably why it's slower.

The NumPy internals has salient things to say on this issue.

Good article, it explains good what I observe. And that is right, pixelcopy
seems to do much more checking, I think I saw 4 different error messages
when I was trying different inputs.


So I would still look forward to having methods dealing with C order,
just to avoid writing extra transposing and full compliance
with default numpy notation.

Any comments or opinions about it?
It would be good to know first, which of those things
people use more often and make some use case examples.
​Personally, I would like C order just because it's "expected" in graphics*. Under this assumption, I wrote all my code e.g. looping over "y" first, using the buffer API for GL interop, etc. This is optimal in the C order every graphics programmer would expect, but in FORTRAN order, it's exactly wrong. I never profiled both options because it's a nearly fundamental assumption.

Agreed, also one who is already familiar with Numpy, or e.g. OpenCV
is already got used to [y,x] notation, so from many sides,
it would be logical to use C order for array-surface ingest.
 

I mean, it's not terribly important. Python is not a fast language. One writes stuff in Python because your program running 5x/50x slower is a non-issue and you want the expressivity. But free perf is free, so it's a bit annoying.

Yes this is a big dilemma. There is an opinion, one should make
everything in C/+, and most industry-level products are done so.
But seriously, I can hardly see the *code* behind all those brackets,
asterisks, cryptic expressions. So for me it is almost no-go,
but as a grafic-man I am just too sensitive to these things :)

I see there is a good solution to all this: one needs a nice tool,
namely an IDE with refined simple syntax,
which produces C-compilable code. I mean if one
concentrates around this, it is not that hard to make.
Strangely I don't find much exactly related projects, one attempt
probably is SDL Basic. Cython is related, but not exactly.

This idea floats for years in air, hmm, what
could be preventing it, I wonder. I mean I don't even
consider myself a professional programmer, but it
seems, making a toy-prototype of such IDE is
a question of several months of "free evenings" job.
And actually to make such a tool, even Python+Pygame would
be totally adequate, since it does not need to be
so performant as a complex game.


Mikhail