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.

> So, having done a lot of experiments, including investigations with
> Rational
> Quantify, I'm now utterly confused about the effects of putting
> timeBeginPeriod(ticks) into
> a) tim_win32_rest()
> and
> b) tim_win32_high_perf_thread
> and maybe even both, with ticks being some numbers e.g. 1, 5 or 10.
> Program
> behaviour is absolutely crazy.

Thanks for being so thorough!

> There's one thing I discovered by debugging into draw_sprite: When I use
> the
> result of load_bitmap, then that bitmap is neither system nor video
> bitmap.
> So drawing is then implemented differently, compared to creating a
> system
> bitmap and blitting the result of load_bitmap into that. So, when I do
> it
> that way, the program is fastest and always suffers slowdown from adding
> any
> timeBeginPeriod(anything) anywhere.

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)?

> 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.

> 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.

> 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.

Evert




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