Are the Two interfaces SDL_UpdateRect(s) and SDL_Flip duplicated?

I think in the user’s point of view , it is better than current
structure that he will always call SDL_UpdateRect(s)?the SDL lib will
decide to call SDL_Flip or not?For the SDL lib , how to make this
decision ? Just see the flags .

I think in the user’s point of view , it is better than current
structure that he will always call SDL_UpdateRect(s)?the SDL lib will
decide to call SDL_Flip or not?For the SDL lib , how to make this
decision ? Just see the flags.
Nah, Flip is drastically faster than a non-fullscreen UpdateRect on
some platforms, so it’s good to differentiate the two clearly.

UpdateRect is rarely useful anyway – only when you target old
platforms and need to squeeze out every bit of non-accelerated
performance.

Stefan.

I don’t think so. In my opinion, the two interface are functionally same in
the caller (programmer) or user’s view. Each time when he try to update the
actual screen to end user, he will decide to use SDL_Flip or SDL_UpdateRects
, and in most cases he will use a same function. Why not to tell the SDL lib
in the early time what Implemention he will use (UpdateRect(s) or Flip) ,
and call only one function every time when he want’s to update screen?

So what I mean is the interface ,Not the Implemention , we can arhive the
same goal, but merge the two interfaces to one , we get clear design. the ?
Design Patterns Explained ? says : Always Program oriented to interfaces NOT
the Implementions. (I am sorry I have no idea of the origin English text
because I read the Chinese Version).

2009/5/22 Stefan Monov > > I think in the user’s point of view , it is better than current

structure that he will always call SDL_UpdateRect(s)?the SDL lib will
decide to call SDL_Flip or not?For the SDL lib , how to make this
decision ? Just see the flags.
Nah, Flip is drastically faster than a non-fullscreen UpdateRect on
some platforms, so it’s good to differentiate the two clearly.

UpdateRect is rarely useful anyway – only when you target old
platforms and need to squeeze out every bit of non-accelerated
performance.

Stefan.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Um, you do realize UpdateRects updates only part of the screen, right?
That makes it different from Flip.
UpdateRects is used when you’re writing a program with simple graphics
(usually 2D), such that simple techniques like dirty-regions can tell
you what parts of the screen need updating. But as I said, on today’s
hardware this is not helpful, so for games that will run on current
hardware you just call Flip and save yourself the headaches.

The only question is whether we should remove Flip and just force the
user to call UpdateRects (passing it a fullscreen rect). My answer was
"no", because updating the whole screen is at least as efficient as
updating a small rect on some platforms, so it’s useful to have the
two as different abstractions.

If one goes from a “fullscreen” UpdateRect(0, 0, 1024, 768) to a
half-screen UpdateRect(0, 0, 512, 768) and the performance gets worse,
this violates the principle of least surprise. So don’t force people
to do a fullscreen UpdateRect in the first place.

No, there is a little differences. Let the user call UpdateRects, But *DO
NOT FORCE * him to pass it a fullscreen rect. He don’t know Flip at all
when call UpdateRects, but the SDL lib knows to choose which actual
implemention, even when the User call it with part screen, the SDL lib may
call Flip internel, it depends on the first time call to get the surface.

But you may say, when people draw something on 2 Rects, but right now he
wants to update 1 Rect only , the SDL lib can’t use Flip at all. I think
this case is very strange for users, so we can ignore it. on the other hand,
if users make a mistake, Create the surface with DOUBLEBUF option, but
wrongly call UpdateRects instead of Flip, he will not get what he wants.

2009/5/22 Stefan Monov > Um, you do realize UpdateRects updates only part of the screen, right?

That makes it different from Flip.
UpdateRects is used when you’re writing a program with simple graphics
(usually 2D), such that simple techniques like dirty-regions can tell
you what parts of the screen need updating. But as I said, on today’s
hardware this is not helpful, so for games that will run on current
hardware you just call Flip and save yourself the headaches.

The only question is whether we should remove Flip and just force the
user to call UpdateRects (passing it a fullscreen rect). My answer was
"no", because updating the whole screen is at least as efficient as
updating a small rect on some platforms, so it’s useful to have the
two as different abstractions.

If one goes from a “fullscreen” UpdateRect(0, 0, 1024, 768) to a
half-screen UpdateRect(0, 0, 512, 768) and the performance gets worse,
this violates the principle of least surprise. So don’t force people
to do a fullscreen UpdateRect in the first place.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL_UpdateRects had better not update the whole screen unless I ask it
to (if I understand you correctly)! The usage of individual rects on
the display is not a strange usage, especially for fancy libraries.

Jonny DOn Fri, May 22, 2009 at 10:32 AM, ??? <zengbo.zhang at gmail.com> wrote:

No, there is a little differences. Let the user call UpdateRects, But *DO
NOT FORCE * him to pass it a fullscreen rect. He don’t know Flip at all
when call UpdateRects, but the SDL lib knows to choose which actual
implemention, even when the User call it with part screen, the SDL lib may
call Flip internel, it depends on the first time call to get the surface.

But you may say, when people draw something on 2 Rects, but right now he
wants to update 1 Rect only , the SDL lib can’t use Flip at all. I think
this case is very strange for users, so we can ignore it. on the other hand,
if users make a mistake, Create the surface with DOUBLEBUF option, but
wrongly call UpdateRects instead of Flip, he will not get what he wants.

2009/5/22 Stefan Monov

Um, you do realize UpdateRects updates only part of the screen, right?
That makes it different from Flip.
UpdateRects is used when you’re writing a program with simple graphics
(usually 2D), such that simple techniques like dirty-regions can tell
you what parts of the screen need updating. But as I said, on today’s
hardware this is not helpful, so for games that will run on current
hardware you just call Flip and save yourself the headaches.

The only question is whether we should remove Flip and just force the
user to call UpdateRects (passing it a fullscreen rect). My answer was
"no", because updating the whole screen is at least as efficient as
updating a small rect on some platforms, so it’s useful to have the
two as different abstractions.

If one goes from a “fullscreen” UpdateRect(0, 0, 1024, 768) to a
half-screen UpdateRect(0, 0, 512, 768) and the performance gets worse,
this violates the principle of least surprise. So don’t force people
to do a fullscreen UpdateRect in the first place.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

But you may say, when people draw something on 2 Rects, but right now he
wants to update 1 Rect only , the SDL lib can’t use Flip at all. I think
this case is very strange for users, so we can ignore it. on the other hand,
if users make a mistake, Create the surface with DOUBLEBUF option, but
wrongly call UpdateRects instead of Flip, he will not get what he wants.

It all doesn’t really matter, there’s no interface to double-buffering
in SDL 1.3, and there’s no SDL_Flip anymore (in the 1.3 API, there’s
still one in the compatibility API that calls SDL_UpdateRect for the
whole screen). The new way, SDL_RenderPresent, is very simple, it has
no arguments at all, and yet can do the same optimizations you could
do with SDL_UpdateRect, automatically.On Fri, May 22, 2009 at 10:32 AM, ??? <zengbo.zhang at gmail.com> wrote:


http://pphaneuf.livejournal.com/