Zitat:

---

Original von tboeckel:
Wie ist denn die Vorauswahl bei dir eingestellt (Konfig -> Neue Post -> Vorauswahl)? Steht das eventuell auf "immer, nur Grössen"?

---

Zitat:

---

Original von tboeckel:
Ganz generell: YAM hat eine Homepage, ein Forum und einen Bugtracker. Fragen in einem öffentlichem Forum wie diesem können und werden wir niemandem verbieten, aber es ist sehr wahrscheinlich, daß wir (die Entwickler) solche Fragen leicht übersehen. Der direkte Weg ist da etwas erfolgsversprechender und direkter.

---

Zitat:

---

Original von Holger:
Ich kann nichts zu der von Dir verwendeten Version sagen, kenne das Verhalten aber auch schon von der Version 2.4. Es tritt nur auf, wenn die Verbindung sehr langsam ist und/oder der Posteingang sehr voll ist. Letzteres scheint ja bei Dir offensichtlich der Fall zu sein.

Dabei werden die Absender und Betreffs sehr wohl angezeigt, nur mit einer seeeehr großen Verzögerung. Wenn es sich bei Dir um dasselbe Phänomen handelt, muss Du also nur lange genug warten, bis die Informationen erscheinen. Hat allerdings den Nachteil, dass dann u.U. schon ein timeout kommt, wenn Du dann noch eine Download-Vorauswahl treffen willst.

---

Zitat:

---

Original von Holger:
Mit Hollywood gibt es ja sogar eine.
Allerdings ist diese halt kommerziell.

---

Zitat:

---

Original von Holger:
Moment mal.
Wie oft soll ich eigentlich noch sagen, dass alles, was Du tust, zwischen BeginRefresh und EndRefresh passieren soll?

Insofern möchte ich nie wieder etwas von nach EndRefresh hören.

---

Zitat:

---

Original von Holger:
Aber trotzdem möchte ich noch mal für die Akten festhalten, dass das Installieren einer Clipping-Region weder die Damage-Liste verändert, noch das Damage-Flag setzt.

---

Zitat:

---

Original von Holger:

Zitat:

---

Original von Reth:
Die Frage war nur, ob ich zu meiner eigenen ClippingRegion die Bereiche der Original-ClippingRegion hinzufügen muss oder nicht, bevor ich meine Objekte aktualisiere?

---

Ja, Du willst ja sowohl die Bereiche, die sich aus der Anwendungslogik her verändert haben, als auch die Bereiche, die "beschädigt" wurden, aktualisieren. Das heißt, Du nimmst eine Oder-Verknüpfung vor.

---

Zitat:

---

Original von Holger:

Zitat:

---

Für das Herstellen des Originalzustandes: Ich hatte verstanden meine Bereiche mit der alten ClipRegion zu verknüpfen, muss diese Originalregion aber am Schluss wieder herstellen.
Ist dies denn überhaupt sinnvoll, oder merke ich mir nur die alte ClipRegion nach BeginRefresh, aktualisiere dann meine Bereiche mit einer eigenen, neuen ClipRegion und stelle die Original-ClipRegion vor EndRefresh wieder her?

---

Letzteres.
Vor BeginRefresh besitzt der Layer ja noch gar keine ClippingRegion. Erst der Aufruf von BeginRefresh macht ja aus der bisherigen Damage-Liste die zugehörige Clipping-Region. Dann kannst Du diese manipulieren, musst natürlich vor EndRefresh den alten Zustand wiederherstellen.

---

C code:

---

RefreshGadgets() und GT_RefreshWindow()

---

Zitat:

---

Original von Holger:
Egal, in welcher Reihenfolge die Verarbeitung im Code steht, wirst Du die Events in der Reihenfolge verarbeiten, wie Du sie empfängst.

Das ist aber überhaupt kein Problem. Jeder Layer hat ein Flag, das besagt, ob Damage vorhanden ist und das bei EndRefresh(...,TRUE) zurückgesetzt wird. Wenn Du eine Refresh-Message bekommst, das Flag aber nicht gesetzt ist, dann weißt Du, dass Du zwischen der Ursache und dem Empfang schon einen Maus oder Timer getriggerten Refresh durchgeführt hast und die Message ignorieren kannst.

---

C code:

