ENGLISH VERSION |
|
Links | | | Forum | | | Kommentare | | | News melden |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
amiga-news.de Forum > Programmierung > Neue Frage zu Überdeckungen | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
1 -2- 3 4 5 6 | [ - Beitrag schreiben - ] |
15.02.2011, 20:05 Uhr Reth Posts: 1858 Nutzer |
@Holger: Danke für Deine Hilfen! Zitat:Und der Refresh-Trigger wäre dann das EraseRect? Zitat:Wenn ich es richtig verstanden habe muss ich dann zwischen BeginRefresh und Endrefresh auch das Rechteck mit in die DamageList aufnehmen, das der alten Cursor-Position entspricht. Wer ermittelt denn die Bereiche, die einen Refresh benötigen? Intuition oder ich oder beides (also ich füge meine Rechtecke mit OrRectRegion der bereits ermittelten ClippingRegion des Fensters hinzu)? Und werden dann eigentlich die ganzen BlitOperationen zwischen meinem Aufruf von BeginRefresh und EndRefresh direkt ausgeführt, oder erst anschließend alle auf einmal? Zitat:Das ist doch aber ziemlich inperformant, wenn ich alle Hex-Tiles und auch alle "darüber liegenden" Objekte neu blitte. Bisher läuft das Ganze bei mir so ab:
Zitat:Wäre das aber nicht was für nen scrollbaren Statusbereich o.ä.? [ - Antworten - Zitieren - Direktlink - ] |
16.02.2011, 12:33 Uhr Holger Posts: 8116 Nutzer |
Zitat:Nein. EraseRect macht, was der Name sagt, es löscht einen rechteckigen Bereich. Wobei die Definition von Löschen davon abhängt, wie der Hintergrund definiert ist. Standard ist Füllen mit der Hintergrundfarbe. Zitat: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. Zitat:Nicht der ClippingRegion, sondern der DamageListe. Das System ermittelt betroffene Bereiche, die durch Layer-Operationen oder durch Scrolling-Operationen beschädigt wurden. Wenn die Layer-Operationen durch Fenster-Operationen verursacht wurden, dann schickt Intuition den zu den Layern gehörenden Fenstern eine Refresh-Message. Zitat:Während. Oder gar nicht. Je nach aktuellem Clipping. Zitat:Nein, alles, was außerhalb der Clip-Bereiche liegt, hat keinen Effekt. Das ist ja der Sinn der Sache. Zitat:Braucht genausowenig ein eigenes Fenster. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
16.02.2011, 23:22 Uhr Reth Posts: 1858 Nutzer |
Zitat:Hm. Ich dachte, ich füge die Bereiche, die ich neu blitten möchte der umgewandelten DamageListe hinzu (also dem Clipping-Bereich). Wie komme ich denn an die DamageListe vor BeginRefresh? Und wie füge ich meine Bereiche dann hinzu? Habe beim Stöbern in den Funktionen nichts Entsprechendes gefunden! Ist dann mein bisheriges Vorgehen mit Installation/Deinstallation von ClippingRegions im Layer des Window-Rastports ohne Begin-/EndRefresh überhaupt systemkonform? Zitat:Kann ich denn die Aktualisierung mit BeginRefresh/EndRefresh auch bei Events wie MOUSEMOVE anwenden? Zitat:Dann kann ich mir ja die ganze Überdeckungsprüfung sparen! Zitat:Aber den eigenen Layer kann ich doch nutzen, damit ich schon mal das Scrolling usw. habe, oder? [ - Antworten - Zitieren - Direktlink - ] |
17.02.2011, 14:09 Uhr Holger Posts: 8116 Nutzer |
Zitat: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. 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. Zitat:Systemkonform ist es schon. Allerdings fehlt Dir der Refresh des Spielfeldes, wenn andere Fenster über Deinem Spielfeld bewegt oder geschlossen werden. Auf einem Custom-Screen ohne weitere Fenster kein Problem, allerdings ist selbst da mal schnell ein System-Requester geöffnet, wenn man nicht drüber nachdenkt. 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:Klar, dann kann es allerdings passieren, dass Du später eine RefreshMessage bekommst, obwohl inzwischen alles wiederhergestellt wurde. Zitat:Ja, genau das ist der Zweck des Clippings: Aktualisierungsroutinen zu vereinfachen, in dem man sie einfach komplett durchläuft, aber nur das tatsächlich zeichnet, was aktualisiert werden muss.Zitat:Dann kann ich mir ja die ganze Überdeckungsprüfung sparen! Nur wenn der Zeichenalgorithmus selbst im Verhältnis zu den Zeichenprimitven (sprich dem Blitting) viel Performance benötigt, lohnt es sich, diesen so anzupassen, dass er kleinere Teilbereiche effizienter abhandeln kann. Zitat:Wofür brauchst Du beim Scrolling einen eigenen Layer? -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
19.02.2011, 09:26 Uhr Reth Posts: 1858 Nutzer |
Zitat:Ah, ok. Danke. Sowas in der Art hatte ich mir schon gedacht, es aber in den Beschreibungen noch nicht gefunden! Zitat:Das wäre ja dann ca. das Gleiche, wie das, was ich bisher mache mit dem Unterschied, dass ich ein SMARTREFRESH-Window anlege, keine Überdeckungsermittlung mehr mache, sondern nur die sich ändernden Teile ermittle, damit die ClippingRegion setzr und alles zw. BeginRefresh und EndRefresh aktualisiere. Dabei binde ich auch das umgebende Rechteck des animierten Cursors an der alten Position vor seiner Bewegung mit ein (oder mache 2 Refreshs, einen vorher, einen nachher ist aber unperformanter). Allerdings hab ich dazu noch folgende Fragen: Wie ist es denn, wenn sich an vielen, weit auseinander liegenden Bereichen des Spielfeldes Dinge ändern? Dann ermittle ich doch mit OrRectRegion im Endeffekt eine riesengroße ClippingRegion, in der auch Dinge geblittet werden, die sich gar nicht geändert haben, oder? Wenn ich Ist denn dann OrRectRegion überhaupt das Richtige, oder brauche ich eine andere Rect-/Region-Funktion? Nach meinem Verständnis müsste OrRectRegion aber eigentlich das Richtige machen und wenn ich C code:richtig verstanden habe, dann liegen darin alle Rechtecke für die ClippingRegion. Aber wer sagt mir, dass Intuition daraus nicht ein umgebendes, großes Rechteck macht?struct RegionRectangle Und muss ich für die ermittelte ClippingRegion erst ein EraseRect machen? Zitat:Du meinst, weil ich bei MouseMove schon aktualisiert habe, Intuition das nicht merkt und mir ne Refresh-Message schickt? Hatte eigentlich geplant, alles zu kombinieren: INTUITICKS, MOUSEMOVE und Refresh-Messages. Dabei könnte ich dann die Refresh-Messages ja als erstes verarbeiten und mir merken, ob der Refresh schon gelaufen ist!? Zitat:Na der bietet das doch schon. Dachte da in der Art von den Statusleisten bei anderen RTSs, die sich von der Seite her einblenden (z.B. über HotKey o.ä.). Und der Layer würde dann das "Rein- und Rausscrollen" übernehmen können. [ - Antworten - Zitieren - Direktlink - ] |
21.02.2011, 12:16 Uhr Holger Posts: 8116 Nutzer |
Zitat:Und EraseRect aufrufst. 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:Nein, EraseRect rufst Du für das gesamte Spielfeld einmal auf, bevor Du es zeichnest. Wie alle Zeichenbefehle zwischen BeginRefresh und EndRefresh. Zitat:Ich glaube, da hast Du einen Denkfehler. 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. Zitat:Wenn Du mit Intuition-Fenstern hantierst, darfst Du nicht gleichzeitig mit Layern (direkt) hantieren, sondern musst dafür auch Fenster nehmen. Dann aber schießt Du mit Kanonen auf Spatzen. Du bewegst den Layer und musst dann auf die Refresh-Message des Systems warten, um betroffene Regionen wiederherzustellen. 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. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
27.02.2011, 20:28 Uhr Reth Posts: 1858 Nutzer |
Zitat:Ja, einigen wir uns darauf und Nein, ich kann es wahrscheinlich nicht besser. Idee hinter diesem Vorgehen ist, die benötigten Systemaufrufe zu minimieren. Sprich: Warum eine Blitoperation für ein Objekt rufen, das sich nicht geändert hat, auch wenn das System dann feststellt, dass die ClippingRegion nicht betroffen ist. Zitat:Aah, danke! Werd ich mir mal ansehen. [ - Antworten - Zitieren - Direktlink - ] |
01.03.2011, 19:15 Uhr Holger Posts: 8116 Nutzer |
Zitat:Wir reden aber immer noch vom AmigaOS, oder? Der Overhead eines Systemaufrufs spielt beim AmigaOS im Vergleich zur Blitoperation selber überhaupt keine Rolle. Außerdem fängst Du die Sache schon wieder falsch an. Implementiere einen straight-forward Algorithmus und schau dann, ob es Performanceprobleme gibt oder nicht. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
21.03.2011, 23:55 Uhr Reth Posts: 1858 Nutzer |
@Holger: Für das Straight-Forward-Verhalten hätt ich dann noch ne Frage: Welches Vorgehen ist denn besser: 1. Begin Refresh - Ermitteln aller geänderter Spielobjekte inkl. der alten Cursorposition - OrRectRegion für diese Objekte in neuer, eigener ClipRegion - InstallClipRegion mit der Ergebnisregion - EraseRect fürs Spielfeld - Blitten der Objekte - Reinstall OriginalClipRegion - EndRefresh oder wie hier im Bsp. dargestellt: 2. Begin Refresh - Ermitteln der alten Cursorposition - InstallClipRegion für dieses Objekt - EraseRect fürs Spielfeld - Reinstall OriginalClipRegion - Ermitteln 1. geändertes Spielobjekt - InstallClipRegion für dieses Objekt - EraseRect fürs Spielfeld - Blitten des Objektes - Reinstall OriginalClipRegion - Ermitteln 2. geändertes Spielobjekt - InstallClipRegion für dieses Objekt - EraseRect fürs Spielfeld - Blitten des Objektes - Reinstall OriginalClipRegion - ... - Ermitteln letztes geändertes Spielobjekt - InstallClipRegion für dieses Objekt - EraseRect fürs Spielfeld - Blitten des Objektes - Reinstall OriginalClipRegion - EndRefresh In beiden Fällen sollte mir Intuition für die alte Cursorposition außerhalb des Spielfelds den grauen Hintergrund wiederherstellen (wenn man mal den Statusbereich rechts auslässt)! Ist dem so, oder muss ich hier noch was machen? Im 2. Fall reicht EraseRect auch für das aktuell bearbeitete Objekt. Rein intuitiv würde ich eher zu Methode 1 neigen. [ - Antworten - Zitieren - Direktlink - ] |
22.03.2011, 15:03 Uhr Holger Posts: 8116 Nutzer |
Zitat:Dem ist so. Zitat:Ich auch. Schließlich ermöglicht die OR-Operation, dass Flächen bei überlappenden Objekten zusammengefasst und ein einem Rutsch aktualisiert werden. Je mehr veränderliche Objekte ins Spiel kommen, desto drastischer dürfte der Unterschied ausfallen. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
25.03.2011, 14:41 Uhr Reth Posts: 1858 Nutzer |
@Holger: Danke nochmal für Deine Hilfe. Jetzt steht mir "nur" noch mein Design im Weg (s. a. meine anderen Threads dazu). Derzeit hab ich das Message-Handling komplett in meiner Window-Klasse und die "Abnehmer" (also die, welche über aufgetretene Ereignisse informiert werden möchten) werden alle über eine parameterlose Methode angetriggert. Für den Refresh muss ich aber das Fenster (oder zumindest dessen Rastport) an die Klasse übergeben, die den Refresh durchführt (bisher hab ich nen Zeiger auf den RastPort in jedem darzustellenden Objekt liegen, da gehört er aber nicht hin)! Muss ich mal knobeln, wie ich das nun am besten designe bei meiner bestehenden Klassenkonstellation - hab zwar schon ein paar Ansätze, aber noch nichts konkretes! Da ich das Ganze auch in C++ mache, um in die Sprache reinzukommen, hab ich damit gerade z.T. doppelt Probleme. Z.B. versuche ich soviel Konstantes wie möglich zu machen (hatte ich als Empfehlung zu C++ so verstanden). Aber an den Schnittstellen zwischen den Systemfunktionen und -komponenten und meinen Klassen hab ich so meine Probleme, wie bei der Übergabe von BitMaps, die Grafiken enthalten. Diese sind in Frame-Klassen gekapselt. Wenn ich allerdings ein Frameobjekt blitten möchte, muss ich dessen BitMap nach außen geben, um sie z.B. in BltBitMapRastPort. Da die Funktion aber eine nicht-konstante BitMap erwartet kann ich diese in der Frame-Klasse nicht als const bzw. als const-pointer auf const zurückgeben. Zudem bin ich mir immer noch unschlüssig, wie ich die animierten Grafikklassen designe. Derzeit bekommt jedes Objekt den RastPort im Konstruktor mit, auf dem es sich darstellen/entfernen können soll (wobei dann die Blitoperation meiner RastPort-Klasse dafür gerufen und dabei der aktuelle Frame übergeben wird). Allerdings finde ich das nicht mehr so sinnvoll, da sich die Objekte theoretisch ja in unterschiedlichen RastPorts gleichzeitig anzeigen lassen könnten (auch wenn es evtl. an praktischen Hintergründen fehlt)! Insgesamt bin ich mir auch nicht ganz klar darüber, wo ich z.B. die Blit-Funktionen kapsele. Da ich derzeit nur eine benötige (BltBitMapRastPort), ist sie in meiner "RastPort-Klasse" enthalten. Dann gibt es ja aber noch die Blit-Operationen mit/auf BitMaps und die ganzen Draw-Funktionen. Hätte die alle gern zusammen in einer Klasse, aber die Basis des Ganzen ist doch sehr heterogen! Oder ist BltBitMapRastPort "nur ne Convenience-Funktion", da dann BltBitMap auf der BitMap im RastPort ausführt? Eine ca. 1:1-Abbildung von AOS-Libs oder ähnlichem hab ich mir nicht vorgenommen! Aber das sind alles schon wieder Themen für einige neue Threads! [ Dieser Beitrag wurde von Reth am 01.04.2011 um 10:10 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
04.04.2011, 11:39 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ja, pack das mal lieber in eigene Threads. Bekommt man sonst nicht so richtig mit, wenn Du Änderungen in einem älteren Beitrag machst. Vor allem, da das Forum keine Funktion hat, um sich die Änderungen anzeigen zu lassen... -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
10.04.2011, 14:29 Uhr Reth Posts: 1858 Nutzer |
@Holger: Jetzt noch ne Frage: Woher bekomme ich denn bei einer nicht von mir verursachten Refresh-Message mit, welche Bereiche denn betroffen sind, so dass ich sie zur Clipping Region hinzufügen kann? Nach meinem Verständnis von C code:wären diese Bereiche in der ClipRegion, die von dieser Funktion zurückgegeben wird, oder?InstallClipRegion() D.h., ich würde:
Zu dem Thema hier: Zitat:ist mir immer nocht nicht ganz klar, wann ich denn nun direkt mit Layern hantiere (bzw. hantieren darf) und wann nicht? Verstanden habe ich bisher, wenn ich ein Fenster habe, Hände weg von Layern. Aber wieso? Und wann kann/sollte ich denn Layer benutzen? Zum Thema Refresh: Wenn das Fenster kein "NOCAREREFRESH" angegeben hat, ist es dann automatisch im SIMPLEREFRESH oder SMARTREFRESH Modus, wenn nichts angegeben wird? Und noch eine Frage: Kann ich bei einem RastPort eines Fensters immer davon ausgehen, dass er eine gültige BitMap enthält? Gibt mir diese die Dimension der Zeichenfläche im RastPort an (z.b. für Koordinaten + Abmessungen für EraseRect, so dass ich nicht an Stellen des RastPorts komme, die ggf. außerhalb der Zeichenfläche liegen)? [ Dieser Beitrag wurde von Reth am 14.04.2011 um 22:49 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
15.04.2011, 11:55 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ich denke schon. Ich habe allerdings gerade keine Dokumentation zur Hand, um das noch mal genau zu überprüfen. Zitat:Im Fenster-System verschickt intuition an alle Beteiligten Refresh-Nachrichten, wenn Refreshs nötig sind, bzw. zeichnet auch schon mal Fensterrahmen und Gadgets selbst neu. Voraussetzung ist, dass intuition auch weiß, dass eine Situation eingetreten ist, die Refreshs nötig machen könnte. Deshalb sind sämtliche Layer-Operation tabu, die dazu führen könnten, dass irgendein Unbeteiligter einen Refresh durchführen müsste, von dem er dann nichts mitbekommt. Für alle diese Operationen gibt es aber Pendants, MoveWindow statt MoveLayer, WindowToFront statt LayerToFront, etc. 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. 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:Das sind zwei verschiedene Paar Schuhe. Der Refresh-Modus eines Fensters ist immer simple, smart oder super-bitmap. no-care ist ein zusätzliches Flag, das lediglich besagt, dass man keine Refresh-Nachrichten bekommen möchte. Zitat:Ja Zitat:Nein. Die BitMap ist mit Ausnahme von super-bitmap-refresh Fenstern die BitMap des Screens und hat dementsprechend deren Ausmaße, bzw. je nach Alignment ist sie sogar größer als der Screen. 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, d.h. Du kannst einfach munter draus los löschen, ohne etwas zu überschreiben. Der Nachteil ist, dass das Fenster dann zwei Layer besitzt (Overhead), einen für den Rahmen und einen für die Zeichenfläche. Normale Fenster haben nur einen Layer und Du musst selbst dafür sorgen, dass Du den Fensterrahmen nicht überschreibst. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
15.04.2011, 22:56 Uhr Reth Posts: 1858 Nutzer |
@Holger: Danke fürs Antworten! Zitat:Wann und warum kann ich denn dann überhaupt reine Layer ohne Fenster benutzen (sprich was wäre denn ein gutes Beispiel)? Zitat:Kann ich denn Scrolloperationen im eigenen Fenster durchführen, ohne Schaden anzurichten (nur mit Clipping, oder)? Zitat:Und welcher ist es, wenn ich nichts angebe? Zitat:Dann kann ich die Dimension der "bezeichenbaren Fläche" eines RastPorts nie ermitteln, ich muss immer die Dimension des Fensters und die Angabe GZZ ja/nein kennen, wenn ich die Dimension der "bezeichenbare Fläche" wissen will? [ - Antworten - Zitieren - Direktlink - ] |
18.04.2011, 10:39 Uhr Holger Posts: 8116 Nutzer |
Zitat:Wenn Du beispielsweise einen Custom-Screen öffnest und auf diesem niemals Fenster benutzt. Keiner sagt, dass es überhaupt sinnvolle Anwendungsmöglichkeiten dafür geben muss. Layers sind einfach das von intuition verwendete Back-End. So wie auch das input.device, für das es auch in den seltensten Fällen Gründe für die direkte Benutzung gibt. Zitat:Ja klar, der RastPort Deines Fensters enthält auch einen Pointer auf den Layer Deines Fensters, weshalb Scroll-Operationen in diesem RastPort auch korrektes Clipping verwenden. Zitat: Musst Du einfach mal in die includes gucken, welches dieser Flags den Wert 0 hat. Ich glaube, es war simple-refresh. Zitat:Sofern Du nicht durchgängig auf GZZ-Fenster setzt, ja. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
29.04.2011, 23:35 Uhr Reth Posts: 1858 Nutzer |
@Holger: Bin gerade über C code:gestolpert.GT_BeginRefresh(), GT_EndRefresh() und GT_RefreshWindow() Letzteres nutze ich schon, da ich Gadtools Gadgets verwende. So wie ich die Beschreibung verstehe, dient diese Funktion aber nur dem Aktualisieren der Gadgets. Sollte ich in meinem Fall dann besser GT_BeginRefresh() und GT_EndRefresh() verwenden, auch wenn ich meine Gadgets gar nicht mehr aktualisieren muss? Oder spielt das hier keine Rolle und ich kann BeginRefresh() bzw. EndRefresh() verwenden? Habe auch gerade gesehen, dass ich WFLG_NOCAREREFRESH mit Gadtools gar nicht verwenden darf/soll. Hatte damit bisher aber keine Probleme! [ - Antworten - Zitieren - Direktlink - ] |
01.05.2011, 14:38 Uhr Holger Posts: 8116 Nutzer |
Zitat:Woher weißt Du denn bei einem normalen Refresh-Zyklus, dass die Gadgets keinen Refresh benötigen? Zitat:Ich vermute mal, dass diese Beschränkung ab AOS3.0 keine Rolle mehr spielt, aber offiziell aufgehoben wurde sie nicht. Das hängt aber auch von den verwendeten Elementen ab, simple Objekte wie Buttons haben schon immer ohne expliziten Refresh funktioniert. Die korrekte Verwendung gemäß Spezifikation schließt aber NoCareRefresh aus. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
04.05.2011, 21:24 Uhr Reth Posts: 1858 Nutzer |
@Holger: Wenn wir gerade beim Thema sind, und weil ich auch gerade die Refreshmethoden in meine Windowklasse einbaue: Was ist denn mit den folgenden Funktionen: C code:?RefreshGadgets() und GT_RefreshWindow() Nach meinem Verständnis brauch ich die 2. nach dem initialen Hinzufügen von Gadgets zu einem Fenster, um die Gadgets anzuzeigen. Die erste Funktion benötige ich immer dann, wenn ich denke, dass die Gadgets refreshed werden müssen, oder wenn ich Gadgets verändert habe und deswegen aktualisieren will. Passt das soweit? Nach diesem Verständnis würde ich dann RefreshGadgets auch immer zwischen BeginRefresh und EndRefresh rufen, sobald ich eine Refresh-Message bekommen habe. Korrekt? Und noch eine Frage dazu: Zitat:Wenn ich nach getaner Arbeit den Originalzustand der ClippingRegion wieder herstelle, verursache ich damit nicht "neuen Damage" und komme so in einen "Teufelskreis"? 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? [ - Antworten - Zitieren - Direktlink - ] |
04.05.2011, 22:02 Uhr Holger Posts: 8116 Nutzer |
Zitat:Passt. Zitat:Nein. Intuition zeichnet Gadgets und Fensterrahmen selbsttätig neu, wenn es Damage verursacht hat und nur in diesen Fällen bekommst Du Refresh-Messages. Nur wenn Du hinterm Rücken von Intuition Damage verursacht hast (siehe vergangene Diskussion zu Scroll-Funktionen), der auch Gadgets betreffen könnte, musst Du den Refresh der möglicherweise betroffenen Gadgets selbst anstoßen. Ansonsten dient RefreshGadgets() ausschließlich zum Updaten nach Änderungen. Bei gadtools gibt es die Besonderheit, dass die Gadgets u.U. nicht alle Grafik-Informationen zum automatischen Neuzeichnen beinhalten. Das liegt daran, dass gadtools zumindest in älteren Versionen nicht auf BOOPSI aufsetzt (es war eine Parallelentwicklung). Genau deshalb gibt es die Funktionen GT_BeginRefresh und GT_EndRefresh, die die entsprechenden Intuition-Funktionen komplett ersetzen, wenn man gadtools benutzt. Diese Funktionen rufen nicht nur BeginRefresh und EndRefresh auf, sondern führen auch die für den kompletten Gadget-Refresh nötigen Zeichenbefehle aus. Deshalb sieht die Trivial-Routine zum vollständigen Refresh eines Gadtools-Fenster (wenn man eine Refresh-Message bekommen hat, wohlgemerkt), das außer Gadgets nicht anderes enthält, genau so aus: code:Weil aber mindestens diese zwei Routinen für einen Refresh aufgerufen werden müssen, arbeiten Gadtools-Oberflächen auch nicht mit NoCareRefresh zusammen.GT_BeginRefresh(); GT_EndRefresh(); Zitat: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. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
04.05.2011, 23:15 Uhr Reth Posts: 1858 Nutzer |
@Holger: Danke! Zitat:Aber mit der unter "Letzteres" genannten Lösung manipuliere ich ja die ClippingRegion nicht, sondern installiere meine eigene, die ich aus allen zu aktualisierenden Bereichen ermittle. Dann werden alle Objekte neu gezeichnet und abschließend wird die bei BeginRefresh erzeugte originale ClippingRegion wieder installiert. Oder hab ich das falsch verstanden? 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? [ - Antworten - Zitieren - Direktlink - ] |
05.05.2011, 19:34 Uhr Holger Posts: 8116 Nutzer |
Zitat:Den Teil hatte ich wohl überlesen. Mir ging es nur darum, dass alles zwischen BeginRefresh und EndRefresh stattfindet. Zitat: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. Die Alternative wäre zwei Zeichenvorgänge durchzuführen, einen mit der Clip-Region, die von BeginRefresh installiert wurde, und einen mit Deiner Clip-Region. Der Vorteil des Verknüpfens liegt darin, dass Bereiche, die sowohl "beschädigt", als auch von veränderten Objekten betroffen sind, nur einmal gezeichnet werden. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
05.05.2011, 23:53 Uhr Reth Posts: 1858 Nutzer |
Zitat:Aber wenn ich in diesem Fall die OriginalRegion nach EndRefresh wieder herstelle, wird dann nicht auch wieder das Damage-Flag gesetzt und die in dieser alten Region enthaltenen Bereiche ebenfalls wieder als beschädigt angesehen? Damit wäre doch einiges umsonst gewesen und die Katze beißt sich ein bisschen in den eigenen Schwanz, oder? [ - Antworten - Zitieren - Direktlink - ] |
06.05.2011, 12:31 Uhr Holger Posts: 8116 Nutzer |
Zitat: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. 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. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
06.05.2011, 17:30 Uhr Reth Posts: 1858 Nutzer |
Zitat:Ja, Herr Lehrer! Mein Fehler! Hast ja recht und soll auch nicht passieren! Zitat:Danke! Das wollte ich wissen und es hilft weiter! Aber mal OT für alle: So interessant und hilfreich die ganze Diskussion ist (und ich bin Dir überaus dankbar für Deine/eure Hilfe), zeigt sie doch auch ein großes Manko bei der Programmierung von AOS: Man muss das System ja fast auswendig kennen, um vernünftig dafür programmieren zu können. Das ist in der heutigen Zeit ein sehr großer Nachteil in meinen Augen, da Entwickler für alle neueren Systeme doch einfach nur ihre Ideen umsetzen wollen, ohne das ganze System dafür in- und auswendig kennen zu müssen (wiederhole hier mal nen Teil, den jmd. schon in nem anderen Thread gepostet hat)! Dem AOS fehlt eine vernünftige, einfach zu nutzende High-Level-API (die einzig Vergleichbare, die ich hier kenne ist die von Java, speziell 1.4 - einfach, intuitiv, leicht erlernbar und leicht bedienbar; man kann sich auf das Problem konzentrieren und muss sich nicht mit der "Infrastruktur" herumplagen! So lange das nicht behoben ist, wird es mit neuer Software eher schlechter werden als besser!) Meine Meinung dazu! [ - Antworten - Zitieren - Direktlink - ] |
06.05.2011, 19:13 Uhr Holger Posts: 8116 Nutzer |
Zitat:Gut, aber ich fasse es trotzdem nochmal zusammen: Zitat:Ich glaub', das habe ich schon mal irgendwo gelesen Mit Hollywood gibt es ja sogar eine. Allerdings ist diese halt kommerziell. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
08.05.2011, 18:09 Uhr Reth Posts: 1858 Nutzer |
Zitat:Habe mich damit noch nicht beschäftigt, auch noch nicht mit den SDKs für AOS4 und MOS bzw. den Möglichkeiten, die AROS hier bietet. Sind denn die "Executables" von Hollywood auch performant und leistungsfähig genug z.B. für echte 68060er oder gar 68040er? [ - Antworten - Zitieren - Direktlink - ] |
08.05.2011, 18:32 Uhr Holger Posts: 8116 Nutzer |
Zitat:Keine Ahnung, das ganze liegt nicht so sehr in meinem Interessengebiet. Ich glaube auch, dass "leichter Einstieg" und "kommerzielles SDK" keine günstige Kombination sind. Ich erwähne das Produkt nur der Fairness halber. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
08.05.2011, 23:00 Uhr Reth Posts: 1858 Nutzer |
@Holger: Finde ich auch gut so. Hatte gerade viele Antwortzeilen geschrieben aber nicht abgeschickt, da dies nicht mehr Thema dieses Threads ist. Würde gern einen neuen aufmachen, fürchte aber, das eine ggf. entstehende Diskussion u.U. weniger konstruktiv ausfallen könnte! [ - Antworten - Zitieren - Direktlink - ] |
08.05.2011, 23:33 Uhr Holger Posts: 8116 Nutzer |
@Reth: Na ja, einiges dazu findet sich im letzten Drittel dieses Threads: http://www.amiga-news.de/forum/thread.php?id=33913&BoardID=1 (und bestimmt auch schon in älteren) -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
1 -2- 3 4 5 6 | [ - Beitrag schreiben - ] |
amiga-news.de Forum > Programmierung > Neue Frage zu Überdeckungen | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |