Dear Eric and Ryan and list,
I’ve been playing with SDL_image on iOS for some time and if possible
I would like to make two requests that would beneficially impact the
development experience.
The first one is to directly add the xcode-ios project file and folder
without compresisng it in a tar bundle: this makes changes easier to
track than ‘binary file differs’ and would allow for patches and
modification to the build system more widely deployable.
The second one is a feature request to make it so that when the
ImageIO framework is not present the library would fallback to the
UIImage backend; although it would perhaps make backporting a little
difficult I am sure that there is still a lot of software targeting
pre-ios 4 that could make use of it.
I hope that these suggestions sound reasonable and that could be added
without problems.
Thanks for your time spent on sdl libraries
Vittorio
Dear Eric and Ryan and list,
I’ve been playing with SDL_image on iOS for some time and if possible
I would like to make two requests that would beneficially impact the
development experience.
The first one is to directly add the xcode-ios project file and folder
without compresisng it in a tar bundle: this makes changes easier to
track than ‘binary file differs’ and would allow for patches and
modification to the build system more widely deployable.
Yes, I think Sam and I spoke about this one a few times. I thought the
1.3 branch put the project directly into the repo instead of a tar.
The second one is a feature request to make it so that when the
ImageIO framework is not present the library would fallback to the
UIImage backend; although it would perhaps make backporting a little
difficult I am sure that there is still a lot of software targeting
pre-ios 4 that could make use of it.
It’s possible, and not entirely unreasonable, but iOS moves so fast
that I haven’t felt it really merited the extra effort to do so. My
experience is that there isn’t a lot of interest in 3.x. I have a
3.1.3 device and there are actually very few apps (that I would be
interested in getting) that support 3.x any more and I have to be very
careful to no upgrade my existing apps because the new versions don’t
work on my device any more. I think the percentage of devices 3.x is
less than 10% now. Testing old devices is another difficulty. And if
you need to start weak linking frameworks in the Xcode project, you go
into areas most non Apple developers don’t know about.
-EricOn 10/26/11, Vittorio G. <vitto.giova at yahoo.it> wrote:
The first one is to directly add the xcode-ios project file and folder
without compresisng it in a tar bundle: this makes changes easier to
track than ‘binary file differs’ and would allow for patches and
modification to the build system more widely deployable.
I totally agree with this, and would have done it already if I didn’t
make it a point to avoid all the add-on libraries.
The first one is to directly add the xcode-ios project file and folder
without compresisng it in a tar bundle: this makes changes easier to
track than ‘binary file differs’ and would allow for patches and
modification to the build system more widely deployable.
I totally agree with this, and would have done it already if I didn’t
make it a point to avoid all the add-on libraries.
Dear Eric and Ryan and list,
I’ve been playing with SDL_image on iOS for some time and if possible
I would like to make two requests that would beneficially impact the
development experience.
The first one is to directly add the xcode-ios project file and folder
without compresisng it in a tar bundle: this makes changes easier to
track than ‘binary file differs’ and would allow for patches and
modification to the build system more widely deployable.
Yes, I think Sam and I spoke about this one a few times. I thought the
1.3 branch put the project directly into the repo instead of a tar.
I saw that it’s just been added, so thanks Ryan!
The second one is a feature request to make it so that when the
ImageIO framework is not present the library would fallback to the
UIImage backend; although it would perhaps make backporting a little
difficult I am sure that there is still a lot of software targeting
pre-ios 4 that could make use of it.
It’s possible, and not entirely unreasonable, but iOS moves so fast
that I haven’t felt it really merited the extra effort to do so. My
experience is that there isn’t a lot of interest in 3.x. I have a
3.1.3 device and there are actually very few apps (that I would be
interested in getting) that support 3.x any more and I have to be very
careful to no upgrade my existing apps because the new versions don’t
work on my device any more. I think the percentage of devices 3.x is
less than 10% now. Testing old devices is another difficulty. And if
you need to start weak linking frameworks in the Xcode project, you go
into areas most non Apple developers don’t know about.
-Eric
I see your point, iOS is a much faster platform than OSX and a lot of
applications are dropping support for 3.* devices, however I feel that
as SDL is a compatibility layer between architectures it should be as
compatible as possible, until major api change or build system make it
impossible/unbearable to keep it updated.
Having said that I am proposing a solution that should keep SDL_image
compatible with both the newer ImageIO for ios4 and osx and allow us
to use uiimage on ios3: what I am linking is a merge of
IMG_UIImage.m and IMG_ImageIO.c and the small changes that need to be
applied to the related xcode project files).
IMG_ImageIO.m contains a brutal check to determine wheter we are on
ios4 (where we know that ImageIO is available) through the following
([NSClassFromString(@“UIImage”)
instancesRespondToSelector:@selector(initWithCGImage:scale:orientation:)]
== NO)
It might be not that nice, but it works great!
Then in the application it is sufficient to weaklink ImageIO to be
able to use SDL_image on ios3.*. On OSX the uiimage part has been
ifdef’d away, but you need to add the Foundation framework in the
project file to be able to compile it.
In the uiimage layer only the tga loading is missing (as it is in IMG_tga.c).
What do you think of this solution? Could it be added mainstream?
Best
VittorioOn Wed, Oct 26, 2011 at 10:32 PM, Eric Wing wrote:
On 10/26/11, Vittorio G. <vitto.giova at yahoo.it> wrote:
IMG_ImageIO.m contains a brutal check to determine wheter we are on
ios4 (where we know that ImageIO is available) through the following
([NSClassFromString(@“UIImage”)
instancesRespondToSelector:@selector(initWithCGImage:scale:orientation:)]
== NO)
It might be not that nice, but it works great!
Then in the application it is sufficient to weaklink ImageIO to be
able to use SDL_image on ios3.*. On OSX the uiimage part has been
ifdef’d away, but you need to add the Foundation framework in the
project file to be able to compile it.
In the uiimage layer only the tga loading is missing (as it is in
IMG_tga.c).
What do you think of this solution? Could it be added mainstream?
Best
Vittorio
Here’s my picky feedback/review on your patch.
First, USE_UIIMAGE_BACKEND should look like a function, e.g.
USE_UIIMAGE_BACKEND() similar to UI_USER_INTERFACE_IDIOM() because if
you misuse it as a compile time check instead of a runtime check, you
are asking for trouble (e.g. autorelease pool leaks). The function
look at least makes it more consistent with what Apple does.
Second, I think your USE_UIIMAGE_BACKEND() should always be inside the #if (TARGET_OS_IPHONE == 1) || (TARGET_IPHONE_SIMULATOR == 1)
blocks because UIImage is iOS only and never Mac.
Third, I think there should yet another preprocessor macro that must
be defined by the user if they want this fallback code. This could be
rolled into the USE_UIIMAGE_BACKEND() macro itself, but the ability
should be there. For example, the UIImage RWops code really sucks and
may not be something developers want to fallback/rely on. In addition,
I think the developers must consciously opt-in to this feature anyway
because they must consciously weak link frameworks. I don’t think we
should make developers pay for the extra (though minor) code bloat if
they don’t want to support it (this is the more common case). Most
developers don’t have the ability to test 3.x devices any more. I
guarantee you that the majority of developers will not know about weak
linking and how to do it, and they will not test on a 3.x device. So
instead, they are going to get nasty App Store reviews from the few
3.x users still out there about how their app crashes.
Fourth, I think the UIImage and ImageIO pieces should be put into
separate, isolated function calls just to make future code maintenance
a little simpler.
Hi Eric,
I have update ImageIO.m with your suggestions and added an exception
in case a 3.* device tries to use SDL_Image without UIImage support.
I’ll let you evalute the level of opting out I implemented, with the
currect configuration you just neet to disable the "unused function"
warning in the osx project file to avoid warnings.
Best,
VittorioOn Fri, Oct 28, 2011 at 7:50 PM, Eric Wing wrote:
IMG_ImageIO.m contains a brutal check to determine wheter we are on
ios4 (where we know that ImageIO is available) through the following
([NSClassFromString(@“UIImage”)
instancesRespondToSelector:@selector(initWithCGImage:scale:orientation:)]
== NO)
It might be not that nice, but it works great!
Then in the application it is sufficient to weaklink ImageIO to be
able to use SDL_image on ios3.*. On OSX the uiimage part has been
ifdef’d away, but you need to add the Foundation framework in the
project file to be able to compile it.
In the uiimage layer only the tga loading is missing (as it is in
IMG_tga.c).
What do you think of this solution? Could it be added mainstream?
Best
Vittorio
Here’s my picky feedback/review on your patch.
First, USE_UIIMAGE_BACKEND should look like a function, e.g.
USE_UIIMAGE_BACKEND() similar to UI_USER_INTERFACE_IDIOM() because if
you misuse it as a compile time check instead of a runtime check, you
are asking for trouble (e.g. autorelease pool leaks). The function
look at least makes it more consistent with what Apple does.
Second, I think your USE_UIIMAGE_BACKEND() should always be inside the #if (TARGET_OS_IPHONE == 1) || (TARGET_IPHONE_SIMULATOR == 1)
blocks because UIImage is iOS only and never Mac.
Third, I think there should yet another preprocessor macro that must
be defined by the user if they want this fallback code. This could be
rolled into the USE_UIIMAGE_BACKEND() macro itself, but the ability
should be there. For example, the UIImage RWops code really sucks and
may not be something developers want to fallback/rely on. In addition,
I think the developers must consciously opt-in to this feature anyway
because they must consciously weak link frameworks. I don’t think we
should make developers pay for the extra (though minor) code bloat if
they don’t want to support it (this is the more common case). Most
developers don’t have the ability to test 3.x devices any more. I
guarantee you that the majority of developers will not know about weak
linking and how to do it, and they will not test on a 3.x device. So
instead, they are going to get nasty App Store reviews from the few
3.x users still out there about how their app crashes.
Fourth, I think the UIImage and ImageIO pieces should be put into
separate, isolated function calls just to make future code maintenance
a little simpler.
Hi Vittorio,
I just wanted to you to know I haven’t forgotten about this. You
caught me in the middle of a busy period. Superficially, I think the
changes look good. I hope maybe to get a better look at this after
this week.
I don’t know if you’ve been following the other thread about pixel
color accuracy with ImageIO. That is the other thing that may affect
this patch (though probably only trivially). If you have some interest
and time, I would be interested in hearing how that change I proposed
actually works. The people complaining about it never wrote back.
Thanks,
EricOn 10/29/11, Vittorio Giovara <vitto.giova at yahoo.it> wrote:
Hi Eric,
I have update ImageIO.m with your suggestions and added an exception
in case a 3.* device tries to use SDL_Image without UIImage support.
I’ll let you evalute the level of opting out I implemented, with the
currect configuration you just neet to disable the "unused function"
warning in the osx project file to avoid warnings.
On Fri, Oct 28, 2011 at 7:50 PM, Eric Wing <@Eric_Wing> wrote:
IMG_ImageIO.m contains a brutal check to determine wheter we are on
ios4 (where we know that ImageIO is available) through the following
([NSClassFromString(@“UIImage”)
instancesRespondToSelector:@selector(initWithCGImage:scale:orientation:)]
== NO)
It might be not that nice, but it works great!
Then in the application it is sufficient to weaklink ImageIO to be
able to use SDL_image on ios3.*. On OSX the uiimage part has been
ifdef’d away, but you need to add the Foundation framework in the
project file to be able to compile it.
In the uiimage layer only the tga loading is missing (as it is in
IMG_tga.c).
What do you think of this solution? Could it be added mainstream?
Best
Vittorio
Here’s my picky feedback/review on your patch.
First, USE_UIIMAGE_BACKEND should look like a function, e.g.
USE_UIIMAGE_BACKEND() similar to UI_USER_INTERFACE_IDIOM() because if
you misuse it as a compile time check instead of a runtime check, you
are asking for trouble (e.g. autorelease pool leaks). The function
look at least makes it more consistent with what Apple does.
Second, I think your USE_UIIMAGE_BACKEND() should always be inside the #if (TARGET_OS_IPHONE == 1) || (TARGET_IPHONE_SIMULATOR == 1)
blocks because UIImage is iOS only and never Mac.
Third, I think there should yet another preprocessor macro that must
be defined by the user if they want this fallback code. This could be
rolled into the USE_UIIMAGE_BACKEND() macro itself, but the ability
should be there. For example, the UIImage RWops code really sucks and
may not be something developers want to fallback/rely on. In addition,
I think the developers must consciously opt-in to this feature anyway
because they must consciously weak link frameworks. I don’t think we
should make developers pay for the extra (though minor) code bloat if
they don’t want to support it (this is the more common case). Most
developers don’t have the ability to test 3.x devices any more. I
guarantee you that the majority of developers will not know about weak
linking and how to do it, and they will not test on a 3.x device. So
instead, they are going to get nasty App Store reviews from the few
3.x users still out there about how their app crashes.
Fourth, I think the UIImage and ImageIO pieces should be put into
separate, isolated function calls just to make future code maintenance
a little simpler.
Hi Vittorio,
I didn’t forget about this, just been way too busy
I finally looked it over in greater detail. Overall it looks good.
Minor nitpicks:
Internal_checkImageIOisAvailable returning 0 instead of 1 through me
for a loop…took my brain a little bit to process, but I see how it
works.
The rename of ImageIO.c to ImageIO.m will require the Mac build
systems to also be modified. (Though I see you have a diff for the
Xcode projects earlier up…the Makefile build system may need to be
updated too…though I’m not totally sure about that. I tend to
neglect that one too )
On Mac, the *_UIImage functions yield ‘unused function’ warnings.
But those issues aside, I’m comfortable with putting this in the core
if it isn’t there already. Sam, Ryan?
Thanks,
Eric
But nitpicks aside, I guess we canOn 11/6/11, Eric Wing <@Eric_Wing> wrote:
Hi Vittorio,
I just wanted to you to know I haven’t forgotten about this. You
caught me in the middle of a busy period. Superficially, I think the
changes look good. I hope maybe to get a better look at this after
this week.
I don’t know if you’ve been following the other thread about pixel
color accuracy with ImageIO. That is the other thing that may affect
this patch (though probably only trivially). If you have some interest
and time, I would be interested in hearing how that change I proposed
actually works. The people complaining about it never wrote back.
Thanks,
Eric
On 10/29/11, Vittorio Giovara <vitto.giova at yahoo.it> wrote:
Hi Eric,
I have update ImageIO.m with your suggestions and added an exception
in case a 3.* device tries to use SDL_Image without UIImage support.
I’ll let you evalute the level of opting out I implemented, with the
currect configuration you just neet to disable the "unused function"
warning in the osx project file to avoid warnings.
On Fri, Oct 28, 2011 at 7:50 PM, Eric Wing <@Eric_Wing> wrote:
IMG_ImageIO.m contains a brutal check to determine wheter we are on
ios4 (where we know that ImageIO is available) through the following
([NSClassFromString(@“UIImage”)
instancesRespondToSelector:@selector(initWithCGImage:scale:orientation:)]
== NO)
It might be not that nice, but it works great!
Then in the application it is sufficient to weaklink ImageIO to be
able to use SDL_image on ios3.*. On OSX the uiimage part has been
ifdef’d away, but you need to add the Foundation framework in the
project file to be able to compile it.
In the uiimage layer only the tga loading is missing (as it is in
IMG_tga.c).
What do you think of this solution? Could it be added mainstream?
Best
Vittorio
Here’s my picky feedback/review on your patch.
First, USE_UIIMAGE_BACKEND should look like a function, e.g.
USE_UIIMAGE_BACKEND() similar to UI_USER_INTERFACE_IDIOM() because if
you misuse it as a compile time check instead of a runtime check, you
are asking for trouble (e.g. autorelease pool leaks). The function
look at least makes it more consistent with what Apple does.
Second, I think your USE_UIIMAGE_BACKEND() should always be inside the #if (TARGET_OS_IPHONE == 1) || (TARGET_IPHONE_SIMULATOR == 1)
blocks because UIImage is iOS only and never Mac.
Third, I think there should yet another preprocessor macro that must
be defined by the user if they want this fallback code. This could be
rolled into the USE_UIIMAGE_BACKEND() macro itself, but the ability
should be there. For example, the UIImage RWops code really sucks and
may not be something developers want to fallback/rely on. In addition,
I think the developers must consciously opt-in to this feature anyway
because they must consciously weak link frameworks. I don’t think we
should make developers pay for the extra (though minor) code bloat if
they don’t want to support it (this is the more common case). Most
developers don’t have the ability to test 3.x devices any more. I
guarantee you that the majority of developers will not know about weak
linking and how to do it, and they will not test on a 3.x device. So
instead, they are going to get nasty App Store reviews from the few
3.x users still out there about how their app crashes.
Fourth, I think the UIImage and ImageIO pieces should be put into
separate, isolated function calls just to make future code maintenance
a little simpler.
Hi Vittorio,
I didn’t forget about this, just been way too busy
I finally looked it over in greater detail. Overall it looks good.
Minor nitpicks:
Internal_checkImageIOisAvailable returning 0 instead of 1 through me
for a loop…took my brain a little bit to process, but I see how it
works.
The rename of ImageIO.c to ImageIO.m will require the Mac build
systems to also be modified. (Though I see you have a diff for the
Xcode projects earlier up…the Makefile build system may need to be
updated too…though I’m not totally sure about that. I tend to
neglect that one too )
On Mac, the *_UIImage functions yield ‘unused function’ warnings.
But those issues aside, I’m comfortable with putting this in the core
if it isn’t there already. Sam, Ryan?
Thanks,
Eric
But nitpicks aside, I guess we can
On 11/6/11, Eric Wing wrote:
Hi Vittorio,
I just wanted to you to know I haven’t forgotten about this. You
caught me in the middle of a busy period. Superficially, I think the
changes look good. I hope maybe to get a better look at this after
this week.
I don’t know if you’ve been following the other thread about pixel
color accuracy with ImageIO. That is the other thing that may affect
this patch (though probably only trivially). If you have some interest
and time, I would be interested in hearing how that change I proposed
actually works. The people complaining about it never wrote back.
Thanks,
Eric
On 10/29/11, Vittorio Giovara <vitto.giova at yahoo.it> wrote:
Hi Eric,
I have update ImageIO.m with your suggestions and added an exception
in case a 3.* device tries to use SDL_Image without UIImage support.
I’ll let you evalute the level of opting out I implemented, with the
currect configuration you just neet to disable the "unused function"
warning in the osx project file to avoid warnings.
IMG_ImageIO.m contains a brutal check to determine wheter we are on
ios4 (where we know that ImageIO is available) through the following
([NSClassFromString(@“UIImage”)
instancesRespondToSelector:@selector
(initWithCGImage:scale:orientation:)]
== NO)
It might be not that nice, but it works great!
Then in the application it is sufficient to weaklink ImageIO to be
able to use SDL_image on ios3.*. On OSX the uiimage part has been
ifdef’d away, but you need to add the Foundation framework in the
project file to be able to compile it.
In the uiimage layer only the tga loading is missing (as it is in
IMG_tga.c).
What do you think of this solution? Could it be added mainstream?
Best
Vittorio
Here’s my picky feedback/review on your patch.
First, USE_UIIMAGE_BACKEND should look like a function, e.g.
USE_UIIMAGE_BACKEND() similar to UI_USER_INTERFACE_IDIOM() because if
you misuse it as a compile time check instead of a runtime check, you
are asking for trouble (e.g. autorelease pool leaks). The function
look at least makes it more consistent with what Apple does.
Second, I think your USE_UIIMAGE_BACKEND() should always be inside the #if (TARGET_OS_IPHONE == 1) || (TARGET_IPHONE_SIMULATOR == 1)
blocks because UIImage is iOS only and never Mac.
Third, I think there should yet another preprocessor macro that must
be defined by the user if they want this fallback code. This could be
rolled into the USE_UIIMAGE_BACKEND() macro itself, but the ability
should be there. For example, the UIImage RWops code really sucks and
may not be something developers want to fallback/rely on. In addition,
I think the developers must consciously opt-in to this feature anyway
because they must consciously weak link frameworks. I don’t think we
should make developers pay for the extra (though minor) code bloat if
they don’t want to support it (this is the more common case). Most
developers don’t have the ability to test 3.x devices any more. I
guarantee you that the majority of developers will not know about weak
linking and how to do it, and they will not test on a 3.x device. So
instead, they are going to get nasty App Store reviews from the few
3.x users still out there about how their app crashes.
Fourth, I think the UIImage and ImageIO pieces should be put into
separate, isolated function calls just to make future code maintenance
a little simpler.
Sounds good to me.On Fri, Dec 30, 2011 at 5:57 AM, Eric Wing wrote:
Hi Vittorio,
I didn’t forget about this, just been way too busy
I finally looked it over in greater detail. Overall it looks good.
Minor nitpicks:
Internal_checkImageIOisAvailable returning 0 instead of 1 through me
for a loop…took my brain a little bit to process, but I see how it
works.
The rename of ImageIO.c to ImageIO.m will require the Mac build
systems to also be modified. (Though I see you have a diff for the
Xcode projects earlier up…the Makefile build system may need to be
updated too…though I’m not totally sure about that. I tend to
neglect that one too )
On Mac, the *_UIImage functions yield ‘unused function’ warnings.
But those issues aside, I’m comfortable with putting this in the core
if it isn’t there already. Sam, Ryan?
Thanks,
Eric
But nitpicks aside, I guess we can
On 11/6/11, Eric Wing wrote:
Hi Vittorio,
I just wanted to you to know I haven’t forgotten about this. You
caught me in the middle of a busy period. Superficially, I think the
changes look good. I hope maybe to get a better look at this after
this week.
I don’t know if you’ve been following the other thread about pixel
color accuracy with ImageIO. That is the other thing that may affect
this patch (though probably only trivially). If you have some interest
and time, I would be interested in hearing how that change I proposed
actually works. The people complaining about it never wrote back.
Thanks,
Eric
On 10/29/11, Vittorio Giovara <vitto.giova at yahoo.it> wrote:
Hi Eric,
I have update ImageIO.m with your suggestions and added an exception
in case a 3.* device tries to use SDL_Image without UIImage support.
I’ll let you evalute the level of opting out I implemented, with the
currect configuration you just neet to disable the "unused function"
warning in the osx project file to avoid warnings.
IMG_ImageIO.m contains a brutal check to determine wheter we are on
ios4 (where we know that ImageIO is available) through the following
([NSClassFromString(@“UIImage”)
instancesRespondToSelector:@selector
(initWithCGImage:scale:orientation:)]
== NO)
It might be not that nice, but it works great!
Then in the application it is sufficient to weaklink ImageIO to be
able to use SDL_image on ios3.*. On OSX the uiimage part has been
ifdef’d away, but you need to add the Foundation framework in the
project file to be able to compile it.
In the uiimage layer only the tga loading is missing (as it is in
IMG_tga.c).
What do you think of this solution? Could it be added mainstream?
Best
Vittorio
Here’s my picky feedback/review on your patch.
First, USE_UIIMAGE_BACKEND should look like a function, e.g.
USE_UIIMAGE_BACKEND() similar to UI_USER_INTERFACE_IDIOM() because if
you misuse it as a compile time check instead of a runtime check, you
are asking for trouble (e.g. autorelease pool leaks). The function
look at least makes it more consistent with what Apple does.
Second, I think your USE_UIIMAGE_BACKEND() should always be inside the #if (TARGET_OS_IPHONE == 1) || (TARGET_IPHONE_SIMULATOR == 1)
blocks because UIImage is iOS only and never Mac.
Third, I think there should yet another preprocessor macro that must
be defined by the user if they want this fallback code. This could be
rolled into the USE_UIIMAGE_BACKEND() macro itself, but the ability
should be there. For example, the UIImage RWops code really sucks and
may not be something developers want to fallback/rely on. In addition,
I think the developers must consciously opt-in to this feature anyway
because they must consciously weak link frameworks. I don’t think we
should make developers pay for the extra (though minor) code bloat if
they don’t want to support it (this is the more common case). Most
developers don’t have the ability to test 3.x devices any more. I
guarantee you that the majority of developers will not know about weak
linking and how to do it, and they will not test on a 3.x device. So
instead, they are going to get nasty App Store reviews from the few
3.x users still out there about how their app crashes.
Fourth, I think the UIImage and ImageIO pieces should be put into
separate, isolated function calls just to make future code maintenance
a little simpler.
wrt the yielded warnings I cheated and deselected the “warn about
unused functions” in the osx project file, not sure if it’s a valid
fix though
VittorioOn Fri, Dec 30, 2011 at 11:57 AM, Eric Wing wrote:
Hi Vittorio,
I didn’t forget about this, just been way too busy
I finally looked it over in greater detail. Overall it looks good.
Minor nitpicks:
Internal_checkImageIOisAvailable returning 0 instead of 1 through me
for a loop…took my brain a little bit to process, but I see how it
works.
The rename of ImageIO.c to ImageIO.m will require the Mac build
systems to also be modified. (Though I see you have a diff for the
Xcode projects earlier up…the Makefile build system may need to be
updated too…though I’m not totally sure about that. I tend to
neglect that one too )
On Mac, the *_UIImage functions yield ‘unused function’ warnings.
But those issues aside, I’m comfortable with putting this in the core
if it isn’t there already. Sam, Ryan?
Thanks,
Eric
But nitpicks aside, I guess we can
On 11/6/11, Eric Wing wrote:
Hi Vittorio,
I just wanted to you to know I haven’t forgotten about this. You
caught me in the middle of a busy period. Superficially, I think the
changes look good. I hope maybe to get a better look at this after
this week.
I don’t know if you’ve been following the other thread about pixel
color accuracy with ImageIO. That is the other thing that may affect
this patch (though probably only trivially). If you have some interest
and time, I would be interested in hearing how that change I proposed
actually works. The people complaining about it never wrote back.
Thanks,
Eric
On 10/29/11, Vittorio Giovara <vitto.giova at yahoo.it> wrote:
Hi Eric,
I have update ImageIO.m with your suggestions and added an exception
in case a 3.* device tries to use SDL_Image without UIImage support.
I’ll let you evalute the level of opting out I implemented, with the
currect configuration you just neet to disable the "unused function"
warning in the osx project file to avoid warnings.
IMG_ImageIO.m contains a brutal check to determine wheter we are on
ios4 (where we know that ImageIO is available) through the following
([NSClassFromString(@“UIImage”)
instancesRespondToSelector:@selector(initWithCGImage:scale:orientation:)]
== NO)
It might be not that nice, but it works great!
Then in the application it is sufficient to weaklink ImageIO to be
able to use SDL_image on ios3.*. On OSX the uiimage part has been
ifdef’d away, but you need to add the Foundation framework in the
project file to be able to compile it.
In the uiimage layer only the tga loading is missing (as it is in
IMG_tga.c).
What do you think of this solution? Could it be added mainstream?
Best
Vittorio
Here’s my picky feedback/review on your patch.
First, USE_UIIMAGE_BACKEND should look like a function, e.g.
USE_UIIMAGE_BACKEND() similar to UI_USER_INTERFACE_IDIOM() because if
you misuse it as a compile time check instead of a runtime check, you
are asking for trouble (e.g. autorelease pool leaks). The function
look at least makes it more consistent with what Apple does.
Second, I think your USE_UIIMAGE_BACKEND() should always be inside the #if (TARGET_OS_IPHONE == 1) || (TARGET_IPHONE_SIMULATOR == 1)
blocks because UIImage is iOS only and never Mac.
Third, I think there should yet another preprocessor macro that must
be defined by the user if they want this fallback code. This could be
rolled into the USE_UIIMAGE_BACKEND() macro itself, but the ability
should be there. For example, the UIImage RWops code really sucks and
may not be something developers want to fallback/rely on. In addition,
I think the developers must consciously opt-in to this feature anyway
because they must consciously weak link frameworks. I don’t think we
should make developers pay for the extra (though minor) code bloat if
they don’t want to support it (this is the more common case). Most
developers don’t have the ability to test 3.x devices any more. I
guarantee you that the majority of developers will not know about weak
linking and how to do it, and they will not test on a 3.x device. So
instead, they are going to get nasty App Store reviews from the few
3.x users still out there about how their app crashes.
Fourth, I think the UIImage and ImageIO pieces should be put into
separate, isolated function calls just to make future code maintenance
a little simpler.
