[rpihddevice] OSD mit GPU-Unterstützung und Pixmap-Support

  • Hallo zusammen


    Ich habe die OSD-Implementation des rpihddevice-Plugins überarbeitet und Unterstützung für Pixmaps eingebaut. Die Änderungen sind in git eingecheckt und bereit zum testen. Ich selber habe bisher, abgesehen von den Default-Skins, mit skinenigmang, skinnopacity (nativ) und skindesigner mit den drei Standard-Skins getestet. Auch das osddemo-Plugin funktioniert nun.


    Mit dem Support von beschleunigten Pixmaps ist nun aber der Speicherverbrauch der GPU etwas dynamischer geworden. Folgendes trägt zum Verbrauch bei:
    - die eigentliche Drawing-Surface in der Grösse der eingestellten Auflösung, mit jeweils 4Byte/Pixel, doppelt gebuffert
    - jedes OSD mit gesetzten Areas, wobei eine default-Pixmap alle Areas umschliesst, 4Byte/Pixel
    - jede zusätzliche Pixmap, 4Byte/Pixel, maximal 2048x2048px
    - jeder Font, abhängig von der Anzahl der Zeichen
    - jedes gecachte cImage


    Mit 256MB funktionieren aber die mitgelieferten Skins von skindesigner zuverlässig und dank GPU-Beschleunigung selbst auf dem alten Raspberry Pi recht flott. Weiter optimieren liesse sich die Performance nur noch, wenn skindesigner das im VDR vorgesehene, und nun auch im rpihddevice implementierte, Cachen von Bildern nutzen würde. Gerade bei häufig genutzten Bildern wie Icons oder andern grafischen Elementen brächte dies noch ein wenig mehr "Schub".


    Bitte beachtet, dass in skindesigner noch ein kleiner Fehler steckt. Der angehängte Patch behebt diesen, womit auch das Ausblenden sauber funktioniert. (louis will diesen bei der nächsten Bugfixing-Runde einbauen)


    Viel Spass beim Testen!


    Gruss
    Thomas

  • Ja coole Sache.
    Werds gleich direkt mal testen :)


    Freu mich drauf!!!!!


    Danke Dir
    Gruß Patrick

    Gruß Patrick


    [size=8]* Meine NeverEndingProjects ;-)*


     vectra --- glasslike ---

  • Super, vielen Dank Thomas. :thumbup: 
    Werde ich gleich installieren und testen.


    Viele Grüße, Uwe

  • Super! :tup:tup:tup 
    Ich habe bisher die Original-Skins genommen, weil der Speed da einfach deutlich besser war, aber von der Optik und Usability war das schon ein harter Einschnitt zu meinem Haupt-VDR.


    Um so besser, dass du jetzt auch die skindesigner-skins mit GPU-Beschleunigung unterstützt.


    Vielen Dank, Peter

    VDR1: vdr-latest, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S
    VDR2: RasPI 2, MLD
    VDR-User #81

    Linux is the best OS I have ever seen -- Albert Einstein

  • Super, vielen Dank. Das ist noch das Sahnehäubchen.

    SAT Hardware: Gibertini SE75 | DuraSat Dur-Line UK-24 | DD OctopusNET V2 Rack (Firmware 1.0.80 Beta) mit MaxS8
    Server: Asus M5A78L-M/USB3 | Sempron 145@2Cores | 8GB ECC RAM | PicoPSU | Debian Jessie 64Bit | Linux Kernel 4.4 | VDR 2.2.0 mit SAT>IP, epgsearch, streamdev, epg2vdr, vdr-epg-daemon
    Clients: RaspberryPI 2/3 | Yocto Poky Linux (Openembedded) 2.2+git | Linux Kernel 4.9+git | VDR 2.2.0 mit SAT>IP, RpiHDDevice, SkinDesigner, Remote, Graphlcd-ax206dpf, RemoteTimer, Extrecmenu, NeutrinoEPG, Femon, Mlist


    R.I.P: Gigaset M740 mit VDR von open7x0.org

  • Super, vielen Dank. Das ist noch das Sahnehäubchen.


    ... mit Kirsche :D

    Gruß Patrick


    [size=8]* Meine NeverEndingProjects ;-)*


     vectra --- glasslike ---

  • Deutlich schneller :]

    Gruß
    Frodo

  • Hall Thomas,
    bisher ist mir folgendes aufgefallen:
    Ich nutze den Skin nopacity (nativ). Mit dem epgsearch Plugin öffne ich die EPG Übersicht von allen Sendern. Nun kann ich mit einen "Scrollbalken" von Sender zu Sender wechseln. Wenn ich nun bei einen Sender mit sehr viel EPG Text bin und dieser von rechts nach links scrollt, dauert es ein relativ langen Moment, bis ich mit den Scrollbalken zum nächsten Sender wechseln kann (nach oben oder unten). Kann das jemand nachvollziehen? Ist das ein Bug?


    Ansonsten macht die GPU Beschleunigung nun sehr viel Spass mit dem Skin nopacity(nativ). :D


    Viele Grüße, Uwe

  • Bombe!!!!
    Läuft ja richtig flott. Hätte nie gedacht das ich mal Skindesigner auf der Himbeere nutzen könnte :)


    Gruß Patrick

    Gruß Patrick


    [size=8]* Meine NeverEndingProjects ;-)*


     vectra --- glasslike ---

  • wow, das ist hart, die Einblendeffekte in nopacity laufen wesentlich flüssiger als auf meinem Nvidia Client...Danke!

    1. Server Zotac D2700-ITS Cine-S2 Dual yaVDR 0.5
    2. Client Zotac D2550-ITS yaVDR 0.5
    Sonstige VDRs
    2. Zotac-HD-ID11 TT-S2-3600 yaVDR 0.5
    3. Zotac D2700-ITS TT-S2-3600 yaVDR 0.5
    4. Zotac ITX-F-E TT-S2-3600 yaVDR 0.5

  • Mein RPI 2 macht richtig was her mit nopacity! :)


    Beim Mailbox-Plugin bekomme ich bei großen Emails folgende Meldung:


    rpihddevice: [OpenVG] cannot allocate pixmap of 2804px x 781px, clipped to 2048px x 781px!


    Ich weiß, jede zusätzliche Pixmap, 4Byte/Pixel, maximal 2048x2048px. Mails werden dann unvollständig angezeigt, kann man da was machen?


    Dann hab ich noch den Patch von kanadakruemel für das osdteletxt-plugin probiert. Da kommt leider nur die Meldung "vdr: [3819] OSD-Teletext: 32BPP" im syslog und dann geht das OSD nicht mehr.


    Echt super wie die Entwicklung des rpihddevice fortschreitet!


    Danke :tup

    FSC Esprimo P5625 AMD Athlon X2 4400 | VDR-SERVER | Centos 7 Kernel-4.4.19 | DVBSky S952 v2 & DVBSKy S950 v3 | VDR-2.2.0 | dummydevice, streamdev-server, etc.
    Raspbery Pi 1 Model B + | Debian wheezy Kernel-3.18.8-v7+ | VDR-2.2.0 | epgsearch, remotetimers, skinsoppalusikka, svdrpservice, mailbox, rpihddevice, sleeptimer, undelete, osdteletext, streamdev-client
    Raspbery Pi 2 - Model B | Debian jessie Kernel-4.1.15-v7+ | VDR-2.2.0 | epgsearch, remotetimers, skinsoppalusikka, svdrpservice, mailbox, rpihddevice, sleeptimer, undelete, osdteletext, streamdev-client

  • Moin,

    - jede zusätzliche Pixmap, 4Byte/Pixel, maximal 2048x2048px


    bezieht sich diese Angabe auf den Viewport oder den Drawport der Pixmap? Viewport wäre ok, der Drawport kann schon mal größer werden...z.B. in der EPG Detailansicht, wenn viel Text zum Scrollen da ist.


    Ciao Louis

  • Hab's gerade mal getestet. Super Arbeit!


    Eine Frage habe ich aber trotzdem. Die Skins werden bei mir nicht Vollbild dargestellt sonder fangen weiter links erst an. Gibt es da eine Einstellung die ich nicht gesehen habe?

  • MajestyIV Schau mal unter Setup --> OSD: Höhe, Breite, links und rechts....


  • bezieht sich diese Angabe auf den Viewport oder den Drawport der Pixmap?


    Das bezieht sich auf die Gesamtgröße der Pixmap, also auf den Drawport.
    Es wird in der nächsten VDR-Version eine Funktion cOsd::MaxPixmapSize() geben, über die man abfragen kann, wie groß eine Pixmap maximal sein kann.


    Klaus

  • Hi Klaus,

    Das bezieht sich auf die Gesamtgröße der Pixmap, also auf den Drawport.
    Es wird in der nächsten VDR-Version eine Funktion cOsd::MaxPixmapSize() geben, über die man abfragen kann, wie groß eine Pixmap maximal sein kann.


    Ok, das heisst wenn man z.B. eine vertikal scrollbare Pixmap anzeigen will, kann man die nicht mehr größer als ca. zwei Bildschirmseiten machen? Fände ich jetzt irgendwie nicht so cool...oder verstehe ich da was falsch? Falls nicht, ist diese allgemeine Beschränkung dann nur wegen dem Raspberry oder gibt es da noch andere Gründe?


    Ciao Louis

  • Das Problem ist im Zusammenhang mit dem rpihddevice zu Tage getreten. Der Raspberry Pi kann wohl nur Pixmaps bis maximal 2048x2048 Pixel. Streng genommen hätte er wegen dem letzten Satz in

    Code
    1. virtual cPixmap *CreatePixmap(int Layer, const cRect &ViewPort, const cRect &DrawPort = cRect::Null);
    2. ///< Creates a new true color pixmap on this OSD (see cPixmap for details).
    3. ///< The caller must not delete the returned object, it will be deleted when
    4. ///< the OSD is deleted. DestroyPixmap() can be called if a pixmap shall be
    5. ///< destroyed before the OSD is deleted.
    6. ///< If this is not a true color OSD, or if the pixmap could not be created
    7. ///< due to limited resources, this function returns NULL.


    bereits NULL zurückliefern müssen, wenn eine zu große Pixmap angefordert wurde.
    Ich hatte damals, als ich das cPixmap-API entworfen habe, leider nicht bedacht, daß es OSDs geben könnte, die hier Beschränkungen haben. Aber letztlich ist es auch verständlich, denn der Speicher ist endlich ;-).


    Ein möglicher Workaround wäre, einfach mehrere Pixmaps anzulegen, die zu scrollende Fläche darauf zu verteilen und die Pixmaps entsprechend zu platzieren.


    Klaus

  • Hi Klaus,

    Ich hatte damals, als ich das cPixmap-API entworfen habe, leider nicht bedacht, daß es OSDs geben könnte, die hier Beschränkungen haben. Aber letztlich ist es auch verständlich, denn der Speicher ist endlich ;-).


    ok, aber muss das dann allgemeingültig sein? Könnte man das nicht im speziellen Fall des Raspis abfangen, wie es jetzt anscheinend auch passiert? Dann fehlt eben beim Raspi ein Teil der Ausgabe, dafür hat man auf Maschinen mit mehr GPU Speicher keine Beschränkungen. Nix gegen den Raspi, aber ich fände es irgendwie seltsam, wenn die kleinste Kiste die anderen ausbremst ;)


    Ein möglicher Workaround wäre, einfach mehrere Pixmaps anzulegen, die zu scrollende Fläche darauf zu verteilen und die Pixmaps entsprechend zu platzieren.


    Das wäre aber ein ziemlicher Hack...


    Ciao Louis

  • rpihddevice: [OpenVG] cannot allocate pixmap of 2804px x 781px, clipped to 2048px x 781px!


    Ich weiß, jede zusätzliche Pixmap, 4Byte/Pixel, maximal 2048x2048px. Mails werden dann unvollständig angezeigt, kann man da was machen?

    Nein. Die OpenVG-Implementation des Raspberry Pi unterstützt Surfaces nur mit einer maximalen Grösse von 2048x2048 Pixeln.


    Dann hab ich noch den Patch von kanadakruemel für das osdteletxt-plugin probiert. Da kommt leider nur die Meldung "vdr: [3819] OSD-Teletext: 32BPP" im syslog und dann geht das OSD nicht mehr.

    Ich habe mir den Patch mal angesehen: Scheinbar wird das Bild Pixel für Pixel direkt auf das OSD gezeichnet. Die Beschleunigung beim rpihddevice funktioniert aber so, dass das OSD pro API-Aufruf einen Befehl in eine Queue schreibt, die wiederum ein separater Thread ausliest und in entsprechende OpenVG-Calls umsetzt. Das funktioniert im Normalfall sehr effizient, wenn aber nun ein ganzer Bildschirm pixelweise geschrieben wird, dann endet das mit einer überfüllten Queue, bzw. einem out-of-memory, weil der Thread mit dem Abarbeiten der Befehle nicht nachkommt.


    Wenn nun das osdteletext-Plugin schon nicht mit einem entsprechenden Font arbeitet, dann wäre es doch angebracht, die Pixel stattdessen in ein Bitmap zu schreiben und dieses dann auf das OSD zu zeichnen. So wie das jetzt gelöst ist, kommt das in meinen Augen einer Vergewaltigung des APIs gleich…


    Gruss
    Thomas

  • ok, aber muss das dann allgemeingültig sein? Könnte man das nicht im speziellen Fall des Raspis abfangen, wie es jetzt anscheinend auch passiert? Dann fehlt eben beim Raspi ein Teil der Ausgabe, dafür hat man auf Maschinen mit mehr GPU Speicher keine Beschränkungen. Nix gegen den Raspi, aber ich fände es irgendwie seltsam, wenn die kleinste Kiste die anderen ausbremst

    Das hat ja nichts mit dem Raspberry Pi zu tun. Kann ja sein, dass bei einer andern Hardware bei 4096x4096 Schluss ist… Jedenfalls muss ein Skin schon davon ausgehen, dass Pixmaps eine endliche Grösse haben.


    Streng genommen hätte er wegen dem letzten Satz in

    Code
    1. virtual cPixmap *CreatePixmap(int Layer, const cRect &ViewPort, const cRect &DrawPort = cRect::Null);
    2. ///< Creates a new true color pixmap on this OSD (see cPixmap for details).
    3. ///< The caller must not delete the returned object, it will be deleted when
    4. ///< the OSD is deleted. DestroyPixmap() can be called if a pixmap shall be
    5. ///< destroyed before the OSD is deleted.
    6. ///< If this is not a true color OSD, or if the pixmap could not be created
    7. ///< due to limited resources, this function returns NULL.


    bereits NULL zurückliefern müssen, wenn eine zu große Pixmap angefordert wurde.

    Ich sollte mir angewöhnen, die Header-Files komplett zu lesen… Wäre es also besser, statt zu beschneiden Null zurückzugeben?


    Gruss
    Thomas