[SDL] SDL_RenderClear not clearing entire render target

Dark_Oppressor DarkOppressor at gmail.com
Thu Oct 17 16:35:33 PDT 2013


On Sat, Oct 05, 2013 at 06:34:30PM +0000, Trev wrote:
>> … Isn't the point of SDL to achieve portability?
>>
>> If you're already using Cocoa and ObjectiveC, why use SDL's (C-based)
>> threading at all?  You've already got things like Grand Central and
>> OpenCL in addition to NSThread and friends.  I don't know why you'd
>> be using SDL's threading given that.
>>
>> A portable app written in C or C++ would use SDL's threads, in which
>> case there are lots of examples and guides.  I just have no idea why
>> you'd be trying to use SDL's threads in a Cocoa app.
>>
>Well, I am trying to make things portable (as much as possible) and that's why I want to use SDL's threading as much as possible. But as I understand it, if I use any functions that require the autorelease pool within a thread, I also need the additional step of making and clearing an autorelease pool for the cocoa version of my app. Always, there is the intent to make things as system independent as possible, and that's why I'm using SDL, but occasionally, some parts just need operating-specific code.

I grabbed the iOS documentation (mostly because the link was ranked 
ever so slightly higher than the OS X version in my search results, 
but what I found was this:

https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmAutoreleasePools.html#//apple_ref/doc/uid/20000047-1041876

It's a good bet that OS X will do it exactly the same way.


IMO the proper way to mix Cocoa and SDL is:

If the app is primarily a Cocoa app and uses SDL as a relatively easy 
way to get at video and typical game hardware, then your threading 
should be done in Cocoa and SDL should run in one thread.

If your app is primarily SDL-based, but you need to provide some 
Cocoa UI elements for a clean and integrated interface on the 
platform, SDL should do all of the multithreading and Cocoa should 
run in one of those threads.

I wouldn't try to mix multithreaded Cocoa and multithreaded SDL if I 
could find any reasonable alternative to doing it.  SDL abstracts 
every aspect of the system it supports into a portable form.  The 
only thing it cannot do is handle the system Cocoa toolkit (in any 
meaningful way), beyond the lowest common denominator for pasteboard 
and drop objects, integration with services, etc.  These are all UI 
issues.  If your app is behaving itself in all other threads in a 
portable fashion, one thread ought to be able to handle the 
interfacing.

But to answer your question, yeah, you pretty much have to manage the 
autorelease pool for each subthread that wants to use one or you're 
going to leak objects.

Joseph




More information about the SDL mailing list