Vittorio Giovara 2010-07-16 19:09:28 PDT
i was reading SDL_renderer_gles and i noticed that every time we there
is some gl call the gl state is modified with a couple of
glEnableClientState()/glDisableClientState.
While this is completely fine for desktops systems, this is a major
performace kill on mobile devices, right where opengles is
implemented.
Normal practice in this case is to update the glstate once, keep it
always the same and disable/enable other states only in very special
occasions.
On the web there's plenty of documentation (on the top of my head
http://developer.apple.com/iphone/library/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/Performance/Performance.html#//apple_ref/doc/uid/TP40008793-CH105-SW5
) and i personally tried this.
I modified my code and got a 10 fps boost, then modified SDL_render_gles and
shifted from 40 fps to 50 fps alone -- considering that i started from ~30fps i
got an 80% performance increase with this technique.
I have attached a dif of my changes, hope that it will be included in
mainstream.
pelya 2010-07-21 04:54:41 PDT
GLES_UpdateTexture() ignores pitch value, because of that some textures created
with SDL_CreateTextureFromSurface() are drawn incorrectly, especially if image
width is not multiplier of 2.
Vittorio Giovara 2010-07-17 19:21:36 PDT
fix the double free error
in SDL_uikitview the variable 'textfield' is initialialized and set to
autorelease.
however in the dealloc method a second [release] is sent.
If the textfield has not been set to nil before (with a viewDidUnload for
example) this can lead to awful hard-to-find crashes when the SDL code
terminates.
the error message is
-[textfield release] message sent to deallocated instance 0x4e5fa90
the fix is simple, just release the object as soon as it is added to the
subview, see attached patch
The are no event handlers for the middle mouse button, right mouse buttons, and
mouse wheel in the latest HG revision 4636. It has been like this for 3 months.
I made a patch for this, though I'm not sure if the Xbutton or mouse wheel code
is "correct" by your standards.
in SDL 1.3 (revision 5508 from SVN), the method used to calculate the
bits per pixel from a “int format” differ between “SDL_ListModes” (which
always uses the “SDL_BITSPERPIXEL” macro) and “SDL_PixelFormatEnumTo-
Masks” (which uses either “SDL_BITSPERPIXEL” or “SDL_BYTESPERPIXEL * 8”,
depending on the value of “SDL_BYTESPERPIXEL”).
Because the values are later compared in “SDL_ListModes” this may lead
to some valid video modes not being returned. In my case the only mode
returned by “SDL_GetNumDisplayModes” was dismissed and NULL was
returned. (This led to the calling application sticking its head in the
sand.)
The attached patch copies the method used within “SDL_PixelFormatEnumTo-
Masks” to “SDL_ListModes”. This solved the problem for me though I don't
fully understand the method used by “SDL_PixelFormatEnumToMasks”.
I *think* the patch below works correctly: sdl-config gets the -march
flag and SDL builds fine. Perhaps there's a better way to get the
-march flag into both CFLAGS and SDL_FLAGS w/o dragging along more
cruft, but adding it to BASE_CFLAGS seemed the best bet to my eyes.
This allows all SDL code to take advantage of the atomic intrinsics on Windows, but doesn't cause applications just including SDL.h to pull in windows.h
Changed the CAS return value to bool, so it's efficient with OSAtomicCompareAndSwap32Barrier()
Added an atomic test adapted from code by Michael Davidsaver
