ac'tivAid

Leider muss an dieser Stelle mitgeteilt werden, dass Wolfgang Reszel seine Arbeit an ac'tivAid beendet hat. Eine Entwicklerversion von ac'tivAid gibt es auf meiner Webseite. Gruß, Michael

Der Bugtracker wurde aus Sicherheitsgründen abgeschaltet, diese Website dient nur noch als statisches Archiv.

Willkommen beim Bugtracker zu ac'tivAid. Ac'tivAid ist ein AutoHotkey-Skript, welches zuletzt in c't 12/08 ausführlich vorgestellt wurde.
Die letzte stabile Version finden Sie unter www.heise.de/ct/activaid.

Wenn Sie in der stabilen Version einen Fehler finden, testen Sie bitte erst die aktuelle Beta-Version, bevor Sie den Fehler melden!

Um evtl. schon hier behandelte und geschlossenen Themen mit der Suche zu finden, muss in der erweiterten Suche bei Status "Alle offenen Aufgaben" auf "Alle Status" umgestellt werden.

Letzte stabile Version bei Heise.de: 1.3.1

Letzte beta Version 1.3.2 beta1 : activaid_beta.exe | portable_activaid_beta.exe

Entwicklerversion von Michael

Änderungen, Liesmich/Hilfe, FAQ und Themen-Special (bei www.heise.de)

Digital Upgrade haben ein Video zu ac'tivAid 1.1.8.1 gedreht, wo ein paar Funktionen kurz angesprochen werden.

| Aufgabenliste |

FS#1143 - Bereichsauswahl sehr träge

Gehört zu Projekt: ac'tivAid
Angelegt Mark Gerber (Gerby) - Donnerstag, 15. November 2007 - 15:55
Aufgabentyp Hilfe / Support
Kategorie Erweiterungen → ScreenShots
Status Zugeteilt
Zuständig Wolfgang Reszel (Tekl)
Betriebssystem Windows XP SP2
Schweregrad Niedrig
Priorität Normal
Betrifft Version 1.1.8.8 beta73
Fällig in Version Unbestimmt
Fällig am Unbestimmt
Prozent erledigt 0%
Stimmen 1
Versteckt Nein

Beschreibung

Ich habe Screenshots angetestet. Leider ist die Auswahl eines Bereiches bzw. das Verschieben des Auswahlrahmens auf meinem System sehr träge. Der Rahmen zuckt im 2- bis 3-Sekunden-Takt hinter dem Mauscursor hinterher.

Eckdaten:

  • Athlon XP 2500 @ 2100 MHz
  • Matrox Millennium G550
  • 2 Bildschirme

Ich befürchte, dass es an der schlechten 3D-Implementierung der Matrox-Karte liegt. Trotzdem die Frage: Gibt es eine Möglichkeit die Reaktion des Auswahlrahmens zu beschleunigen (z. B. durch Ein-/Ausschalten irgendwelcher Features)?

Schöne

Diese Aufgabe ist abhängig von

Kommentar von Mark Gerber (Gerby) - Freitag, 16. November 2007 - 15:16

Eine kleine Entschuldigung: Ich habe die Aufgabe  FS#1129  erst jetzt entdeckt, in der das Problem der Trägheit auch angesprochen worden ist. Irgendwie waren wohl meine Filtereinstellungen bei der ersten Suche daneben.

Leider wird die Problematik dort nicht weiter verfolgt. Ich habe nun auch schon die neueren Entwicklerversionen der Erweiterung ausprobiert: keine Besserung.

Kommentar von Michael (Michael) - Samstag, 17. November 2007 - 08:06

Anscheinend scheint es tatsächlich mit der Grafikkarte zusammenzuhängen, denn auch in  FS#1129  wird ein Problem mit dem selben Modell
gibt im Moment leider noch keine Optionen die Reaktion des Auswahlrahmens zu beschleunigen.

