Strange performance in blit

[bw]

Howdy, folks,

I am getting some strange behavior in Surface.blit(). This is a mystery.

I blit a collection of images to to fill the screen. If I pan left or
right even one pixel, blit consumes nearly 4x the CPU. It is only left
or right: if I pan up or down performance is not impacted.

I've attached a program that attempts to demonstrate this. Hopefully
you'll find it minimal and easy to comprehend. Please let me know:

- Am I doing something wrong, and how?
- Is this a legitimate issue, and how might I work around it?


Please read the program description for the steps to reproduce the issue:

"""strange.py - demonstrating strange performane in Surface.blit

This program fills a screen with sprites to produce a checkerboard
background,
and demonstrates a problem.

Controls:

UP,DOWN,LEFT,RIGHT pan the background
SPACE center the background
ESCAPE quit

Reproducing the problem:

The times indicated in these steps are on a Intel i3 running Windows 7
64-bit.
Times will vary on other machines. The time cost measured is in blit ONLY.

1. Observe the cost per blit in the window's caption. On my machine it costs
about 0.0000015 seconds per blit.
2. Pan LEFT one or more pixels. Note the cost goes up nearly 4x (0.0000056).
3. Press SPACE to center the background. Note the cost goes back down to the
original value.
4. Pan RIGHT just one or more pixels. Note the costs goes up as in step 2.
5. Press SPACE to center the background.
6. Pan UP or DOWN: the cost is not impacted.
"""

Gumm

[bw]

Whoops. Forgive my haste and loss of focus right before sending that.
There is a mistake.

Change line 89:
costs = []
to
costs_per_screen = []

Gumm

Post by bw
Howdy, folks,
I am getting some strange behavior in Surface.blit(). This is a mystery.
I blit a collection of images to to fill the screen. If I pan left or
right even one pixel, blit consumes nearly 4x the CPU. It is only left
or right: if I pan up or down performance is not impacted.
I've attached a program that attempts to demonstrate this. Hopefully
- Am I doing something wrong, and how?
- Is this a legitimate issue, and how might I work around it?
"""strange.py - demonstrating strange performane in Surface.blit
This program fills a screen with sprites to produce a checkerboard
background,
and demonstrates a problem.
UP,DOWN,LEFT,RIGHT pan the background
SPACE center the background
ESCAPE quit
The times indicated in these steps are on a Intel i3 running Windows 7
64-bit.
Times will vary on other machines. The time cost measured is in blit ONLY.
1. Observe the cost per blit in the window's caption. On my machine it costs
about 0.0000015 seconds per blit.
2. Pan LEFT one or more pixels. Note the cost goes up nearly 4x (0.0000056).
3. Press SPACE to center the background. Note the cost goes back down to the
original value.
4. Pan RIGHT just one or more pixels. Note the costs goes up as in step 2.
5. Press SPACE to center the background.
6. Pan UP or DOWN: the cost is not impacted.
"""
Gumm

[bw]

After some more study I have refined the behavior. Thanks to DR0ID for
helping me reduce the problem.

In any blit(surf, (x,y)), if x is aligned on a multiple of 16 then blit
is fast; otherwise it is slow.

Is this a SDL quirk?

If you have a faster computer than my i3 laptop you may be able to see
the problem more clearly with larger tile sizes and screen width.

I've attached another program that is easier to play with, though a bit
more complicated to read due to all the run-time controls. You can set
the tile size on the fly, and toggle the camera step. Culling is an
option just to show rendering off screen has no impact.

Gumm

Post by bw
Whoops. Forgive my haste and loss of focus right before sending that.
There is a mistake.
costs = []
to
costs_per_screen = []
Gumm

Post by bw
Howdy, folks,
I am getting some strange behavior in Surface.blit(). This is a mystery.
I blit a collection of images to to fill the screen. If I pan left or
right even one pixel, blit consumes nearly 4x the CPU. It is only
left or right: if I pan up or down performance is not impacted.
I've attached a program that attempts to demonstrate this. Hopefully
- Am I doing something wrong, and how?
- Is this a legitimate issue, and how might I work around it?
"""strange.py - demonstrating strange performane in Surface.blit
This program fills a screen with sprites to produce a checkerboard
background,
and demonstrates a problem.
UP,DOWN,LEFT,RIGHT pan the background
SPACE center the background
ESCAPE quit
The times indicated in these steps are on a Intel i3 running Windows
7 64-bit.
Times will vary on other machines. The time cost measured is in blit ONLY.
1. Observe the cost per blit in the window's caption. On my machine it costs
about 0.0000015 seconds per blit.
2. Pan LEFT one or more pixels. Note the cost goes up nearly 4x (0.0000056).
3. Press SPACE to center the background. Note the cost goes back down to the
original value.
4. Pan RIGHT just one or more pixels. Note the costs goes up as in step 2.
5. Press SPACE to center the background.
6. Pan UP or DOWN: the cost is not impacted.
"""
Gumm

[diliup gabadamudalige]

could this be due to the fact operations are done in multiples of 8 bits?
(16 bit, 32 bit, 64 bit etc.)

Post by bw
After some more study I have refined the behavior. Thanks to DR0ID for
helping me reduce the problem.
In any blit(surf, (x,y)), if x is aligned on a multiple of 16 then blit is
fast; otherwise it is slow.
Is this a SDL quirk?
If you have a faster computer than my i3 laptop you may be able to see the
problem more clearly with larger tile sizes and screen width.
I've attached another program that is easier to play with, though a bit
more complicated to read due to all the run-time controls. You can set the
tile size on the fly, and toggle the camera step. Culling is an option just
to show rendering off screen has no impact.
Gumm