---

GT_BeginRefresh(), GT_EndRefresh() und GT_RefreshWindow()

---

Zitat:

---

Original von Maverik:
Geht doch

---

Zitat:

---

Original von Tomcat:
Ich habe bei jabber.earth.li mein Konto, da gebe ich beim ICQ-Transport meine UIN und das Passwort ein, das sind 2 Felder. Was du da beschreibst, ist der IRC-Transport, nicht ICQ.

---

Zitat:

---

Original von Holger:
Da für reine Layer, die nicht zu einem Fenster gehören, keine solchen Alternativen zur Verfügung stehen, können diese eben nicht systemkonform mit Fenstern vermischt werden.

---

Zitat:

---

Original von Holger:
Etwas anderes sind Operationen, die ausschließlich den Layer Deines Fensters betreffen. Wenn Du also Scroll-Operationen innerhalb Deines Fensters durchführst, erhältst Du u.U. Damage in Deinem Layer, aber Du weißt ja, dass Du diese Operation durchgeführt hast, kannst also im direkten Anschluss das Damage Bit überprüfen und, wenn nötig, einen Refresh durchführen.

---

Zitat:

---

Original von Holger:
Der Refresh-Modus eines Fensters ist immer simple, smart oder super-bitmap.

---

Zitat:

---

Original von Holger:
Die Größe Deiner Zeichenfläche ist die Größe des Fensters abzüglich des Rahmens. Wenn Du GZZ-Fenster benutzt, ist die Zeichenfläche identisch mit der Größe Deines Layers

---

C code:

---

InstallClipRegion()

---

Zitat:

---

Original von Holger:
Mit ScrollRasterBF kannst Du denselben Effekt innerhalb Deines primären Layers (Fensters) erreichen und sofort im Anschluss den nötigen Refresh ohne Zeitverzögerung durchführen.

---

Zitat:

---

Original von Holger:
Ja klar, aber Du hattest die Frage angesprochen, ob die RastPort-Klasse Methoden anbietet, die an die BitMap delegieren.
...
Und da es momentan eher so aussieht, als ob Du die Blit-Funktionen auf BitMap überhaupt nicht brauchst, lass sie doch einfach weg.

---

Zitat:

---

Original von Holger:
Ja, man könnte natürlich eine Abstraktion der Art "Blit-Ziel" machen, um dann bestimmte Funktionen von der Frage, ob sie in einen RastPort oder direkt in eine BitMap blitten, zu entkoppeln.
Die Frage, die Du Dir dabei stellen solltest, ist: brauchst Du diese Möglichkeit?

---

Zitat:

---

Original von Holger:
Und wenn man versucht, Eindeutigkeit beispielsweise über den Namen zu erzielen, sind die Funktionen auch nicht mehr komfortabler, als beispielsweise, rastport->bitMap->blit statt rastport->bitMapDirectBlit zu schreiben.

---

Zitat:

---

Original von Holger:
Natürlich. RastPort hat eine BitMap, aber RastPort ist keine BitMap.

---

Zitat:

---

Original von Holger:
Dafür sind die Operationen sinnvoll, aber von brauchen würde ich nicht reden. Schließlich kann man auch für Offscreen-BitMaps RastPorts anlegen.

---

Zitat:

---

Original von Holger:
Der RastPort ist im Grunde genau das, was die Graphics-Klasse in Java/AWT ist

---

Zitat:

---

Original von Holger:
Für Raster-Grafiken ist das Prinzip ebenfalls ähnlich: man kann sie auch auf einer niedrigeren Ebene verarbeiten, da die meisten Kontext-Attribute keine Auswirkungen haben.

...

Ein wichtiges Feature, das einen RastPort benötigt, ist das Clipping. Die BitMap-Struktur hat keine Referenz auf den Layer, d.h. alle Blit-Operationen, die auf BitMaps arbeiten, ignorieren die Layer-Constraints, während alle RastPort-Operationen den Layer respektieren, wenn der zugehörige Eintrag im rp nicht null ist.

---

Zitat:

---

Original von Holger:
Deshalb müssen systemkonforme Blits bei der Verwendung von Fenstern immer im RastPort erfolgen, es sei denn, man lockt die Layer und a) clipt selber oder b) hat vorher überprüft, dass es keine Überlappungen gibt. Das ist aber nur dann sinnvoll, wenn man sehr viele Blit-Operationen durchführen will.

