Re: [AD] Add timeBeginPeriod(1) to wtimer.c

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> > Over the weekend I have put a little demo and benchmark program
> > together.
> > Now being almost ready for upload, should I mail it or put it into the
> > forum?
> 
> Maybe do both, but be sure to post it here anyway. I can't currently post
> on ACC anyway, I think there's a problem with the server.
It's up again.

 
> So, just so I understand correctly, there's a slowdown if
> timeBeginPeriod()
> is added in the case of using video/system bitmaps?
> Is this also true if you use timeBeginPeriod to decrease resolution of the
> timer, eg by calling timeBeginPeriod(100)?
Didn't think of 100... 
More experiments: using 10 or more doesn't change the behavior. So there's
an effect only when the requested precision is <10. 

 
> > Bearing this in mind, I would now suggest to not make any changes, but
> > do
> > more investigations actually.
> 
> I agree. That'll make it post 4.2 material though.
So it seems. Sniff. 

When you begin to play around with my program (to be posted on the forum)
then you might also see something of that sort: Having 3000 balls the prog
needs about 10% cpu, 4000 balls result in about 50% cpu (on my 3GHz PC at
work). That is with allegro unchanged. 
No, adding timeBeginPeriod(1) to only the rest() function, 3000 balls use
some 25-30%, but 4000 balls use hardly more than 30% also. 
It's this kind of non-linear behavior which I find most irritating here... 


> > For example, there no word about the type of bitmap which is returned
> > from load_bitmap, so I was thinking it should be a system bitmap really.
> 
> Hmm... I'm not sure. This actually only makes a difference in Windows, as
> far as I know, so other platforms wouldn't really care anyway. For me it's
> somewhat logical that it loads into memory without being told to do
> otherwise - and there not being a way to do that means it always loads to
> memory.
> Well, different discussion anyway.
It might simply be the dcase that the type flags of the BITMAP returned from
load_bitmap are not properly set: The ->id was 0 in my debugger. But that
means that different code is executed in draw_sprite... 


> > One question is, why does draw_sprite need so many critical sections?
> > Just
> > wondering. I saw n calls to draw_sprite call 3*n times
> > EnterCritialSection
> > and LeaveCriticalSection.
> 
> I'm not sure... someone who knows about the Windows code should probably
> have a look at it and be able to tell more. Other than that, perhaps it
> can
> be optimized by rearranging some instructions.


Tobias 




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/