[ANNOUNCE] vdr-SOFTOSD-Patch (nicht NUR für Softies)

Zitat

Original von UFO

Hast Du eine Karte ohne 4MB-Mod? Dann gibt es jedenfalls mehrere OSD-Fenster.

Imho muß man den Code noch einmal überdenken: Flush() ruft sich selbst mitten aus der Bitmap-Schleife noch einmal auf. Habe so meine Zweifel, das so etwas bei mehreren OSD-Fenstern gut geht...

CU
Oliver

Alles anzeigen

Das geht Gut. Die Fade-Schleife wird nur aufgerufen wenn fade=0 ist. In der Schleife wird fade sofort auf !=0 gesetzt.

ardi

Zitat

Original von UFO

Und was ist mit Seiteneffekten infolge der Treiberaufrufe über Cmd()?

CU
Oliver

Was meinst Du?
Das einzige was bis zur Fade-Schleife aufgerufen wird ist "Cmd(OSD_SetWindow, 0, i + 1);" und zwar mit i=0.
"Cmd(OSD_SetWindow, 0, i + 1);" wählt nur das Window auf welches sich die folgenden Cmd's beziehen. Das kann ich so oft aufrufen wie ich will. Ohne nebeneffekt.

ardi

So ich habe jetzt den Patch erweitert (siehe ersten Post)

Es sind ein paar #defines dazugekommen.

Interessant ist vielleicht wenn man SOFTOSD_PALETTE_ONLY auf 2 setzt

#define SOFTOSD_PALETTE_ONLY 2

Dann wird beim Faden nur die Palette aktualisiert
ABER: beim letzten Step werden auch Pixel refresht. Dadurch sollten die Farbfehler weg sein.
Ich habe keine Ahnung ob es hilft und was wichtiger ist ob es "aussieht".

Achja FADEIN und FADEOUT lassen sich getrennt de/aktivieren

ardi

Zitat

Original von UFO

Was ist mit OSD_Open?

Oliver

In der Tat. Ich bin bisher davon ausgegangen, dass ein Osd angelegt wird, das auch angezeigt werden kann (also das kleinste Level hat).
Dann wird es schon einmal vom OsdProvider geflusht. Da aber zu dieser Zeit die Palette leer ist (if (Colors)) in diesem Fall Colors=0 es nicht zur Fade-Schleife kommt.
Du hast aber recht. Denn wenn ein Osd durch ein anderes mit höherem Level in den Hintergrund gedrückt wird und anschließend wieder vor kommt, dann wird OSD_Open 2 mal aufgerufen.

Allerdings sollte man annehmen das die Treiber sauber genug geschrieben sind, dass sie ein doppeltes OSD_Open ablehnen oder ein ReOpen veranlassen. Hier also effektlos bleiben.

Im ersten Patch hatte ich die Fade-Schleife in einen Thread ausgelagert. Vieleicht sollte ich das wieder einbauen.

ardi

Zitat

Original von HolgerR
Nope... sorry. Da ist noch irgendwas gewaltig krumm. Der VDR startet mit eingeblendeter Kanalinfo. Die bleibt die ganze Zeit stehen, bis sich der VDR von alleine neu startet. Eine Bedienung (Menüaufruf, Umschalten, etc.) ist zu keiner Zeit möglich.

Gruß
Holger

EDIT: Siehe Post über mir

Sorry, das der Patch nicht läuft. Kann wie ihr wisst nicht testen.

Ich werds mir morgen noch mal ansehen. Heute wird das nichts mehr.

Zitat

Original von HolgerR

Kein Problem! Mach dir keinen Stress...

So. Hab mir den Patch nochmal angesehen und habe den Fehler auch schon gefunden. Heute abend kommt dann der neue Patch.

Für eilige:

cCondWait::SleepMs(wait_time-flush_time);
    }
    fading = false;
    return;
 }
- fade = SOFTOSD_STEPS;
#endif

So. Jetzt der korrigierte Patch 0.0.3. Wie immer im ersten Post zu finden.

Neu:

• die Fade-Schleife ist jetzt am Anfang von Flush() (verhindert dadurch mögliche Seiteneffekte)
• Steps und Rate für FadeIn und FadeOut separat einstellbar bzw. komplett Abschaltbar.
• Syslog-Ausgabe hinzugefügt
• MAX_OSD_SIZE hiermit kann das Fading für OSDs ab einer bestimmten Größe abgeschaltet werden

Ich hoffe das der Patch nicht wieder einen Fehler enthält

Zitat

Original von HolgerR
Danke! Das ist auf jeden Fall schon mal der richtige Weg. Die Anzeige funktioniert jetzt verläßlich; während des Einblendens sieht man natürlich die Falschfarben, aber das wird sich wohl kaum verhindern lassen. Die "stehende" Anzeige am Ende ist jedenfalls korrekt und die Performance ist wesentlich besser.

Richtig. Wird sich leider nicht verhindern lassen. Aber sieh dir mal den neuen Patch an. Mit MAX_OSD_SIZE kannst du OSDs ab einer bestimmten Größe "aussperren". Der Effekt kommt meiner Meinung nach bei den "großen" Menüs eh nicht so zur Geltung. Wenn die "kleinen" (z.B. Kanalinfo, Lautstärke und Sprachwahl) mit SOFTOSD_PALETTE_ONLY 0 ausreichend schnell gefadet werden, könnte das für dich eine akzeptable Alternative sein.

ardi

Zitat

Original von UFO

Ja, liegt an einem kleinen Bug in dem Block, der die Palette berechnet. Damit geht's:

Code

#ifdef SOFTOSD
                int steps = fading < 0 ? SOFTOSD_FADEOUT_STEPS : SOFTOSD_FADEIN_STEPS;
                if (SOFTOSD_ON && 0 < fade && fade < steps)
                    colors[i] = (((((Colors[i] >> 24) & 0x000000FF) * fade) / steps) << 24) |
                                ((Colors[i] & 0x0000FF) << 16) | (Colors[i] & 0x00FF00) | ((Colors[i] & 0xFF0000) >> 16);
                else
#endif

Sorry für's Umformatieren, aber meine Augen brauchen Leerzeichen...

CU
Oliver

Alles anzeigen

Danke für die schnelle Diagnose. Habe einen korrigierten Patch hochgeladen.

ardi