If I draw individual pixels to a 24 bit screen, either directly editing
the buffer or by using the pixelRGBA function in SDL_gfx, then I have to
decide the rectangular area to update. The easy thing to do would be to
do a 1x1 update rectangle for each pixel, but it seems like it would be
slow.
If I had a high enough changed pixel density for a given area, it would be
better to update that whole area rather than do an update rectangle for
each individual pixel, wouldn’t it?
Does anyone know the minimal changed-pixel density in a 24 bit screen
that it is better to draw one large rectangle rather than multiple
individual ones?
Also, if double buffering is enabled, would it be faster to do my pixel
operations on a software screen and then blit that onto the real screen?
It sounds like your going a little over the top here. If pixels are drawn by
someone in the UI, you want the update to happen automatically. If your
drawing a batch of pixels (like a small fill, image, pattern, whatever), you
can calculate a bounding rectangle by simply keeping track of the min/max
extents of the x,y coordinates of all the pixels per “batch”.
I’m assuming this is an application where double buffering is not enabled.
Matthew> If I draw individual pixels to a 24 bit screen, either directly editing
the buffer or by using the pixelRGBA function in SDL_gfx, then I have to
decide the rectangular area to update. The easy thing to do would be to
do a 1x1 update rectangle for each pixel, but it seems like it would be
slow.
If I had a high enough changed pixel density for a given area, it would be
better to update that whole area rather than do an update rectangle for
each individual pixel, wouldn’t it?
Does anyone know the minimal changed-pixel density in a 24 bit screen
that it is better to draw one large rectangle rather than multiple
individual ones?
Also, if double buffering is enabled, would it be faster to do my pixel
operations on a software screen and then blit that onto the real screen?
I heard some time back that 24 bit color was actually SLOWER than 32 bit
color.
Does anyone know if that’s still true? Might help him if he switches to 32
but don’t want to give bad advice (:_____
From: sdl-bounces+atrix2=cox.net@libsdl.org
[mailto:sdl-bounces+atrix2=cox.net at libsdl.org] On Behalf Of Matt J
Sent: Thursday, March 16, 2006 8:29 AM
To: A list for developers using the SDL library. (includes SDL-announce)
Subject: Re: [SDL] Lowest pixel density for update rectangle
It sounds like your going a little over the top here. If pixels are drawn by
someone in the UI, you want the update to happen automatically. If your
drawing a batch of pixels (like a small fill, image, pattern, whatever), you
can calculate a bounding rectangle by simply keeping track of the min/max
extents of the x,y coordinates of all the pixels per “batch”.
I’m assuming this is an application where double buffering is not enabled.
Matthew
If I draw individual pixels to a 24 bit screen, either directly editing
the buffer or by using the pixelRGBA function in SDL_gfx, then I have to
decide the rectangular area to update. The easy thing to do would be to
do a 1x1 update rectangle for each pixel, but it seems like it would be
slow.
If I had a high enough changed pixel density for a given area, it would be
better to update that whole area rather than do an update rectangle for
each individual pixel, wouldn’t it?
Does anyone know the minimal changed-pixel density in a 24 bit screen
that it is better to draw one large rectangle rather than multiple
individual ones?
Also, if double buffering is enabled, would it be faster to do my pixel
operations on a software screen and then blit that onto the real screen?
It sounds like your going a little over the top here. If pixels are drawn by
someone in the UI, you want the update to happen automatically.
Yes it’s for people drawing pixels in the user interface, a scheme
interface to SDL, and I’m not sure how they are going to use the pixels. But however they draw the pixels, I
don’t want them to have to draw the update rectangles themselves. So, I
was hoping to optimize the rectangles as they draw the pixels, and when
they call the “draw” function to update the screen, it would update them
all, in an optimized fashion.
Likewise, if I draw a line, from (0, 0) to (90, 90), is it better to
update a whole 90x90 rectangle, just to show the line, or is it better to
make a bunch of smaller rectangles that follow the slope of the line?
Just how slow is the rectangle update? It might be faster updating the
whole rectangle than calculating where to put the smaller rectangles,
though I doubt it.
I was also wondering, is it faster to call “updateRects” if I have a bunch
of rectangles, than to just call “updateRect” several times?On Thu, 16 Mar 2006, Matt J wrote:
If your
drawing a batch of pixels (like a small fill, image, pattern, whatever), you
can calculate a bounding rectangle by simply keeping track of the min/max
extents of the x,y coordinates of all the pixels per “batch”.
I’m assuming this is an application where double buffering is not enabled.
Matthew
If I draw individual pixels to a 24 bit screen, either directly editing
the buffer or by using the pixelRGBA function in SDL_gfx, then I have to
decide the rectangular area to update. The easy thing to do would be to
do a 1x1 update rectangle for each pixel, but it seems like it would be
slow.
If I had a high enough changed pixel density for a given area, it would be
better to update that whole area rather than do an update rectangle for
each individual pixel, wouldn’t it?
Does anyone know the minimal changed-pixel density in a 24 bit screen
that it is better to draw one large rectangle rather than multiple
individual ones?
Also, if double buffering is enabled, would it be faster to do my pixel
operations on a software screen and then blit that onto the real screen?
The screen can update faster then the user can draw pixels. And no, its not
faster to draw a bunch of update rectangles along the slop of the line. I
think your a little worried about premature optimization. And if this
program has any sort of layers, you’ll have double buffering anyway, making
this a mute exercise.
Matt> It sounds like your going a little over the top here. If pixels are drawn
by
someone in the UI, you want the update to happen automatically.
Yes it’s for people drawing pixels in the user interface, a scheme
interface to SDL, and I’m not sure how they are going to use the
pixels. But however they draw the pixels, I
don’t want them to have to draw the update rectangles themselves. So, I
was hoping to optimize the rectangles as they draw the pixels, and when
they call the “draw” function to update the screen, it would update them
all, in an optimized fashion.
Likewise, if I draw a line, from (0, 0) to (90, 90), is it better to
update a whole 90x90 rectangle, just to show the line, or is it better to
make a bunch of smaller rectangles that follow the slope of the line?
Just how slow is the rectangle update? It might be faster updating the
whole rectangle than calculating where to put the smaller rectangles,
though I doubt it.
I was also wondering, is it faster to call “updateRects” if I have a bunch
of rectangles, than to just call “updateRect” several times?
If your
drawing a batch of pixels (like a small fill, image, pattern, whatever),
you
can calculate a bounding rectangle by simply keeping track of the
min/max
extents of the x,y coordinates of all the pixels per “batch”.
I’m assuming this is an application where double buffering is not
enabled.
Matthew
If I draw individual pixels to a 24 bit screen, either directly
editing
the buffer or by using the pixelRGBA function in SDL_gfx, then I have
to
decide the rectangular area to update. The easy thing to do would be
to
do a 1x1 update rectangle for each pixel, but it seems like it would
be
slow.
If I had a high enough changed pixel density for a given area, it
would be
better to update that whole area rather than do an update rectangle
for
each individual pixel, wouldn’t it?
Does anyone know the minimal changed-pixel density in a 24 bit screen
that it is better to draw one large rectangle rather than multiple
individual ones?
Also, if double buffering is enabled, would it be faster to do my
pixel
operations on a software screen and then blit that onto the real
screen?