Edgar Simo      2011-02-20 09:02:31 PST

Linux uses fname, which is the name of the device path like for example
/dev/input/event3 so it shouldn't have the issue. However I can confirm that it
looks like haptic->index never gets properly set on windows. Have to look at
mac os x also. I'll see if I can fix it real quick now.

Cleaned up dependencies on generating SDL_revision.h
Fixed 'make install' if you are not building from a Mercurial repository

(See mailing list message with subject "Streaming textures not properly initialized?")

Don't remove the pseudo-generated headers because this command might be run from the repo directory and it confuses people, especially if they have no way of regenerating SDL_revision.h :)

Our minimum Windows version is Windows 2000, so it's okay to directly call InitializeCriticalSectionAndSpinCount()..

 Patrick Baggett      2011-02-16 22:58:33 PST

This enhancement is for both x86/x64 Windows.

The SDL implementation of mutexes uses the Win32 API interprocess
synchronization primitive called a "Mutex". This implementation is subpar
because it has a much higher overhead than an intraprocess mutex. The exact
technical details are below, but my tests have shown that for reasonably high
contention (10 threads on 4 physical cores), it has 13x higher overhead than
the Win32 CriticalSection API.

If this enhancement is accepted, I will write a patch to implement SDL mutexes
using the critical section API, which should dramatically reduce overhead and
improve scalability.


-- Tech details --
Normally, Win32 Mutexes are used across process boundaries to synchronize
separate processes. In order to lock or unlock them, a user->kernel space
transition is necessary, even in the uncontented case on a single CPU machine.
Win32 CriticalSection objects can only be used within the same process virtual
address space and thus to lock one, does not require a user->kernel space
transition for the uncontended case, and additionally may spin a short while
before going into kernel wait. This small spin allows a thread to obtain the
lock if the mutex is released shortly after the thread starts spinning, in
effect bypassing the overhead of user->kernel space transition which has higher
overhead than the spinning itself.

--HG--
rename : include/SDL_keysym.h => include/SDL_keycode.h

Even if we're blitting between two different surfaces their pixels might still overlap, because of SDL_CreateRGBSurfaceFrom(), so always use SDL_BlitCopy() and check for overlap in that function.

When handling overlapping surfaces, don't assume that memcpy() iterates forward, instead use memmove() correctly, and provide a fallback implementation of SDL_memmove() that handles the different cases.

Fixed a bug with SDL_memset() not completely filling lengths that aren't a multiple of 4.
Optimized SDL_memcpy() a bit using the same technique as SDL_memset().