Kommentar von Wolfgang Reszel (Tekl) - Montag, 19. November 2007 - 09:14

Man könnte die Transparenz der Abdunklung in der INI-Datei unter [ScreenShots] mit DimTransparency=OFF abschalten, womit es dann aber deckend Schwarz ist, was weniger hilfreich ist. Funktionieren denn andere Tools wie z. B. Jing (http://www.jingproject.com/) vernünftig? Eigentlich hat die Matrox doch gute 2D-Performance.

Kommentar von Mark Gerber (Gerby) - Montag, 19. November 2007 - 15:37

Der Schalter DimTransparency hat bei mir überhaupt keine Wirkung. Sowohl bei der Einstellung OFF als auch bei irgendeiner Zahl wird immer die gleiche Abdunklungsfarbe angezeigt. Somit kann ich in diesem Zusammenhang leider keine Tests durchführen.

Bezüglich Jing: Es ist auch träge, jedoch nicht ganz so wie die ScreenShots-Erweiterung.

Kommentar von Wolfgang Reszel (Tekl) - Montag, 19. November 2007 - 15:48

DimTransparency setzt v1.2.2 Beta1 oder höher vorraus und muss in der ac'tivAid.ini unterhalb von [ScreenShots] eingetragen werden. Achte auch darauf, dass es da nicht zweimal auftaucht. Die Änderung wird erst mit neu Laden von ac'tivAid wirksam.

ScreenShots verwendet zwei transparente Fenster, um Mausklicks abzufangen. Unter dem dunklen Bereich gibt es noch ein quasi unsichtbaren transparenten Bereich, welcher sich aber nicht verändert. Auf diesen kann ich leider nicht verzichten, ohne ScreenShots deutlich komplexer zu machen. Ich denke deswegen ist ScreenShots noch träger als Jing, welches scheinbar nur einen transparenten Bereich verwendet. Zudem zeigt Jing bei Aktivierung einen eingefrorenen Bildschirm an, bei ScreenShots sieht man immer den aktuellen Bildschirm, eben nur abgedunkelt.

Ich fürchte du wirst mit der Trägheit leben müssen. Evtl. gibt es ja auch eine neueren Treiber oder es hilft gar der Wechsel auf den bei XP mitgelieferten Treiber.

Kommentar von Mark Gerber (Gerby) - Montag, 19. November 2007 - 16:30

Die Sache mit der Trägheit ist kein Drama. Es ist mir halt nur aufgefallen.

Ich habe tatsächlich zwischendurch noch einen anderen Matrox-Treiber ausprobiert. Leider gab es da keine Verbesserung. Windows XP selber hat keinen Treiber für die Matrox G550. Oder meinst Du den VESA-Treiber? Aber das lasse ich mal sein.

Bezüglich DimTransparency: Es war tatsächlich so, dass der Eintrag zwei mal vorhanden war. Jetzt funktioniert es. Wie Du bereits vermutetest macht das jedoch bzgl. der Trägheit auch keinen Unterschied.

So gut die Darstellungsqualität der Matroxkarte auf meinen Bildschirmen mit Analogeingang auch ist, so miserabel ist alles, was über die flache 2D-Darstellung hinausgeht, in der Performance. :-(

Kommentar von Wolfgang Reszel (Tekl) - Montag, 19. November 2007 - 16:42

In der Datei ac'tivAid_ScreenShots.ahk gibt's ziemlich am Anfang eine Zeile scr_WinDelay = 0. Setze da mal den Wert auf 20 oder was anderes. Bringt das was? Ansonsten bin ich gerade dabei ReadingRuler mit ScreenShots zusammenarbeiten zu lassen, so dass man eine Alternative komplett ohne Transparenzen hat.

Kommentar von Wolfgang Reszel (Tekl) - Montag, 19. November 2007 - 16:54

Wegen eines Tippfehlers klappt mein Vorschlag mit scr_WinDelay erst mit v1.2.2 Beta3.

Kommentar von Michael (Michael) - Donnerstag, 22. November 2007 - 18:02

Existiert die Trägheit eigentlich noch? Was ist mit dem Setzen von scr_WinDelay, ändert sich dadurch irgendetwas?

Kommentar von Mark Gerber (Gerby) - Freitag, 23. November 2007 - 19:00

Ups, ganz vergessen das mal auszuprobieren. Leider komme ich bis morgen (Samstag) nicht mehr dazu. Am Sonntag oder Montag gibt's dann ein Feedback meinerseits.

Kommentar von Mark Gerber (Gerby) - Sonntag, 25. November 2007 - 13:32

Das Testen verschiedener Werte für scr_WinDelay (20, 50, 10) brachte leider keine Besserung.

Kommentar von Wolfgang Reszel (Tekl) - Montag, 26. November 2007 - 06:20

Ist denn ReadingRuler auch langsam? Ggf. könntest du nämlich auch auf den zurückgreifen, um einen Ausschnitt zu wählen. Dazu musst du ihn so konfigurieren, dass er die Start- und Endposition anzeigt (siehe auch Liesmich)

Kommentar von Mark Gerber (Gerby) - Montag, 26. November 2007 - 07:58

Danke für den Tipp. Die Verwendung von ReadingRuler ist tatsächlich eine brauchbarer Workaround.

Kommentar von Mark Gerber (Gerby) - Dienstag, 27. November 2007 - 08:34

Es hat sich ergeben, dass ich eine neue Grafikkarte in das Bürosystem einbauen konnte (nun mit Chipsatz GeForce 7600 GS). Und nun die Überraschung: Das Positionieren und Verändern des Screenshotbereichs ist beinahe noch träger als zuvor! Es liegt also an anderen Systemkomponenten oder -einstellungen. Aber wo ist der Flaschenhals?

Auf Verdacht habe ich zunächst mal in den Anzeigeeigenschaften von Windows XP (Einstellungen | Erweitert | Problembehandlung) nachgesehen, jedoch steht die Einstellung für die Hardwarebeschleunigung für beide Bildschirme auf "Maximal" und das Write Combining ist auch aktiviert.

Liegt's eventuell am Athlon-System? Auf einem Pentium-4-System mit GeForce-2-Karte, das ich auch noch zur Verfügung habe, läuft ScreenShots übrigens relativ flüssig.

Kommentar von Wolfgang Reszel (Tekl) - Dienstag, 27. November 2007 - 15:20

Das ist wirklich seltsam. Mir gelingt es partout nicht dein Verhalten zu rekonstruieren. Ich habe mal alle Beschleunigungen abgeschaltet und auch mal den abgesicherten Modus getestet. Überall habe ich ähnliche (für XP übliche) Performance. Allerdings konnte ich das bis jetzt nur in VMWare testen. Ist denn das Verschieben von Fenstern samt Inhalt bei dir auch so lahm? Wie sieht es mit einem anderen Benutzer-Account aus? Die gleichen Probleme?

Kommentar von Mark Gerber (Gerby) - Mittwoch, 28. November 2007 - 08:08

Kleine Testreihe: Unter einer XP-Parallelinstallation auf dem selben Rechner sind die gleichen Symptome vorhanden. Mit Vista auf dem selben Rechner funktioniert die Ausschnittspositionierung flüssig. Unter Vista werden wohl andere Routinen verwendet, oder?

Mal sehen ob mir noch was einfällt, was ich am System ändern kann um eine Verbesserung unter XP zu erzielen. Tipps sind willkommen.

Kommentar von Wolfgang Reszel (Tekl) - Mittwoch, 28. November 2007 - 11:09

Vista delegiert viele Aufgaben direkt an die Grafikkarte, was man besonders bei TransparentWindow im automatischen Modus sieht. Aus irgend einem Grund scheint bei dir XP die Fenster komplett über die CPU zu zeichnen. Wie sieht das bei dir aus mit den Fenstern samt Inhalt verschieben? Ist das überhaupt möglich bzw. akzeptabel flüssig?

Kommentar von Mark Gerber (Gerby) - Mittwoch, 28. November 2007 - 17:04

Sorry, das vergaß ich bereits früher zu erwähnen: Das Verschieben von Fenstern (mit Inhalt) funktioniert wunderbar und flüssig. Sonst wäre ich schon vorher stutzig geworden.

Du hast mich übrigens darauf gebracht ebenfalls mal in VMware zu testen. Siehe da: In der virtuellen Maschine ist die Aktualisierung des Auswahlrahmens spürbar schneller als auf meinem Host-Desktop (wenn auch immer noch ruckelnd). Es muss also irgendwas mit einer Systemeinstellung oder -datei zu tun haben. Mal sehen ob ich das noch rauskriege. Eine Windows-Neuinstallation kommt jedenfalls nicht in Frage.

Kommentar von Mark Gerber (Gerby) - Mittwoch, 28. November 2007 - 17:24

Noch eine Frage: In  FS#1129  wurde die GdiPlus.dll erwähnt. Kann die was damit zu tun haben, oder ist sie nur für das Erstellen der Grafikdatei zuständig?

Kommentar von Michael (Michael) - Mittwoch, 28. November 2007 - 17:31

Die Systembibliothek GdiPlus.dll wird nur zum Konvertieren von Bilddaten benötigt, also nur zum Speichern des Bildes in den verschiedenen Formaten. Ohne GdiPlus.dll arbeitet die Anzeige identisch, nur die Funktionalität den Screenshot zu speichern ist dann nicht verfügbar.

Kommentar von Mark Gerber (Gerby) - Freitag, 30. November 2007 - 08:10

Ein Schmankerl zu meiner Recherche: Bei Google "2d-performance transparenz windows xp" angegeben. Als erstes Ergebnis erscheint genau diese Seite - Mist! ;-)

Kommentar von Mark Gerber (Gerby) - Freitag, 30. November 2007 - 12:54

Folgendes hat sich herausgestellt: Die Aktualisierungsrate des Auswahlrahmens ist stark abhängig von der verwendeten Bildschirmauflösung und Farbtiefe. Insbesondere bei der Verwendung zweier Bildschirme (wie hier die Regel) folgt der Auswahlrahmen nur noch sprungweise.

Es scheint tatsächlich so, dass AutoHotkey über die CPU die gesamte Last der Aktualisierung übernimmt und nicht irgendeine Systemfunktion. Dies zeigt auch der Screenshot erstellt mit ScreenShots kurz nach dem Aufziehen des Auswahlrahmens (Prozessorlast 83 %, stieg zuvor auf über 90 %).

Kommentar von Wolfgang Reszel (Tekl) - Montag, 10. Dezember 2007 - 16:11

Sind eigentlich auch Spiele im Zweischirmbetrieb langsamer?

Kommentar von Mark Gerber (Gerby) - Dienstag, 11. Dezember 2007 - 08:57

Leider spiele ich nicht mit dem System. Ich habe aber mal 3DMark05 drüberlaufen lassen, bei aktiviertem und bei deaktiviertem zweiten Bildschirm. Es ergaben sich jedoch keine signifikanten Unterschiede. Das Programm läuft natürlich immer nur auf dem Hauptschirm, insofern kann ich nicht beurteilen, ob dieser Test überhaupt sinnvoll gewesen ist.

Kommentar von Hermann Ruckerbauer (ruckb) - Mittwoch, 09. Januar 2008 - 15:23

Hallo,

ich hab das gleiche Problem mit folgender
Dell latitude C640 P4 1.8GHz mit ATI M7 Radeon Graphic,
Normalerweise fahre ich auch eine Dual Screen Auflösung, das problem tritt aber auch dann auf, wenn ich die Auflösung auf single screen 1024x768
macht bei mir Alt-Druck nur ein schwarzes Fenster.Über die Bereichsauswahl kriege ich einen Screenshot hin (wenn ich denn geduldig genug bin). Kann das damit was zu tun haben
Themes (rückmeldung von Wolfgang Reszel) nutze ich nicht.

WEnn ich was machen kann oder genauere infos notwendig sind kann ich sicher etwas aufwand spendieren.

Hermann

Kommentar von Wolfgang Reszel (Tekl) - Mittwoch, 09. Januar 2008 - 15:39

Das mit den schwarzen Bildern lässt sich unter weitere Optionen beheben.

Wegen der langsamen Bereichsauswahl bin ich nicht schlauer, da ich keinen Zugriff auf Systemen mit diesem Verhalten habe.

Kommentar von Hermann Ruckerbauer (ruckb) - Donnerstag, 10. Januar 2008 - 09:07


deinen Kommentar bez. der schwarzen Bildern habe ich die aktuelle Beta installiert. in der 1.2.1 hat es die Option noch nicht gegeben. Mit der 1.2.2 beta49 hat sich das verhalten bei der Bereichsauswahl auch verbessert. Das System reagiert zwar noch träge, aber mit etwas Gedult ist das Feature fast Nutzbar.

Die Schwarzen Bildern sind weg. Allerding ist mir nicht klar welches Feature ich damit aufgegeben habe ...

Was bei mir nicht geklappt hat ist das automatische öffenen der Datei wenn ich z. B. AltDruck verwende. Wenn ich die Bereichsauswahl verwende dann geht mein Bildbearbeitungsprogramm auf (leider jedes mal ne neue instanz...), aber wenn ich den Screenshot mit Alt-Druck mache passiert nichts.

Da fällt mir aber gleich noch eine Verbesserungsoption
wird nicht das MuliClipBoard verwendet zum einfügen des Screenshots verwendet. Da könnte man auf eine Position den Dateinamen legen, und auf eine Andere den Screenshot ...

Und noch was, weil ich grad die Kombination ReadingRuler mit Screenshots probiert habe. Ist tatsächlich ein brauchbarer Workaround. Allerdings würde ich mir da noch eine optimierung wüchen. ich hab mir dazu den ReadingRuler auf Win-Druck gelegt. Damit ziehe ich das Fenster auf. wenn ich dann auf Druck gehe geht mein Screenshot mit der Auswahl auf. Aber dann sollte der Screenshot gleich gemacht werden, und nicht noch mal eine Bestätigung erfordern.

und bei meinen Systemangaben hab ich noch das OS vergessen: Win2k ...

Gruss

Hermann

Kommentar von Mathias Kalb (Mathias) - Donnerstag, 10. Januar 2008 - 09:56
Und noch was, weil ich grad die Kombination ReadingRuler mit Screenshots probiert habe.
Ist tatsächlich ein brauchbarer Workaround. Allerdings würde ich mir da noch eine optimierung wüchen.
ich hab mir dazu den ReadingRuler auf Win-Druck gelegt. Damit ziehe ich das Fenster auf.
wenn ich dann auf Druck gehe geht mein Screenshot mit der Auswahl auf.
Aber dann sollte der Screenshot gleich gemacht werden, und nicht noch mal eine Bestätigung erfordern.

Funktioniert schon mit "Sofort letzte interaktive Auswahl". Einfach das Tastenkürzel ändern oder das entsprechende verwenden.

Mathias

Kommentar von Wolfgang Reszel (Tekl) - Donnerstag, 10. Januar 2008 - 17:08

In Beta 50 gibt's nun entsprechende Änderungen, so dass auch der Tipp von Mathias nicht mehr nötig ist.

Kommentar von Mathias Kalb (Mathias) - Donnerstag, 10. Januar 2008 - 17:28

War das denn
konnte man zwischen zwei Möglichkeiten wählen (Interaktiv und Sofort letzte interaktive Auswahl), jetzt verhalten sich beide gleich, d.h. die Funktionalität wurde eingeschränkt.

Mich stört es nicht so sehr, aber vielleicht diejenigen, bei denen die Screenshot-Auswahl sehr träge ist und die stattdessen ReadingRuler verwenden.

Kommentar von Wolfgang Reszel (Tekl) - Donnerstag, 10. Januar 2008 - 21:30

Ich dachte die Auswahl stört generell, da sie auch nach ReadingRuler das System mit den drei transparenten überlagernden Fenstern belastet.

Kommentar von Mathias Kalb (Mathias) - Freitag, 11. Januar 2008 - 09:15

Das weiß ich nicht. Bei mir läuft es ja
war nur erstaunt, dass du Funktionalität
verwende immer den ReadingRuler um einen Screenshotbereich auszuwählen, da die Fadenkreuze sehr hilfreich sind. Vorher konnte man entscheiden, ob man mit "Sofort letzte interaktive Auswahl" den Bereich sofort als Screenshot haben will oder ob man mit "Interaktiv" noch Größenänderungen vornehmen will. Das war flexibler.

Kommentar von Wolfgang Reszel (Tekl) - Freitag, 11. Januar 2008 - 09:33

Flexibler klar, aber braucht man wirklich zwei Bereichsauswahlen hintereinander? Langfristig werde ich sowieso eine Alternative Auswahlmöglichkeit in Screenshots einbauen.

Kommentar von Mathias Kalb (Mathias) - Freitag, 11. Januar 2008 - 09:40

Mit Größenänderungen meinte ich die Skalierung des Bereichs, z.b. auf
Bereich wähle ich immer nur mit ReadingRuler aus (zwei Fadenkreuze).

Kommentar von Hermann Ruckerbauer (ruckb) - Montag, 14. Januar 2008 - 12:31

Hi,

ich hab die Beta50 noch nicht probiert, aber über den Tipp von Mathias geht die auswahl über Reading Ruler recht gut. Was mich etas stoert (vielleicht mache ich da auch noch was
Fadenkreuze wären schon ganz hilfreich für die Auswahl des Bereichs. Allerdings kriegt man das erste Fadenkreuz erst nachdem man die maus plaziert hat und dann Reading ruler aufruft. Das hilft also bei der Plazierung der ersten Ecke noch nicht. Das geht zwar am eigentlichen Sinn von Reading ruler vorbei, aber für den Zweck der Bereichsauswahl für den Screenshot wäre gut, wenn man auch die Startposition erst festlegenkönnte, wenn man das Fadenkreuz schon hat. Aber fragt mich mal nicht wie das am besten implementiert werden könnte ...

gruss

Hermann

Kommentar von Mathias Kalb (Mathias) - Montag, 14. Januar 2008 - 12:36

Das Problem kommt mir bekannt vor. Ging mir schon häufiger so.

Kommentar von Wolfgang Reszel (Tekl) - Montag, 14. Januar 2008 - 13:13

Ich habe in Beta 53 ReadingRuler um eine Funktion ergänzt, so dass man nun mit einem Doppelklick auf Strg die Startposition neu setzen kann.

Kommentar von Mathias Kalb (Mathias) - Montag, 14. Januar 2008 - 13:22

Funktioniert gut. Danke für die schnelle und praktische Lösung.

Die ist übrigens auch für den ReadingRuler hilfreich und nicht nur in der Kombination mit ScreenShots.

Kommentar von Hermann Ruckerbauer (ruckb) - Montag, 14. Januar 2008 - 14:47

Das ging schnell, und geht gut .. Danke!

Einmal hatte ich den Effekt, dass ich 3x Strg drücken musste um die startposition neu zu
beim nächsten mal wieder weg.

Hermann

Kommentar von Wolfgang Reszel (Tekl) - Montag, 14. Januar 2008 - 14:49

Man darf dazwischen nichts anderes drücken und auch nicht zu lange warten, sonst zählt es nicht als Doppelklick

Kommentar von Michael (Michael) - Montag, 14. Januar 2008 - 14:52

Funktioniert auch bei mir prima, nur dass ich erst nicht wusste, was mit Doppelklick gemeint war. Für mich ist ein Klick immer mit einer Maustaste. Vielleicht sollte man es lieber "zweimaliges Drücken der Strg-Taste" nennen?

Kommentar von Hermann Ruckerbauer (ruckb) - Freitag, 04. April 2008 - 14:37

Hi,

ich hab grad ne erinnerungsmail bekommen, das Wolfgang Reszel jetzt Eigentümer der aufgabe ist ... d. h. da passiert noch was
Orignial auswahl macht bei mir immer noch probleme .. Übrigens habe ich vor kurzem ein Ähnliches problem festgestellt, als ich per MS Livemeeting eine Anwendung freigegeben habe. Da wird der rest des Desktops auch so abgedunkelt ... und dann ging nicht mehr viel ..

Die nutzen vielleicht die gleiche Funktion dazu ?

gruss

hermann

Kommentar von Michael (Michael) - Dienstag, 06. Mai 2008 - 16:51

Unter "Weitere Optionen" gibt es in den aktuellen betas die zwei Einstellungen zum beschleunigen der interaktiven Auswahl. (Der Tippfehler ist schon für die nächste beta korrigiert siehe  FS#1429 )

Helfen diese Einstellungen gegen die Probleme?

Kommentar von Hermann Ruckerbauer (ruckb) - Mittwoch, 07. Mai 2008 - 10:29

Hi,

ich habe in der zwischenzeit den Rechner gewechselt, immer noch ein notebook in dual screen mode. Bei dem Gerät ging es von Haus aus besser, aber es war immer noch etwas träge/unhandlich. Alelrdings hatte ich da auch schon unterschiedliche Beobachtungen gemacht. Zur Zeit ist es im normal und halbtransparent modus noch ruckelt. d. h. ich würd mal sagen ich krieg so 5 aktualisierungen pro sekunde. Nicht perfekt, aber damit könnte man leben. Ich sehe aber keinen unterschied zw. halbtransparent und normal ... Worauf muss ich denn achten, dass ich hier einen unterschied sehe ?

Im Modus ohne Trasparenz folgt das Rechteck ohne delay dem Mauszeiger, wenn ich es verschiebe. Was man in dem Modus verbessern könnte: Ändern der Farbe des Auswahlrahmens. Ich hab grad den screenshot von einem Fenster gemacht, und den Rahmen ziemlich genau an das Fenster angepasst. Dann hätt ich beim nächsten screenshot mit der gleichen Auswahl den Rahmen fast nicht mehr gefunden.

gruss

Hermann

Kommentar von Mark Gerber (Gerby) - Donnerstag, 08. Mai 2008 - 06:48

Die Performance-Optionen bewirken bei mir, dass der Desktop vollständig in beige bzw. grau erscheint und nur noch das Kontrollfenster und der Auswahlramen sichtbar sind. Abgesehen davon scheint sich der Auswahlrahmen tatsächlich etwas flüssiger zu bewegen, aber nicht deutlich.

Nochmal zur
XP @ 2100 MHz, VIA-Chipsatz KT880, GeForce
XP Pro

P.S.: Der Screenshotvorgang des Auswahlrahmens lässt sich (allgemein) nicht per Doppelklick auslösen (Hinweiston erklingt), per Eingabetaste jedoch schon.

Kommentar von Mathias Kalb (Mathias) - Freitag, 09. Mai 2008 - 09:52

Bei mir bringt der Wechsel von normal zu halbtransparent eine deutliche Beschleunigung, wenn ich versuche das Fenster (nicht die Auswahl) zu verschieben.

Ich sehe aber keinen unterschied zw. halbtransparent und normal ... Worauf muss ich denn achten, dass ich hier einen unterschied sehe ?

Versuche mal die Auswahl teilweise über das Fenster zu schieben, dann solltest du einen Unterschied zwischen den beiden Modi feststellen können.

Kommentar von Hermann Ruckerbauer (ruckb) - Freitag, 09. Mai 2008 - 13:48

Hallo,

Danke für den Hinweis
ich sehe immer noch keinen unterschied. Allerdings ist mir jetzt auch nicht klar was du "das Fenster" meinst. Ich arbeite zur zeit nur mit dem Auwahlrahmen, mit dem ich irgenwelche Bereiche auf dem Desktop capture. Und da liegen viele Fenster rum ;-)

Ich hab grad noch ein anderes interesanntes Problem festgestellt. Ich habe eine applikation die per GNU plot ein Fenster aufmacht. Das gibt auch noch ein kleines OK window, mit dem ich das echte Fenster wieder schliessen kann. Dieses OK Window muss ich zuerste verschieben. Wenn ich dann mein GNUplot window Capture kriege ich eine ganze weisse Fläche, oder zum Teil irgendwelche Linien (zum Beispiel hab ich schon mal das halbe grid von einem Graphen im screenshot gesehen). Aber das problem ist so abgefahren ... da muss ich noch ein wenig rumprobieren...

Gruss

hermann

Kommentar von Mathias Kalb (Mathias) - Freitag, 09. Mai 2008 - 13:58

Mit dem Fenster meinte ich die "ScreenShots Werkzeug Palette". Es gibt eine Option, die dieses Fenster einblendet.

Im normalen Modus lässt sich bei mir dieses Fenster nur sehr langsam verschieben, daher verwende ich den halbtransparenten Modus.

Kommentar von Hermann Ruckerbauer (ruckb) - Freitag, 09. Mai 2008 - 17:19

Hi,

ja, jetzt weiss ich was für ein Fenster du meinst ... das war die erste Funktion die ich abgeschaltet hab, nachdem ich die neue Beta probiert habe.. ist zwar nett die Auswahl zu haben, aber ich hab immer den gleichen Ausschnitt mit gleichen Bedingungen gebraucht...

Und ich kann auch bestätigen, dass sich dieses Fenster Flüssiger verschieben lässt, wenn die Transparenz nur halb aktiv ist.

Aber ich seh den Unterschied immer noch nicht ;-( ... Aber das ist bei mir ganz normal ... in den Spielezeitschriften sind auch immer Bilder von den Spielen in hoher und niedriger Auflösung, und entweder sehe ich den Unterschied nicht, oder ich stelle im nachhinein fest, daß mir das bild mit der niedrigen Auflösung besser gefällt ...

ich denke ich kann mit der jetzigen Performance und den Einstellungsmöglichkeiten durchaus leben ...

Gruss

Hermann

Kommentar von Mark Gerber (Gerby) - Donnerstag, 05. März 2009 - 10:30

Im Laufe der Zeit hat sich herauskristallisiert, dass die Problematik in der schlechten 2D-Leistung meines Systems liegt. Woran es liegt, ist nicht klärbar. In meinem Fall jedoch nicht an den eingesetzten AGP-Grafikkarten (Matrox G550, GeForce 7600 GS), sondern wohl eher am Chipsatz (VIA KT880) im Zusammenhang mit Windows XP.

Unter Windows Vista existiert das Problem nicht, da hier die 2D-Darstellung intern anders gehandhabt wird.

Das kleine, uralte Testprogramm BltTest kann Aufschluss über die 2D-Leistung geben (Webseite). Werte unter 100 MB/s sind eher schlecht. Es sollten schon mehrere hundert MB/s sein.


Lade...