|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Autoscroll-Screens und mehr | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- | [ - Beitrag schreiben - ] |
|
22.07.2007, 10:15 Uhr uho Posts: 114 Nutzer |
Habe letztens mal einen Abend versucht, einen Autoscroll-Screen (ähnlich wie es auch auf der WB möglich ist) zu proggen. Kam leider - auch mangels Literatur, da auswärts - nicht recht zum Zuge. Der Screen soll - Autoscroll haben - kein Overscan - kein Fenster - evtl. Gadgets direkt im Screen - automatisch aktiviert sein Anschauungsbeispiel: ältere Versionen von ABackup Der Screen soll Autoscroll haben, jedoch keinen Overscan, da dieser ja von den Prefs des jeweiligen Users abhängig ist, die Darstellung jedoch immer gleich sein soll. Kein Fenster, da ich mal gelesen habe, daß die Darstellung mit häufigen Systemaufrufen (z.B. Pixel setzen) schneller sein soll, da man sich das ständige Hangeln durch die Windows-Struktur spart (stimmt das ?) und man auch selber durch direktes verändern der Bytes in den Screen schreiben können soll. Außerdem stören für diesen Fall Windows-Elemente nur. Ich benutze OpenScreenTags() mit SA_Type, CUSTOMSCREEN, SA_DisplayID, HIRES_KEY, (also 640x256) SA_WIDTH, 1280 und SA_AUTOSCROLL, TRUE. Funzt aber nicht: Sobald der Mauszeiger an den rechten Rand kommt, verschwindet er, um später am linken Rand wieder aufzutauchen. Dann sind jedoch der aktive (Klick)punkt und die Darstellung des Mauszeigers nicht mehr identisch; man kann nichts mehr gezielt anklicken (Abstand wahrscheinlich 640). Der Screen scrollt gar nicht. Nehme ich noch SA_Overscan, TRUE (oder muß hier ein Wert hin ?) dazu, scrollt der Screen - aber erst nach öffnen eines Fensters (WA_Flags, ACTIVATE) oder Anklicken und natürlich mit Overscan :-(. IMHO gibt es kein Screen-Flag fürs Aktivieren. Bei ABAckup geht das aber. (Test: LAmiga+LMB drücken und Screen runterziehen, loslassen, bei Bewegen der Maus an den unteren Bildschirmrand scrollt der aktive (!) Screen hoch. Geht bei ABackup, in meinem Beispiel aber erst nach Öffnen eines Fensters oder vorherigem Anklicken mit LMB) Vielleicht kann mir ja diesmal jemand helfen. Da ich noch nicht viele Versuche unternommen habe, sollten die Chancen besser als sonst sein ;-) Gruß uho [ - Antworten - Zitieren - Direktlink - ] |
|
22.07.2007, 11:53 Uhr thomas Posts: 7716 Nutzer |
@uho:Zitat: Da gibt's alles, was du brauchst: http://www.haage-partner.de/download/AmigaOS/NDK39.lha Zitat: SA_Overscan,OSCAN_TEXT wäre richtig. Zitat: Ohne Fenster geht eh nichts. ABackup öffnet vermutlich ein Backdrop-Fenster. Zitat: WA_Flags,WFLG_ACTIVATE oder WA_Activate,TRUE Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
23.07.2007, 14:39 Uhr Holger Posts: 8116 Nutzer |
Zitat:Nein, das stimmt nicht. Es gibt keine Zeichenbefehle, die mit einer Windows-Struktur zu tun haben. Zeichenbefehle werden auf einem RastPort angewendet, und abhängig davon, ob dieser einen Verweis auf einen Layer besitzt, findet ein Clipping statt oder eben nicht. Der Overhead des Clippings ist aber minimal, da dabei keineswegs alle Fenster durchsucht werden (was auch wiederum keine Rolle spielen würde, wenn man nur eines hat). Im Falle des Setzens eines einzelnen Pixels ist das Setzen selbst der Performance Fehler. In nahezu allen praxisrelevanten Fällen ist es effizienter in eine private BitMap, bzw ein byte-array zu schreiben und dieses mit einem Systemaufruf zu übertragen. Wenn's unbedingt sein muss, benutzt man dazu eine private Kopie des RastPorts mit gelöschtem Layer-Pointer. Dann muss aber absolut gewährleistet sein, dass man innerhalb der korrekten Grenzen zeichnet. Übrigens besitzen ab AOS2.0 auch Screens Layer. Somit ist der angebliche Overhead von Fenstern auch dann präsent, wenn gar keine Fenster geöffnet wurden. Zitat:das wiederum widerspricht komplett der vorhergehenden Betrachtung. Was interessiert die Performance des Systemaufrufs, wenn Du ihn gar nicht benutzt? Außerdem ist es definitiv ineffizient, mit der CPU im Bildschirmspeicher herumzumalen. Zitat:Man kann keine Screens aktivieren. Man kann nur Fenster aktivieren. Alles andere hat thomas schon gesagt. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
23.07.2007, 20:05 Uhr uho Posts: 114 Nutzer |
@Thomas,Holger: Erstmal danke für die Antworten. Allerdings muß ich nochmal nachhaken: > "Ohne Fenster geht eh nichts. ABackup öffnet vermutlich ein > Backdrop-Fenster." Man kann also keine Gadgets direkt an den Screen anhängen ? In der NewScreen-Struktur ist doch Platz für einen Gadget-Zeiger ? Und zu dem Problem "Autoscroll ohne Overscan" habt Ihr Euch leider gar nicht geäußert. Bedingt das Eine das Andere oder mache ich nur bei den Flags was falsch ? OSCAN_TEXT ist wohl der kleinste, aber doch eben ein Overscan. Auch habe ich keine Info gefunden, wieviele Pixel das denn sind. Gruß uho [ - Antworten - Zitieren - Direktlink - ] |
|
23.07.2007, 21:42 Uhr ZeroG Posts: 1487 Nutzer |
@uho: Die Anzahl der Pixel solltest du z.B. im Overscan-Einsteller im Prefs-Verzeichnis finden. Außerdem ist es bestimmt nicht verkehrt zusätzlich zu den Autodocs auch mal in die Includes zu gucken: Zitat: [ - Antworten - Zitieren - Direktlink - ] |
|
24.07.2007, 20:22 Uhr uho Posts: 114 Nutzer |
Zitat: Das OSCAN_TEXT 1:1 die Einstellung im Prefs-Fenster meint, darauf bin ich kurz nach Absenden meines Beitrags auch gekommen - naja  Den o.g. Abschnitt in den Includes hatte ich schon vorher entdeckt. Jedoch erfährt man da eben gerade _keine_ konkrete Pixelzahl (da User-Einstellung). Es ging aber gerade darum, sich von den Overscan-Einstellungen unabhängig zu machen. Also bitte die Fragestellung genauer lesen ! uho [ - Antworten - Zitieren - Direktlink - ] |
|
24.07.2007, 23:36 Uhr NoImag Posts: 1050 Nutzer |
@uho: OSCAN_TEXT ist die Voreinstellung von SA_OVERSCAN. Hast Du denn die obigen Tipps mal umgesetzt? Es gibt keinen Grund, kein Fenster auf dem Screen zu öffnen. Verwende ein simplerefresh, backdrop und borderless Fenster. Tschüß [ - Antworten - Zitieren - Direktlink - ] |
|
03.08.2007, 10:45 Uhr uho Posts: 114 Nutzer |
(sorry, hatte nicht gleich Zeit) Hallo, mittlerweile habe ich einige Tests gemacht und Folgendes herausbekommen: a) Autoscroll OHNE Overscan scheint wirklich nicht zu funzen. Allerdings habe ich dazu keine "offiziellen" Infos. b) Verwendet man Overscan, ist man auf Teufel komm' raus von den User-Prefs abhängig: Niemand hindert einen daran, die OSCAN_TEXT-Einstellung in den unsichtbaren Bereich zu verschieben bzw. auf die Maximalwerte einzustellen. Man kann zwar die Fenstergröße automatisch anpassen, z.B. WA_Top, Screen->BarHeight+Screen->BarVBorder, WA_Height,Screen->Height-Screen->... ...BarHeight-Screen->BarVBorder, Im allgemeinen hat man bei Pixelgrafik aber feste Abmessungen (siehe Wator). Außerdem lassen sich die dahinterstehenden Algorithmen oft nur aufwendig und/oder unter Leistungsverlust variabel gestalten. Der Aufwand steht dabei in keinem Verhältnis zum Nutzen ! c) Wie von Euch vermutet, verwendet ABAckup tatsächlich ein BORDERLESS-Fenster. Dies habe ich mittels RSys feststellen können, da dort neben den Screens auch die Fenster angezeigt werden. Als Flags wurde dort 0x00001900 angezeigt. Das läßt sich zerlegen in: 0x00001000 WFLG_ACTIVATE 0x00000100 WFLG_BACKDROP 0x00000800 WFLG_BORDERLESS So ein Fenster habe ich dann auch geöffnet. Allerdings war bei mir die Titelzeile noch zu sehen. Das lag daran, daß ich WA_Title, " " bei OpenWindowTags() angegeben hatte. Das stammte noch aus Zeiten, als ich OpenWindow() ver- wendet habe - bei der man es nicht weglassen konnte. Bei OpenWindowTags() dagegen gibt man einfach nichts an und die Titelleiste verschwindet auch. Übrigens ist mir aufgefallen, daß BACKDROP-Windows auch hinter der Screen-Leiste verschwinden. Dieser Speicherbereich kann dann sowohl von Intuition als auch von mir beschrieben werden. Führt das nicht zu Komplikationen ? Wird an dieser Stelle das Zeichnen einfach geblockt ? Oder muß ich selber darauf achten, daß das Fenster erst unterhalb der Screenleiste beginnt ? Ein normales Fenster würde die Screenleiste ja einfach überdecken... d) Um die o.g. Nachteile mit variablem Overscan zu vermeiden, kann man stattdessen SA_DClip, dclip_rect, angeben, wobei dclip_rect auf eine struct Rectangle- Struktur zeigen muß, die den den zu scrollenden Bereich - z.B. 640x256 - bestimmt. Großer Nachteil: Oberhalb des Screens, der ja i.A. unter- halb des Overscan-Bereiches beginnt, sieht man nicht die Hintergrund-Farbe, sondern dahinterliegende Screens. Der geöffnete Screen läßt sich nichtmal nachträglich über die ursprüngliche Position schieben ! Läßt man deshalb den Ausschnitt bei Zeile 0 beginnen, liegt er meist im unsichtbaren Bereich. Also auch keine optimale Lösung. So. Lange Rede, langer Sinn :-) Ich habe viel herausgefunden, bin aber nicht wirklich am Ziel. Keine Variante ist optimal: Entweder alles variabel (aber: feste Größe des Bildschirminhaltes) oder Sichtbarkeit mehrerer Screens... Die Antworten von Euch haben mir immerhin den Weg gewiesen. Herausgefunden habe ich letztlich das meiste selbst (und das nur durch Probieren, da in den Büchern stets nur die Verwen- dung der Standard-Parameter beschrieben wird). Keiner konnte mir die Frage beantworten, ob Autoscroll Overscan vorraussetzt. Niemand hat die Möglichkeit von SA_DCLIP erwähnt. Evtl. gibt es sogar noch weitere Variationen, die ich noch nicht herausgefunden habe. Es gibt so viele gute Programme für den Amiga. Aber manchmal frage ich mich wirklich: Wer hat sie geschrieben ? mfg uho [ - Antworten - Zitieren - Direktlink - ] |
|
03.08.2007, 11:39 Uhr thomas Posts: 7716 Nutzer |
@uho: Irgendwie verdrehst du alles. Deine Ausführungen machen keinen Sinn. Du öffnest einen Autoscroll-Screen. D.h. dein Screen ist größer als die Anzeige. Nehmen wir mal 1280x1024. Davon zeigst du nur einen Teil an. Dieser Teil wird durch die Overscan-Einstellungen begrenzt. Z.B. 640x256 oder eben 724x283. Dann sprichst du von Algorithmen und Overhead. Das hat absolut nichts miteinander zu tun. Deine Algorithmen beziehen sich immer auf die Größe der Bitmap (also 1280x1024). Der sichtbare Bereich wird ohne jeden Overhead von der Hardware aus dem Bitmap-Speicher übernommen. Es ist vollkommen irrelevant, ob die Overscan-Einstellungen auf 640x256 oder 724x283 oder irgendwas dazwischen stehen. Zitat: NewWindow.Title = NULL ist durchaus möglich. Zitat: Auch hier kannst du WA_Title,NULL angeben, wenn du es denn unbedingt willst. Zitat: Kommt drauf an, wohin du zeichnest. Wenn du direkt in die Bitmap des Screens zeichnest (was absolut verboten ist), dann überklatscht du auch die Titelzeile. Wenn du aber mit dem RastPort deines Fensters arbeitest, dann übernimmt das Betriebssysten das Clipping für dich. Wenn du die Titlezeile des Screens verstecken möchtest, laß einfach das Backdrop weg. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomasrapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
03.08.2007, 12:26 Uhr whose Posts: 2156 Nutzer |
@thomas: SA_Quiet = TRUE und das Backdrop auf volle Größe? Grüße -- ---  µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Antworten - Zitieren - Direktlink - ] |
|
03.08.2007, 17:43 Uhr Holger Posts: 8116 Nutzer |
Zitat:Richtig, und volle Größe erreicht man am einfachsten, in dem man gar keine Größenangaben macht. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
03.08.2007, 18:12 Uhr ZeroG Posts: 1487 Nutzer |
@uho: Wenn du mit " " einen Zeiger auf einen leeren String übergibts ist es völlig richtig das du eine "leere" Titlezeile siehst. [ - Antworten - Zitieren - Direktlink - ] |
|
04.08.2007, 00:38 Uhr NoImag Posts: 1050 Nutzer |
Zitat: Ich habe Dich darauf hingewiesen, dass OSCAN_TEXT die Voreinstellung von SA_OVERSCAN ist. Anders geschrieben: Wenn Du SA_OVERSCAN weglässt, dann ist dies dasselbe, als wenn Du "SA_OVERSCAN, OSCAN_TEXT," angibst. Tschüß [ - Antworten - Zitieren - Direktlink - ] |
|
04.08.2007, 10:46 Uhr whose Posts: 2156 Nutzer |
Zitat: Manchmal verstehen die Leute mehr, wenn man Details einstweilen wegläßt  @uho: Die Frage ist lange beantwortet, Du hast es nur nicht mitbekommen. Für einen Autoscroll-Screen ist es egal, wie groß Du das "Sichtfenster" gestaltest. Es wird aber kein Overscan vorausgesetzt dafür. Alles, was evtl. benutzter Overscan verändert, ist der tatsächlich auf dem Monitor sichtbare Ausschnitt der Bitmap eines AutoScroll-Screens. Der ist dann halt mal größer oder mal kleiner, je nach dem, ob Du OSCAN_TEXT, OSCAN_STANDARD, OSCAN_MAX oder OSCAN_VIDEO wählst. Und wie NoImag schon sagte: Wenn Du "normal" arbeitest (also nicht direkt einen View bastelst o.Ä.) und keine Sonderwünsche beim Öffnen des Screens anmeldest dann wird so oder so die Standard-Einstellung benutzt, die OSCAN_TEXT ist. Desweiteren solltest Du mal etwas in den Includes und den RKMs stöbern. Da gibt es z.B. eine DisplayInfo-Struktur, in der viele interessante Sachen über Deinen just kreierten Screen/View drin stehen. U.A. die tatsächlich sichtbare Größe in Pixeln, aktueller Overscan-Modus und noch vieles mehr. Beschäftige Dich mal damit. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Antworten - Zitieren - Direktlink - ] |
|
07.08.2007, 17:15 Uhr Holger Posts: 8116 Nutzer |
Zitat:Es ist aber leider nicht ganz richtig. Wenn man keine Größenangabe macht oder STDSCREENWIDTH, bzw. STDSCREENHEIGHT benutzt, bekommt man die OSCAN_TEXT Größe, die de-facto kein Overscan bedeutet, weil der Bereich ja komplett im sichtbaren Bereich sein sollte. Wenn man aber einen explizite Größenangabe macht und weder SA_Overscan noch SA_DClip angibt, wird der Display-Bereich auf dieselbe Größe gesetzt. Das weiß kaum einer, weil diese Konstellation zusammen mit einem übergroßen Bildschirm keiner benutzt. Zitat:Nicht ganz. Wenn das Sichtfenster genauso groß wie die BitMap ist, gibt es nichts zu scrollen. Und genau das ist bei der Kombination „keine Angabe zum Overscan“ und „übergroßer Screen“ passiert. Zitat:Richtig, kein Overscan, aber eine explizite Angabe zum Sichtfenster, entweder via SA_Overscan oder via SA_DClip. Da uho eigentlich nicht "kein Overscan", sondern eigentlich "exakt 640 Pixel breites Sichtfenster" haben will, ist SA_DClip die einzige Möglichkeit für ihn. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
07.08.2007, 17:45 Uhr Holger Posts: 8116 Nutzer |
Zitat:Was Du meinst, ist, dass exakt 640 Pixel Sichtfenster mit einem übergroßen Screen nicht so einfach zu programmieren ist. Das braucht aber auch so gut wie nie einer. Wenn Du einen Screen ohne Overscan-Angabe, aber einer übergroßen Breitenangabe, öffnest, wird der Display-Clip auf eben jene Breite gesetzt. Das entspricht bei Deiner extremen Bereite auch dem von Dir beschriebenem Phänomen, dass die Maus schon wieder links rauskommt. Aber schau mal an den rechten Rand: das ist Overscan. Zitat:Daran kannst Du den User sowieso nicht hindern, weil selbst mit einer exakt auf 640 Pixel festgeschriebenen Screengröße bestimmt die User-Einstellung die Zentrierung auf dem Bildschirm, kann ihn also auch aus dem Bildschirm herausschieben. Aber wo ist das Problem, glaubst Du im ernst, der Benutzer hat nichts besseres zu tun, als die Einstellung, die für alle Programme gilt, auf unsinnige Werte zu setzen? Zitat:Das hat auch nicht das gerinste mit irgendeinem vorher diskutierten Thema zu tun... Zitat:Ach was Zitat:Vermutlich ist das, was Du willst, zu erreichen, in dem Du mittels QueryOverscan(HIRES_KEY, &Rect, OSCAN_TEXT ) den Textbereich ermittelst, dann das Rechteck dahingehend veränderst, dass Du die X-Position um die Hälfte der Differenz zwischen Deinen gewünschten 640 und der in diesem Rechteck angegebenen Breite vergrößerst (zum Zentrieren) und die Breite auf Deine gewünschten 640 setzt. Dieses Rechteck gibst Du dann bei SA_DClip an, setzt die Höhe des Screens explizit auf 256. Dann wäre der Screen vertikal verschiebbar, aber nicht aus dem OSCAN_TEXT Bereich heraus, gut, nach unten geht immer. Horizontal wäre der sichtbare Bereich zentriert und auf 640 fixiert, somit scrollbar. Natürlich bleibst Du damit von User-Einstellungen abhängig, aber daran solltest Du Dich beim Programmieren gewöhnen. Du programmierst für den User, nicht gegen ihn. Zitat:Doch, Overscan wird, das wurde mehrfach gesagt, nicht vorausgesetzt. Aber, das wurde leider nicht gesagt, das Scrollen an sich (nicht das Autoscroll) erfordert einen explizit definierter sichtbarer Bereich. Dass dieser kleiner als der Inhalt sein muss, damit es was zum Scrollen gibt, ergibt sich allerdings durch einfache Logik. Zitat:Weil es unnötig kompliziert ist. Es weiß auch immer noch niemand, warum zum Teufel Du unbedingt exakt 640 Pixel Breite brauchst, und was an der Möglichkeit, dass der Benutzer etwas konfiguriert haben könnte, so schlimm ist. Bist Du Dir sicher, dass das AmigaOS das richtige für Dich ist? Es gibt andere Betriebssysteme, da kann der User überhaupt nichts verstellen... Zitat:Ich kenne keines, das so programmiert ist, wie Du es machen willst. Wenn Du für unnötige Verkomplizierungen nicht genügend Vorschläge bekommst, wie man es noch komplizierter machen kannst, beschwer Dich nicht auch noch. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
08.08.2007, 21:26 Uhr uho Posts: 114 Nutzer |
Hallo, hatte leider wieder bischen Zeitnot... @thomas: Zitat: Das ist ein Mißverständnis. Ich habe nie gesagt, daß ich vertikal scollen will. Sieht man auch an meinem Code-Beispiel. Allerdings hatte ich es nicht explizit erwähnt. Die Bildschirmabmessungen sind zwar konstant, die Overscan-Prefs aber nicht. Die Grafik (konstanter Größe) wird in Felder aufgeteilt. Außerdem sollen am unteren Rand auch Gadgets zu sehen sein. Bei variablem Overscan kann man nicht sagen, wie groß der sichtbare Ausschnitt wirklich ist - was ungünstig/fatal für die Darstellung der Grafik bzw. die Nutzbarkeit der Gadgets sein kann. Mein Kompromiß dazu: s.u. @whose: Der Tip mit SA_QUIET ist wirklich genial ! Man kann ein BACKDROP- BORDERLESS-Fenster nutzen und sieht dennoch nichts von Intuition. Funktioniert auch einwandfrei (und spart evtl. paar Taktzyklen). Mir macht allerdings Gedanken, daß SA_Quiet per #define SCREENQUIET ist. Und dieses steht zusammen mit einigen anderen Flags unter der Überschrift "FLAGS SET BY INTUITION" - also eher nicht für User. Ob das noch bei OS 3.2 funktioniert ? >:-) @whose+NoImag: Zitat:Zitat: Zitat: Lest doch bitte wenigstens Eure eigenen Beiträge ! Die Frage war eben bis zu diesem Zeitpunkt noch NICHT beantwortet, da - wie ja NoImag gerade selbst darlegte - OSCAN_TEXT die Vorein- stellung von SA_Overscan ist. Das Weglassen dieses Tags bedeutet also gerade NICHT, daß man keinen Overscan benutzt. Frage war vielmehr, wieso Autoscroll nicht mehr geht und der Mauszeiger verrückt spielt, wenn man Overscan abschaltet (also SA_Overscan, FALSE)... So wie ich das inzwischen sehe, ist "FALSE" einfach ein falscher Parameter und Overscan läßt sich nur indirekt durch Nutzung von SA_DClip abschalten. Siehe dazu auch den Beitrag von Holger. @Holger: Zitat: Ist das ein dokumentiertes Verhalten oder sollte man aus Kombatibilitätsgründen die Fenstergröße doch lieber explizit hinschreiben ? Der letzte Beitrag war übrigens aufschlußreich. Danke. @alle: So wie es mir vorschwebte (eine zentrierter, scrollender Bildaus- schnitt mit exakt 640x256, ringsherum Hintergrundfarbe) ist wohl direkt nicht möglich. Da man mit SA_DCLIP die Darstellung entweder am (meist unsicht- baren) oberen Rand hängen hat oder aber darunterliegende Screens sieht, werde ich wohl Folgendes machen: Ich öffne den Screen mit SA_Text, frage die tatsächliche Größe ab und baue dann meine Darstellung mit z.B. 1200x256 zentriert auf (mit Rändern ringsherum, um die Sichtbarbkeit zu garantieren). Das kostet zwar bischen Chip-Mem (und wohl auch DMA-Zyklen), ist aber ein annehmbarer Kompromiß. Zumindest weiß ich nun, was machbar ist und was nicht und habe sogar einige Extra-Tips erhalten. Danke. Jedenfalls danke für die Mühe ! Nächster Schritt ist dann eine Bitmap zum direkten Reinschreiben. Mal sehen, ob ih das alleine gebacken bekomme. Bei den Vortests ist mir schonmal aufgefallen, daß ein Screen gar keinen eigenen (Bildschirm)Speicher zu haben scheint. Jedenfalls ist der Speicherverbrauch des ersten geöffneten Fensters ähnlich - egal, ob man SIMPLE- oder SMART_REFRESH angibt. Erst beim zweiten Fenster unterscheidet sich der verbrauchte Speicher wie erwartet. Gruß uho P.S.: Einige Passagen haben sich mittlerweile erübrigt, jedoch kann ich jetzt nicht nochmal alles umschreiben, da ich online bin, ein Gewitter aufzieht und ich Euch nicht noch länger warten lassen will. Jedenfalls nochmals danke für die ausführlichen Antworten. Das war diesmal wirklich besser ! [ - Antworten - Zitieren - Direktlink - ] |
|
09.08.2007, 00:11 Uhr NoImag Posts: 1050 Nutzer |
Zitat: So wie ich die RKRMs verstehe, ist die Verwendung von SA_QUIET legal. Zitat: Richtig. So wie Du den Begriff Overscan benutzt, kann Overscan nicht abgeschaltet werden. Das ist doch der entscheidende Punkt. Wie ich finde, hat Holger aber zum Begriff Overscan schon alles klargestellt. Zitat: Dass SA_Overscan, FALSE falsch ist, war doch schon lange gesagt. Zitat: siehe oben. Zitat: Zu jedem Screen gehört eine Bitmap. Diese Bitmap ist der Bildschirmspeicher des Screens, d.h. natürlich hat jeder Screen eigenen Bilschirmspeicher. Ein Simple-Refresh-Fenster verbraucht keinen eigenen Bildschirmspeicher. Ein Smart-Refresh-Fenster verbraucht erst dann eigenen Bildschirmspeicher, wenn es von einem anderen Fenster (teilweise) verdeckt wird. Daher gibt es erst beim zweiten Fenster einen Unterschied (daher Smart-Refresh). Es gibt dann auch noch No-Care-Refresh. Tschüß [ - Antworten - Zitieren - Direktlink - ] |
|
09.08.2007, 12:39 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ist es nicht. Diese Symbole haben völlig unterschiedliche Werte und werden auch in unterschiedlichem Kontext verwendet, SCREENQUIET in einer Flagvariablen (UWORD) und SA_Quiet als TAG_KEY (ULONG). Zitat:SCREENQUIET wird von intuition in den Flags des Screens gesetzt, wenn die Anwendung SA_Quiet,TRUE beim Öffnen mit angegeben hat. "Set by intuition" impliziert, dass man dieses Flag nicht selbst in der Screen-Struktur ändern darf, also dass man es nicht nachträglich ändern darf/kann, weil es im OS3.x keine Funktion ala ChangeScreen(myScreen, SA_Quiet, TRUE) gibt. Zitat:Habe jetzt keine Dokumentation diesbezüglich gefunden, aber das ist seit AOS2.0 so, und ich wüsste nicht, welchen default man sonst wählen sollte. Ansonsten kann man auch SA_Width,~0,SA_Height,~0,SA_AutoAdjust,TRUE benutzen, wobei man SA_AutoAdjust,TRUE auch weglassen kann, wenn man OpenWindowTags(NULL, ...) benutzt. (Das ist dokumentiert)Zitat:Ist das ein dokumentiertes Verhalten oder sollte man Zitat:Wenn Du SA_Exclusive,TRUE benutzt, gibt es nichts dahinter zu sehen. Sollte man aber nur einsetzen, wenn es wirklich sinnvoll ist. Autoscroll und Einschränkungen bezüglich DisplayClip, bzw. Sichtbarkeit dahinterliegender Screens passen konzeptionell eigentlich nicht zusammen. Vielleicht solltest Du Deine Intention etwas ausführlicher erkläutern. Zitat:Vermutlich schon. Zitat:Anders herum. Fenster haben (normalerweise) keine eigene BitMap. Ich habe Dir ja schon am Anfang gesagt, dass es den angeblichen Overhead geöffneter Fenster eigentlich gar nicht gibt. Zitat:Kleiner Tipp: Nur SimpleRefresh Fenster verwenden. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
09.08.2007, 22:56 Uhr NoImag Posts: 1050 Nutzer |
Zitat: Habe ich Dich jetzt missverstanden? Wenn man eine NewWindow-Struktur verwendet, wie will man dann die Größenangabe des Fensters weglassen? Wenn man aber OpenWindowTags(NULL, ...) benutzt, dann braucht man nicht nur nicht SA_AutoAdjust,TRUE anzugeben, dann kann man auch SA_Width,~0,SA_Height,~0 weglassen. Tschüß [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2007, 10:34 Uhr Holger Posts: 8116 Nutzer |
Zitat:Richtig, aber lies noch mal genauer. Es ging darum, dass die Tatsache, dass man SA_AutoAdjust,TRUE weglassen kann, dokumentiert ist, während ich für das Weglassen von SA_Width,~0,SA_Height,~0 keine passende Dokumentation gefunden habe (auch wenn es seit AOS2.0 schon immer so war). Wenn Du eine entsprechende Passage irgendwo findest, wäre ich (und offenbar auch uho, der gefragt hatte) sehr dankbar. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
10.08.2007, 15:58 Uhr geit Posts: 332 [Ex-Mitglied] |
Das mit den ~0 steht natürlich nirgendwo, da es total Banane ist. Die richtigen Werte lauten: STDSCREENWIDTH und STDSCREENHEIGHT. Das kann man in den RKRM Libraries unter "Screen Attributes" nachlesen. (Seite 48) Geit [ - Antworten - Zitieren - Direktlink - ] |
|
11.08.2007, 23:55 Uhr NoImag Posts: 1050 Nutzer |
Zitat: Die einzige Aussage, die ich gefunden habe, ist (AutDocs OpenWindowTagList): Zitat: Diese Aussage gilt natürlich auch für WA_Width und WA_Height. Eine genaue Spezifikation ist das natürlich nicht. Im Zweifel ist die Angabe der Fenstergröße daher natürlich der sicherere Weg. Da die Screengröße aber in uhos Fall bekannt ist, kann uho dann auch gleich die Screengröße statt ~0 angeben. Tschüß [ - Antworten - Zitieren - Direktlink - ] |
|
11.08.2007, 23:57 Uhr NoImag Posts: 1050 Nutzer |
@geit: Wir sprechen von den Fensterdimensionen. Das SA_ war ein Tippfehler. Tschüß [ - Antworten - Zitieren - Direktlink - ] |
| -1- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Autoscroll-Screens und mehr | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|