---

Zitat:

---

Original von Holger:
Gleiche Regel wie für Library-Calls: selbstverständlich musst Du vorher öffnen.

---

Zitat:

---

Einigen wir uns doch darauf, dass die graphics.library höchstwahrscheinlich nur dann Rechtecke zusammenfasst, wenn die Verwaltung der Fläche als einzelne kleine Rechtecke in keinem sinnvollen Verhältnis zum Gewinn durch nicht enthalten Teilflächen mehr steht.
Falls so etwas überhaupt passiert.
Jedenfalls würde das System niemals disjunkte Rechtecke zu einem großen zusammenfassen.

Für Dich gilt doch erst mal, dass Du den einfachen Zeichenalgorithmus implementieren solltest, bevor Du Dir darüber Gedanken machst, ob die resultierende Performance das Ersetzen der Systemalgorithmen durch eigene (kannst Du es denn überhaupt besser?) erforderlich macht.

---

Zitat:

---

Mit ScrollRasterBF kannst Du denselben Effekt innerhalb Deines primären Layers (Fensters) erreichen und sofort im Anschluss den nötigen Refresh ohne Zeitverzögerung durchführen.

---

Zitat:

---

Original von Holger:
DamageList ist ein Eintrag in der Layer-Struktur, genauso wie ClipRegion, der einzige Unterschied ist der, dass Du natürlich den Layer locken musst, bevor Du etwas veränderst.

---

Zitat:

---

Original von Holger:
Allerdings erscheint es mir für Deinen Fall doch einfacher, die Bereiche der normalen Clip-Liste während des Refreshs hinzuzufügen, Du musst nur daran denken, den exakten Originalzustand vor EndRefresh wiederherzustellen.

---

C code:

---

struct RegionRectangle

---

Zitat:

---

Original von Holger:
Und da hakt's dann auch mit dem INTUITICKS-basiertem Refresh, der an sich mit dem NoCareRefresh harmoniert. Aber wenn ein neues Fenster geöffnet und aktiviert wird, bekommt Dein Fenster als inaktives keine Ticks mehr und da es auch keine Refresh-Meldungen erhält, wird Dein Spielfeld nicht aktualisiert, wenn das darüberliegende Fenster bewegt wird.

Zitat:

---

Original von Reth:
Kann ich denn die Aktualisierung mit BeginRefresh/EndRefresh auch bei Events wie MOUSEMOVE anwenden?

---

Klar, dann kann es allerdings passieren, dass Du später eine RefreshMessage bekommst, obwohl inzwischen alles wiederhergestellt wurde.

---

Zitat:

---

Original von Holger:

Zitat:

---

Reth:
Aber den eigenen Layer kann ich doch nutzen, damit ich schon mal das Scrolling usw. habe, oder?

---

Wofür brauchst Du beim Scrolling einen eigenen Layer?

---

Zitat:

---

Original von Holger:
Um Himmels Willen, nein. Alle Bereiche müssen vor dem Aufruf von BeginRefresh in die DamageListe eingetragen werden. Der Aufruf von BeginRefresh macht aus die aktuellen DamageListe einen aktuellen Clipping-Bereich.
...
Nicht der ClippingRegion, sondern der DamageListe. Das System ermittelt betroffene Bereiche, die durch Layer-Operationen oder durch Scrolling-Operationen beschädigt wurden.

---

Zitat:

---

Original von Holger:
Wenn die Layer-Operationen durch Fenster-Operationen verursacht wurden, dann schickt Intuition den zu den Layern gehörenden Fenstern eine Refresh-Message.

---

Zitat:

---

Original von Holger:

Zitat:

---

Original von Reth:
Das ist doch aber ziemlich inperformant, wenn ich alle Hex-Tiles und auch alle "darüber liegenden" Objekte neu blitte.

---

Nein, alles, was außerhalb der Clip-Bereiche liegt, hat keinen Effekt.

---

Zitat:

---

Original von Holger:

Zitat:

---

Original von Reth:
Wäre das aber nicht was für nen scrollbaren Statusbereich o.ä.?

---

Braucht genausowenig ein eigenes Fenster.

---