Guillaume Proux | 1 Jan 07:59 2006
Picon

Re: converting byte image for display

Ouch!

def to_bw(rawbuffer):
   retstr=''
   for e in rawbuffer :
       retstr = retstr + e*3
   return retstr

This is a typical slow usage of string concat.
the same loop would be much quicker execute like this

bwbuffer = "".join(map(lambda x:x*3,rawbuffer))

Guillaume

Trevor Fancher | 2 Jan 02:53 2006

Re: converting byte image for display


On Jan 1, 2006, at 12:59 AM, Guillaume Proux wrote:

> Ouch!
>
> def to_bw(rawbuffer):
>    retstr=''
>    for e in rawbuffer :
>        retstr = retstr + e*3
>    return retstr
>
> This is a typical slow usage of string concat.
> the same loop would be much quicker execute like this
>
> bwbuffer = "".join(map(lambda x:x*3,rawbuffer))
>
> Guillaume

Guillaume,

I am a new python coder and found your one-line replacement for veto's
function pretty neat.  So neat I decided to run some benchmarks to see
if it truly is faster.

 From my test it appears veto's original function is faster.  I tested
that with my test_concat function.  I then tested your way with
test_map1 and a way I thought might be a bit faster with test_map2.  As
you can see from the results test_concat seems to have run the fastest.

However, my benchmarking code may be extremely flawed because, as I
(Continue reading)

Simon Wittber | 2 Jan 04:00 2006
Picon

Re: converting byte image for display

On 1/2/06, Trevor Fancher <trevor@...> wrote:
> However, my benchmarking code may be extremely flawed because, as I
> said, I am new to python.  If you don't mind, could you correct my
> benchmarking code or explain why test_concat is running faster?

Benchmarks are fun.

In your test_concat function, you are testing a function call as well
as the concat process. This will add extra time to that benchmark,
which the other benchmarks don't have.

Also, you are using a very small 3 item list for the test. a 320x200
256 color image will have 64000 bytes.

Using

test_list = "a" * 64000
test_count = 100

these were my results:

concat: 6.103
  map1: 6.349
  map2: 6.303

String concantenation used to be quite slow in Python 2.3, but has
since recieved some optimisation.

http://mail.python.org/pipermail/python-list/2004-September/242125.html

(Continue reading)

Trevor Fancher | 2 Jan 05:38 2006

Re: converting byte image for display


On Jan 1, 2006, at 9:00 PM, Simon Wittber wrote:
> Benchmarks are fun.

Sure are.  :)

> In your test_concat function, you are testing a function call as well
> as the concat process. This will add extra time to that benchmark,
> which the other benchmarks don't have.

I noticed this but left the function call in on purpose because that
is what the original poster was going to be doing anyways.

> Also, you are using a very small 3 item list for the test. a 320x200
> 256 color image will have 64000 bytes.
>
> Using
>
> test_list = "a" * 64000
> test_count = 100
>
> these were my results:
>
> concat: 6.103
>   map1: 6.349
>   map2: 6.303
>
> String concantenation used to be quite slow in Python 2.3, but has
> since recieved some optimisation.
>
(Continue reading)

Norbert Sebok | 2 Jan 06:42 2006
Picon

Re: pygame.image.frombuffer problems

> I want a more effecient way of using pygame and pycairo together.

The solution is surprisingly easy and very fast: Cairo can draw
directly to an SDL surface.

I don't know if it's work on every platform, I use it only on Ubuntu
on x86 machines. But maybe it can work everywhere with the help of
SDL_PixelFormat's masks.

The main code in C:

cairo_surface_t *
create_for_sdl_data(SDL_Surface *sdl_surface)
{
   int btpp = 4;
   cairo_format_t format = CAIRO_FORMAT_RGB24;

   unsigned char *data = sdl_surface->pixels;
   int width = sdl_surface->w;
   int height = sdl_surface->h;
   int stride = width * btpp;

   cairo_surface_t* s;
   s = cairo_image_surface_create_for_data (data,format,width,height,stride);
   return s;
}

and in Python it's as easy as:

screen = pygame.display.set_mode((width, height))
(Continue reading)

Guillaume Proux | 2 Jan 07:26 2006
Picon

Re: converting byte image for display

Very nice...

It seems some old tricks do not apply anymore.
In any case, getting rid of function calls in inner loops are always a
good idea even with the newest list comprehension optimizations.

Regards,

Guillaume

Guillaume

