[Gambas-user] gb3 (rev. 3641) and SDL surfaces

[Kevin Fishburne]

On 03/10/2011 05:09 AM, Benoît Minisini wrote:
>> I've been experimenting with gb.sdl and found that I could achieve frame
>> rates higher than 380 fps at 1920x1080, including alpha channel. This
>> involves writing directly to the SDL window/surface with a 1920x1080
>> image loaded from a file, for example:
>>
>> Public Screen As New Window As "Screen"
>> Public SomeImage As Image = Image.Load("someimage.png")
>>
>> Public Sub Main()
>>
>>     ' Create screen.
>>     With Screen
>>       .Width = 1920
>>       .Height = 1080
>>       .Framerate = 1000
>>       .FullScreen = True
>>       .Show()
>>     End With
>>
>> End
>>
>> Public Sub Screen_Draw()
>>
>>     Draw.Image(SomeImage, 0, 0)
>>     Draw.Text(Screen.Framerate&  " FPS", 0, 0)
>>
>> End
>>
>> While this is awesome, there is a problem if images need to be
>> composited before being written to the SDL surface. For example, if I
>> wanted to do something like this:
>>
>> Water.Draw(WaterRipples, 0, 0)
>> Water.Draw(SkyReflection, 0, 0)
>> Water.DrawAlpha(WaterDepth, 0, 0)
>>
>> and then draw Water to the SDL window, not only is the imlib2 component
>> required (otherwise it states the .Draw method is unknown), it kills the
>> frame rate because the Draw method is done in software (imlib2) and only
>> the writes done directly to the SDL window are hardware accelerated.
>>
>> Attempting to circumvent this I created a second SDL window, hoping I
>> could write the contents of window B to window A. The idea was to create
>> multiple secondary SDL windows, using them as image buffers, then write
>> the buffers as necessary to the main SDL window when its Draw event was
>> called. This didn't work at all and I don't think it's supported.
>>
>> Is there a way to use the Draw method, or an equivalent, so that
>> image-to-image writes can be done entirely in SDL? I've already
>> converted my app to use the SDL component but too much of it currently
>> uses the .Draw and .DrawAlpha methods which bring the framerate to 21
>> fps at 1280x720. The framerate is only going to get worse from here, as
>> I'm just getting started.
> I think (only Laurent can confirm) that SDL uses internally OpenGL to do its
> stuff. So the speed of the SDL component depends on the graphics driver (which
> is a very sensible thing on Linux).
>
> Then, if you want to compose images, I think only doing direct OpenGL call
> will help you, by stacking textured rectangles. But I don't know if OpenGL can
> do the equivalent of Draw.Alpha().

That makes sense, as SDL uses OpenGL when available for hardware 
acceleration. I think it's basically a wrapper for OpenGL (or DirectX 
though that is irrelevant obviously). While DrawAlpha is a blessing, the 
main problem is the regular Draw method not being supported by the SDL 
component. As I said drawing directly to the SDL surface is super fast 
but image-to-image drawing is super slow. I have no issue with DrawAlpha 
being maintained in software only, but basic image blitting should 
definitely be supported by the SDL (and by proxy OpenGL) component. I 
wonder if this has something to do with how the images are loaded into 
RAM/VRAM. Without understanding the SDL implementation, it's hard for me 
to imagine why blitting an image to the SDL surface is fast but blitting 
image A to image B is slow. Maybe there's a good reason for that, but it 
seems counter-intuitive to me (story of my life, right?).

-- 
Kevin Fishburne
Eight Virtues
www: http://sales.eightvirtues.com
e-mail: sales at ...1887...
phone: (770) 853-6271