Post by bw
Whoops. Forgive my haste and loss of focus right before sending that.
There is a mistake.
costs = []
to
costs_per_screen = []
Gumm

Post by bw
Howdy, folks,
I am getting some strange behavior in Surface.blit(). This is a mystery.
I blit a collection of images to to fill the screen. If I pan left or
right even one pixel, blit consumes nearly 4x the CPU. It is only left or
right: if I pan up or down performance is not impacted.
I've attached a program that attempts to demonstrate this. Hopefully
- Am I doing something wrong, and how?
- Is this a legitimate issue, and how might I work around it?
"""strange.py - demonstrating strange performane in Surface.blit
This program fills a screen with sprites to produce a checkerboard
background,
and demonstrates a problem.
UP,DOWN,LEFT,RIGHT pan the background
SPACE center the background
ESCAPE quit
The times indicated in these steps are on a Intel i3 running Windows 7
64-bit.
Times will vary on other machines. The time cost measured is in blit ONLY.
1. Observe the cost per blit in the window's caption. On my machine it costs
about 0.0000015 seconds per blit.
2. Pan LEFT one or more pixels. Note the cost goes up nearly 4x (0.0000056).
3. Press SPACE to center the background. Note the cost goes back down to the
original value.
4. Pan RIGHT just one or more pixels. Note the costs goes up as in step 2.
5. Press SPACE to center the background.
6. Pan UP or DOWN: the cost is not impacted.
"""
Gumm

--
Diliup Gabadamudalige


http://www.diliupg.com
http://soft.diliupg.com/

**********************************************************************************************
This e-mail is confidential. It may also be legally privileged. If you are
not the intended recipient or have received it in error, please delete it
and all copies from your system and notify the sender immediately by return
e-mail. Any unauthorized reading, reproducing, printing or further
dissemination of this e-mail or its contents is strictly prohibited and may
be unlawful. Internet communications cannot be guaranteed to be timely,
secure, error or virus-free. The sender does not accept liability for any
errors or omissions.
**********************************************************************************************

[bw]

If you change line 97:

step = 8

and line 112:

elif e.key == K_s: step = 8 if step == 1 else 1

you should see that when X is 8, 24, 40, etc. the problem occurs. When
it is 0, 16, 32, 48, etc. it does not occur. The same holds true for the
negative X values. 16 is the magic number.

Gumm

Post by diliup gabadamudalige
could this be due to the fact operations are done in multiples of 8 bits?
(16 bit, 32 bit, 64 bit etc.)
After some more study I have refined the behavior. Thanks to DR0ID
for helping me reduce the problem.
In any blit(surf, (x,y)), if x is aligned on a multiple of 16 then
blit is fast; otherwise it is slow.
Is this a SDL quirk?
If you have a faster computer than my i3 laptop you may be able to
see the problem more clearly with larger tile sizes and screen width.
I've attached another program that is easier to play with, though
a bit more complicated to read due to all the run-time controls.
You can set the tile size on the fly, and toggle the camera step.
Culling is an option just to show rendering off screen has no impact.
Gumm
Whoops. Forgive my haste and loss of focus right before
sending that. There is a mistake.
costs = []
to
costs_per_screen = []
Gumm
Howdy, folks,
I am getting some strange behavior in Surface.blit(). This
is a mystery.
I blit a collection of images to to fill the screen. If I
pan left or right even one pixel, blit consumes nearly 4x
the CPU. It is only left or right: if I pan up or down
performance is not impacted.
I've attached a program that attempts to demonstrate this.
Hopefully you'll find it minimal and easy to comprehend.
- Am I doing something wrong, and how?
- Is this a legitimate issue, and how might I work around it?
Please read the program description for the steps to
"""strange.py - demonstrating strange performane in Surface.blit
This program fills a screen with sprites to produce a
checkerboard background,
and demonstrates a problem.
UP,DOWN,LEFT,RIGHT pan the background
SPACE center the background
ESCAPE quit
The times indicated in these steps are on a Intel i3
running Windows 7 64-bit.
Times will vary on other machines. The time cost measured
is in blit ONLY.
1. Observe the cost per blit in the window's caption. On
my machine it costs
about 0.0000015 seconds per blit.
2. Pan LEFT one or more pixels. Note the cost goes up
nearly 4x (0.0000056).
3. Press SPACE to center the background. Note the cost
goes back down to the
original value.
4. Pan RIGHT just one or more pixels. Note the costs goes
up as in step 2.
5. Press SPACE to center the background.
6. Pan UP or DOWN: the cost is not impacted.
"""
Gumm
--
Diliup Gabadamudalige
http://www.diliupg.com
http://soft.diliupg.com/
**********************************************************************************************
This e-mail is confidential. It may also be legally privileged. If you
are not the intended recipient or have received it in error, please
delete it and all copies from your system and notify the sender
immediately by return e-mail. Any unauthorized reading, reproducing,
printing or further dissemination of this e-mail or its contents is
strictly prohibited and may be unlawful. Internet communications
cannot be guaranteed to be timely, secure, error or virus-free. The
sender does not accept liability for any errors or omissions.
**********************************************************************************************