Hello everyone!
Quick question for the experts: suppose you have a 640x480 image and a
480x272 screen. If you were to blit the image onto the screen (which is
smaller than the image), would SDL blit the WHOLE surface onto the
screen, even the out-of-bounds pixels?
Would it be a good practice if I clipped the image myself? I’m having a
tough time doing that; so I ask to make sure I’m not doing all this work
in vain.
Thanks, and even though I’m not a very active member at all on this
list, I want to thank all of you who have helped me with my SDL problems
in the past, and wish you all a happy new year! =)
L-28C wrote:
Hello everyone!
Quick question for the experts: suppose you have a 640x480 image and a
480x272 screen. If you were to blit the image onto the screen (which is
smaller than the image), would SDL blit the WHOLE surface onto the
screen, even the out-of-bounds pixels?
Hi, I’m in no way, shape, or form an expert. But I know this one. 
Yes, if you blit a 640x480 to a 480x272 screen, only 480x272 of the
image will be visible. The rest is “off screen”.
jim
Yes, it does only display the size of your “screen” as James said. I am a
bit interested in this myself from a performance standpoint, as a bit of
code I have written in the past loads a large image into a surface. Does SDL
spend time clipping the pixel data before blitting? I.E. is the unused
portion of the image actually causing any performance impact as opposed to
clipping the image manually before blitting?
Yes, it does only display the size of your “screen” as James said. I am a
bit interested in this myself from a performance standpoint, as a bit of
code I have written in the past loads a large image into a surface. Does
SDL
spend time clipping the pixel data before blitting? I.E. is the unused
portion of the image actually causing any performance impact as opposed to
clipping the image manually before blitting?
Assuming you’re using SDL_BlitSurface, which needs a source rect as an
argument, wouldn’t that cause the clipping automatically? All you have to do
is read out the destination’s surface’s dimensions and use those as your
source rect dimensions.
Or am I missing something?
Cheers,
Peter
Yeah, that’s sort of what I’m asking.
Even though my machine is too fast to notice, I did test the image by
making it a bit larger… I didn’t see any speed difference, but once I
removed all transparent (colorkeyed) pixels, I did notice a slight
slowdown in the background. But like I said, my machine is too fast (not
bragging). 
Jonathan Greig wrote:> Yes, it does only display the size of your “screen” as James said. I
am a bit interested in this myself from a performance standpoint, as a
bit of code I have written in the past loads a large image into a
surface. Does SDL spend time clipping the pixel data before blitting?
I.E. is the unused portion of the image actually causing any
performance impact as opposed to clipping the image manually before
blitting?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL_BlitSurface basically just does clipping on the rectangles in
question and then hands them off to SDL_LowerBlit. The clipping is
done to the rectangles, so unblitted portions won’t affect performance
(barring the influence of caches).
If you’ve written your own clipping code, or know for a fact that no
clipping needs to be done, you can obtain an insignificant performance
boost by using SDL_LowerBlit. Usually, you want clipping; the extra
performance will only matter if you’re blitting tons of really tiny
surfaces.
-:sigma.SBOn Dec 30, 2007 12:07 AM, Jonathan Greig wrote:
Yes, it does only display the size of your “screen” as James said. I am a
bit interested in this myself from a performance standpoint, as a bit of
code I have written in the past loads a large image into a surface. Does SDL
spend time clipping the pixel data before blitting? I.E. is the unused
portion of the image actually causing any performance impact as opposed to
clipping the image manually before blitting?