How badly does my SDLx::App code suck?

[Andy Walker]

So, my intent here was to simulate the behavior of a planned array of
LED light circuits.  Simply, the idea was that each one would
occasionally randomly decide to change its color to a random RGB
value.  This would then propogate a 'front' of sorts that could
potentially interact with other fronts in strange and interesting
ways.  This basically works.  The problem is that it seems kind of
slow.  This is a result, no doubt of my only burgeoning understanding
of SDL and the Perl bindings.  As you can probably see, it's based off
of the game of life example in that it uses draw_rect to make a grid
of objects across an SDLx::App surface.  Basically it iterates over a
2D array of datastructures representing each element and renders it.

Is there a better/faster way to be rendering this?  Should I be
blitting? What aspects could be slowing it down significantly?  A
cursory examination with NYTProf revealed that, unsurprisingly, a lot
of time is being spent in draw_rect, though, interestingly, the
highest amount of time is in its call to
SDLx::Validate::_color_arrayref.  Does this mean using an approach
like this:

unpack ('I', pack ('C*', int rand...

to color randomization and comparison would be better, or would
validation still take up a sizable amount of time?

I'm still learning and trying to piece together the right way to do
things from disparate examples, but it's a little difficult, so I
thought I'd ask here.  Please feel free to comment / criticize at
length.

-A


gridtest.pl
Description: Binary data

[Fwd: Re: How badly does my SDLx::App code suck?]

[Kartik Thakore]

Apologies I sent the wrong file out. 
-- 
Kartik Thakore thakore.kar...@gmail.com
---BeginMessage---
SDLx::* is still in the stages of being too slow to use. We have not
optimized the SDLx::Validate in it. 

You can mix with SDL::* to improve your performance, if you are
confident of the validation.

Another things you can do is keep track of what 'LED' changes, and only
update that rect. 

SDL::Video::update_rects( ( SDL::Rect-new(x,y,w,h),  );

I have attached an updated script.

Regards,
Kartik Thakore 

On Tue, 2010-10-12 at 10:56 -0400, Andy Walker wrote:
 So, my intent here was to simulate the behavior of a planned array of
 LED light circuits.  Simply, the idea was that each one would
 occasionally randomly decide to change its color to a random RGB
 value.  This would then propogate a 'front' of sorts that could
 potentially interact with other fronts in strange and interesting
 ways.  This basically works.  The problem is that it seems kind of
 slow.  This is a result, no doubt of my only burgeoning understanding
 of SDL and the Perl bindings.  As you can probably see, it's based off
 of the game of life example in that it uses draw_rect to make a grid
 of objects across an SDLx::App surface.  Basically it iterates over a
 2D array of datastructures representing each element and renders it.
 
 Is there a better/faster way to be rendering this?  Should I be
 blitting? What aspects could be slowing it down significantly?  A
 cursory examination with NYTProf revealed that, unsurprisingly, a lot
 of time is being spent in draw_rect, though, interestingly, the
 highest amount of time is in its call to
 SDLx::Validate::_color_arrayref.  Does this mean using an approach
 like this:
 
 unpack ('I', pack ('C*', int rand...
 
 to color randomization and comparison would be better, or would
 validation still take up a sizable amount of time?
 
 I'm still learning and trying to piece together the right way to do
 things from disparate examples, but it's a little difficult, so I
 thought I'd ask here.  Please feel free to comment / criticize at
 length.
 
 -A

-- 
Kartik Thakore thakore.kar...@gmail.com


gridtest.pl
Description: Perl program
---End Message---


gridtest.pl
Description: Perl program