pygame.display.update(rectangle) es wird mehr als das rectangle "upgedated"?

[opus]

Ich habe merkwürdiges Problem mit pygame.display.update(Rectangle).
Es wird mehr als das übergebene Rectangle (oder die Liste von Rectangles) "upgedated".
Zum Überprüfen fülle ich das Rectangle vorher per "screen.fill((25,25,25),Rectangle)" und wende dann o.a. CodeZeile an. Natürlich habe ich alle anderen "pygame.display.update" oder "pygame.display.flip" Befehle dafür auskommentiert.
Auf dem Bildschirm wird dann richtigerweise das schwarze Rechteck angezeigt, aber auch die Bereiche weiter rechts werden "upgedated".
Das Rectangle ist ergo richtig definiert.

Soweit ich das verstehe ist da was falsch.

[__deets__]

Kann sein, dass es ein Bug ist - https://github.com/libsdl-org/SDL/issues/3663 zb. Aber salopp gesagt: das ist Quatsch, das zu benutzen. Die Zeiten, in denen man peinlich genau Bildschirmteile manipuliert hat, sind vorbei. Üblicherweise malt man einfach alles neu.

[__deets__]

UNd noch ein Nachtrag: ohne deinen Code zu sehen, kann man da nichts genaues zu sagen, aber es kann auch sein, dass aus Effizienzgruenden das Update mit einer auf zB 16 oder 32 pixel gerundeten Groesse angewandt wird. Und was du da beobachtest ein Artefakt ist, weil du direktes malen mit updates mischst. Das ist aber nur eine Vermutung.

[opus]

Danke für die Antworten!

Den gelinkten Bug-Report hatte ich gesehen. Da dieser ab alt, closed und (nach meinem begrenzten Verständnis) eher für das OS Windows gilt hatte ich hier nochmal nachgefragt.
Ob es "Quatsch" ist muss man wohl selbst entscheiden. Eine Steigerung von 15-20% in den erreichbaren FPS sind für MICH Grund genug. Insbesondere da ich zwar auf einem Linux Laptop erstelle, das Zielsystem aber ein Raspi ist und ich dort nur ein Viertel der FPS des Laptops erziele.

Das man ohne den Code zu sehen, diesen nicht kommentieren kann ist mehr als verständlich. Eine Antwort wie die Erste entspricht meiner Erwartungshaltung!
Eine Nachfrage noch: Das mit dem möglichen Artefakt ist mir nicht klar. Wie könnte ich feststellen ob "update" mit "gerundete Größen" arbeitet?

Nochmal zum Verhalten von "pygame.display.update()". Es sieht für mich so aus als ob die Rectangles zwar genutzt werden, leider aber nur in der Y-Richtung. Der gesamte Bildschirmbereich rechts und links von dem Rectangle wird "upgedated"

[__deets__]

Der konkrete Bug ist fuer Windows, ja. Aber du hattest ja in deinem Ausgangspost keinerlei OS erwaehnt. Kann man also nicht wissen. Und auch nicht, wie alt oder neu dein pygame bzw. die darunter liegende SDL sind. Das kann durchaus 2 Jahre oder aelter sein, wenn man auf einer entsprechenden Distribution zB unterwegs ist. Ich weiss auch nicht, wie sehr pygame die SDL trackt. Ob die jedes release automatisch mitnehmen, etc.

Gerundet auf bestimmte Groessen war ja nur eine Vermutung. Du sagst jetzt, dass es quasi immer Streifen sind. Kann genauso sein, dass man das als Kompromiss gewaehlt hat. Warum auch immer. Was es nicht tun sollte, ist fuer dich sichtbar sein. Ich kann mir aber eben vorstellen, dass du etwas komisch machst, also update-Verfahren mischst, und dadurch kommt es zu sichtbaren Artefakten. Kann ich aber ohne Code nicht beurteilen.

Was die Geschwindigkeit angeht: wenn es schnell werden soll, benutzt man heutzutage Hardware-Beschleunigung (die auch der Pi bietet), und da kann man dein partielles Update gar nicht anwenden.

[opus]

Erstmal Danke für die ausführlichen Antworten!

Ich habe mal den aktuellen Code auf den Raspi gebracht, dort zeigt sich dieser Fehler NICHT! Diese Art von Fehler muss man lieben!
Auf dem Raspi läuft es jetzt mit bummelig 20FPS (auf dem Laptop waren es 80+FPS).

In die Hardware-Beschleunigung schaue ich jetzt mal rein.

[__deets__]

Welchen Pi benutzt du denn? Auf dem urspruenglichen Pi habe ich mal ein Spiel (auch fuer ein Museum) gebaut, mit pygame. Das war erst durch die Verwendung von PyPy ueberhaupt tragbar. Heutzutage wuerde ich eher zu C++ oder Rust greifen, wenn's was grafisches sein soll. Kommt aber natuerlich darauf an, was man genau macht. Wie schon erwaehnt - numpy zB zu benutzen ist performant, und das bisschen Python drumrum macht (fast) nix aus.

[opus]

Das läuft auf einem Raspi 4 (1GB).
Mit der jetzigen Performance bin ich zufrieden. 20 FPS bedeutet für diese Anwendung RealTime*20, das sollte reichen für die Besucher. Jede weiter Beschleunigung wäre jetzt nur Entlastung der Hardware (von daher lasse ich das wohl mit der Hardware-Beschleunigung).
In der Software werden nur einzelne Pixel (VIELE) oder Linien(wenige) gemalt und die Inhalte der Surfaces werden per .scroll verschoben. Dazu kommen noch die trigonomischen Berechnungen der Farbe für die Pixel.
An UserInput gibt es nur einen Switch per GPIO und ein Paar Schalter per Tastatur. Also nix Großes!!