On 1/2/06, Trevor Fancher <trevor@...> wrote:
>
> On Jan 1, 2006, at 9:00 PM, Simon Wittber wrote:
> > Benchmarks are fun.
>
> Sure are.  :)
>
>
> > In your test_concat function, you are testing a function call as well
> > as the concat process. This will add extra time to that benchmark,
> > which the other benchmarks don't have.
>
> I noticed this but left the function call in on purpose because that
> is what the original poster was going to be doing anyways.
>
>
> > Also, you are using a very small 3 item list for the test. a 320x200
> > 256 color image will have 64000 bytes.
(Continue reading)

Hannu Kakkori | 2 Jan 19:05 2006
Picon

Re: converting byte image for display

I did also some benchmarking with interesting results.

test_list = "a"*10**6
test_count = 10

con_cat = 29.4 , 1x
map1 = 12.6 , 2.3x
map2 = 12.5, 2.4x
list_com = 4.6, 6,4x

let's add
import psyco
psyco.full()

con_cat = 4.4 , 1x
map1 = 15.6 , 0.28x and 0.8x compared to situation without psyco
map2 = 15.8, 0.28x
list_com = 2.8, 1.6x

psyco + list_com = 10.5x improvement.

Thank you for the help!
--HannuK

On 1/2/06, Guillaume Proux <gproux@...> wrote:
> Very nice...
>
> It seems some old tricks do not apply anymore.
> In any case, getting rid of function calls in inner loops are always a
> good idea even with the newest list comprehension optimizations.
(Continue reading)

Stefan Elwesthal | 3 Jan 18:33 2006

Ocemp

Hi all!

Since there has been some traffic about Ocemp - I would be like to hear some comments about it? ( A standard
WidgetLibrary for pygame would be very nice in my opinion)

I certainly dont know if that should be Ocemp (it doesn't install in Ubuntu since I need to create somekind of
Makefile in /usr/lib/python24 first) but I was going to try the other example in a minute ;-)

So, what's the opinion? Is it even needed?

Regards
Stefan

--

-- 
_______________________________________________
Check out the latest SMS services  <at>  http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.

Powered by Outblaze

Miles Van Pelt | 3 Jan 19:49 2006
Picon

looking for a particle/billiard ball engine

I'm looking to experiment with some simple emergent behavior ideas. Does anyone have a favorite particle simulator, or otherwise know where I can find the source to a simple engine that uses newtonian physics for particle interaction?
 
Miles
Marcus von Appen | 3 Jan 21:22 2006

Re: Ocemp

On, Tue Jan 03, 2006, Stefan Elwesthal wrote:

> Hi all!
> 
> Since there has been some traffic about Ocemp - I would be like to
> hear some comments about it? ( A standard WidgetLibrary for pygame
> would be very nice in my opinion)

Great library, thumbs up ;-).

> I certainly dont know if that should be Ocemp (it doesn't install in
> Ubuntu since I need to create somekind of Makefile in
> /usr/lib/python24 first) but I was going to try the other example in a
> minute ;-)

Tell your ubuntu maintainers, that something is weird then. OcempGUI
uses the default python paradigm of installing itself and does fine on
several systems (on which python is installed properly and not a lousy
splitted package mess).

> So, what's the opinion? Is it even needed?

As project lead of OcempGUI I would say no, not in my opinion. The main
problems I see, are: 

* What kind of GUI engine should be used (Sprite-based, like OcempGUI,
  (Sub)Surface-based like pgu, only implement the logics, etc.pp.)?
* How much GUI features should it incorporate (simple and only the
  minimum basics like S.J. Brown's or Mike Leonhard's or many features
  like pgu or OcempGUI)?
* How much abstraction is wanted?
* How flexible should it be?
* Who will take care of the maintenance?
...

Also any developer using pygame has a different view of how the GUI
should fit into his own scenario, how it should behave, what its
capabilities should be, etc.pp..

Each existing GUI library for pygame has another approach of doing
things, too. Each one has a different development focus. As pygame is
understood as a SDL wrapper with a (nice) basic set of graphics and
multimedia abilities, integrating a GUI would mean: serving the most
necessary parts of it in order to not annoy users with defaults that are
ot wanted or missing features.

A minimalistic set however would lead to a sort of unusable GUI design
as large parts have to be implemented by the user, if he does not want
to stay with the defaults (which mostly will not fit). This in turn would
lead to (some) unhappy users again, who say that the module is
superfluous and so on.

To summarize the said: I think it would lead to more problems and
requests for the pygame developers than it would solve.

Just my two cents.

Regards
Marcus

Gmane