我正在尝试移动这张图片：
在我的PyGame屏幕上，从右到左再返回。但是随着图片的移动，每秒钟都会有一次屏幕撕裂，就像这样：
我使用的代码循环类似于这样：
到目前为止，我已经尝试了以下方法来解决问题：
在创建屏幕时使用HWSURFACE、FULLSCREEN和DOUBLEBUF标志，但没有效果，我还将我的.update（rect）调整为.flip()（因为在使用DOUBLEBUF时建议这样做？）
将内存分配到GPU和CPU之间（我正在运行树莓派2），我尝试给两者都更多的内存，但没有改变。
将clock.tick设置为60 FPS以限制更新速率（高于和低于60 FPS），这确实平滑了一些撕裂，但并非全部。
调整每个增量向左或向右的大小，使增量较小可以减少撕裂，但速度也会降低。（不能让它太慢）
将新的黑色表面blit而不是在移动图像时绘制黑色矩形以确保其后面没有痕迹，因为我在某个地方读到blit使用HWSURFACE比绘图更好支持，虽然我无法证实这一点？- 这没有效果。
如果有人有其他可以改善情况的解决方案，我会非常感激。
我宁愿不要从PyGame更改到其他任何东西（如pyglet），因为我已经使用PyGame进行了相当多的实现，但我愿意听取建议。
干杯
编辑
如所请求，相关代码：
在我的PyGame屏幕上，从右到左再返回。但是随着图片的移动，每秒钟都会有一次屏幕撕裂，就像这样：
我使用的代码循环类似于这样：screen.blit(img, (x,y))
pygame.update((x,y),(w,h))
pygame.draw.rect(screen,(0,0,0),((x,y),(w,h)))
到目前为止，我已经尝试了以下方法来解决问题：
在创建屏幕时使用HWSURFACE、FULLSCREEN和DOUBLEBUF标志，但没有效果，我还将我的.update（rect）调整为.flip()（因为在使用DOUBLEBUF时建议这样做？）
将内存分配到GPU和CPU之间（我正在运行树莓派2），我尝试给两者都更多的内存，但没有改变。
将clock.tick设置为60 FPS以限制更新速率（高于和低于60 FPS），这确实平滑了一些撕裂，但并非全部。
调整每个增量向左或向右的大小，使增量较小可以减少撕裂，但速度也会降低。（不能让它太慢）
将新的黑色表面blit而不是在移动图像时绘制黑色矩形以确保其后面没有痕迹，因为我在某个地方读到blit使用HWSURFACE比绘图更好支持，虽然我无法证实这一点？- 这没有效果。
如果有人有其他可以改善情况的解决方案，我会非常感激。
我宁愿不要从PyGame更改到其他任何东西（如pyglet），因为我已经使用PyGame进行了相当多的实现，但我愿意听取建议。
干杯
编辑
如所请求，相关代码：
if scanner == True:
clocker.tick(clockspeed)
if x < 11:
slower = 3
if firstTime == True:
img.set_alpha(int(x * 25))
newSurf.set_alpha(int(x * 25))
screen.blit(newSurf,(xText,35))
pygame.display.update((xText,35),((xText + newSurf.get_width()),(50 + newSurf.get_height())))
img.set_alpha(255)
elif x > (divider - 15):
slower = 3
else:
slower = 0
firstTime = False
screen.blit(img, ((xStart - (x * increment) + slower),100))
pygame.display.update(((xStart - (x * increment) + slower),100),(95,450))
pygame.draw.rect(screen, (0,0,0), (((xStart - (x * increment) + slower),100),(95,450)))
变量 slower 旨在在进度条扫过速度的最左侧和最右侧时，给人一种惯性感，它会稍微减慢速度。
变量 firstTime 用于在进度条首次出现时淡入显示。
下面还有一个非常相似的循环，但是将图像扫回到另一侧。
pygame.draw.rect(screen,(0,0,0),((x,y),(w,h)))，因为第三个参数是一个pygame.Rect对象 :) - elegent