Also experimented with texture rectangle updates, but I think at this point the full rect update gives the most consistent results.

Switched the SDL 1.2 compatibility to use the window surface, so it's fast even when there's no hardware acceleration available.
This means that the YUV overlay now uses software, but that's okay since fast YUV code should be using the textures now anyway.

Added a way to get a framebuffer interface for a window, and also a way to create a software renderer for an arbitrary surface.
The software renderer has been re-routed to use the framebuffer interface, which makes it possible to have software rendering available even on simple ports.

--HG--
rename : src/video/SDL_blendline.c => src/render/software/SDL_blendline.c
rename : src/video/SDL_blendpoint.c => src/render/software/SDL_blendpoint.c
rename : src/video/SDL_draw.h => src/render/software/SDL_draw.h
rename : src/video/SDL_drawline.c => src/render/software/SDL_drawline.c
rename : src/video/SDL_drawpoint.c => src/render/software/SDL_drawpoint.c

This allows me to reduce the set of formats supported by the renderers to the most optimal set, for a nice speed boost.

--HG--
rename : src/video/SDL_yuv_mmx.c => src/render/SDL_yuv_mmx.c
rename : src/video/SDL_yuv_sw.c => src/render/SDL_yuv_sw.c
rename : src/video/SDL_yuv_sw_c.h => src/render/SDL_yuv_sw_c.h
rename : src/video/mmx.h => src/render/mmx.h

Moved the rendering code out to a separate directory in the hope that it can someday be completely decoupled from the rest of the library and be expanded to an awesome 2D on 3D library.

--HG--
rename : src/video/windows/SDL_d3drender.c => src/render/direct3d/SDL_d3drender.c
rename : src/video/SDL_renderer_gl.c => src/render/opengl/SDL_renderer_gl.c
rename : src/video/SDL_renderer_gles.c => src/render/opengles/SDL_renderer_gles.c
rename : src/video/SDL_renderer_sw.c => src/render/software/SDL_renderer_sw.c

The rendering functions take a context so it's clear what window they're drawing to.  This also potentially opens to the door to multi-threaded rendering in the future.

Making the API simpler, the renderer present semantics are always having a backbuffer and then discarding it.  This is best for hardware accelerated rendering.

--HG--
extra : rebase_source : bbe6641fce097c79ccd47f4e1ea6b27683fd0acb

--HG--
extra : rebase_source : 880752438aae8f6526503d220bad91aabc3a7d1c

--HG--
extra : rebase_source : f06ea01caa64c8ad14170c723e5af52dad64d779

--HG--
extra : rebase_source : d00f0590e133604070f978762a6728b4afde02ca

Making the API simpler, scaling is always defined as linear interpolation and should be supported as much as possible on all renderers.

--HG--
extra : rebase_source : 4edac7fd162a2eb37a50159b958db37a03e944a5

--HG--
extra : rebase_source : 3fc2560c02393bf9e7c46360fc24f2585c9409be

 Vittorio Giovara      2011-02-01 02:25:48 PST

i have attached an updated patch that fixes this behaviour