Crash mit librsvg2-2 Version größer als 2.40.8

Moin,

Zitat von louis

wie es ausschaut ist der Fehler mit der 2.40.9 reingekommen.

Laut Datei- und Zeilenangabe im Backtrace müsste es um den commit bgo#605875 - Gaussian blurred objects are sometimes missing gehen. Die betreffende Zeile lässt sich leider nicht verlinken.

Zitat von louis

Mittelfristig sollte sich jemand mit dem Problem die Mühe machen, den Bug an die Developer zu melden, damit der gefixt wird

Grundsätzlich hätte ich kein Problem damit, das zu tun, allerdings bezweifle ich, ein kompetenter Ansprechpartner für die Entwickler der librsvg zu sein, wenn Rückfragen kommen. Es ist ja nicht davon auszugehen, dass einer von ihnen zufällig einen VDR mit skindesigner rumstehen hat.

Rückfragen werden sicher kommen, weil es mit der 2.40.9 kein grundsätzliches Problem mit der Darstellung der header.svg gibt: rsvg oder inkscape zeigen die header.svg korrekt an. Auch im Skin kann die header.svg angezeigt werden, wenn sie nicht extremst gestaucht wird.

header.svg hat eine Größe von 1920x34 und wird im stillClassic an verschiedensten Stellen verwendet:

- als Hintergund für Header und Menübalken, hier kommt es zu keinem Crash, läuft einwandfrei!(kein übermäßiges Stauchen)

- Hintergrund für die Startzeiten in der Kanalinfo, Crash (stauchen des Seitenverhältnisses von 960/17 auf 115/165)

- Scrollbalken, Crash (stauchen des Seitenverhältnisses von 960/17 auf bis zu 29/702 - je nach Höhe des Balkens)

Wenn ich das richtig sehe, wurde mit dem o.g. commit der Weichnzeicher 'verfeinert', das ist sicher ein sehr rechenintensiver Prozess... Ob die Entwickler der librsvg einsehen, dass er dabei auch solchen extremen Anforderungen gerecht werden soll....

Gruß,
Tomas

Zitat von tomas

Rückfragen werden sicher kommen, weil es mit der 2.40.9 kein grundsätzliches Problem mit der Darstellung der header.svg gibt: rsvg oder inkscape zeigen die header.svg korrekt an. Auch im Skin kann die header.svg angezeigt werden, wenn sie nicht extremst gestaucht wird.

Inkscape ist ein schlechtes Beispiel. Soweit ich weiß parsen die SVG mit eigenem Code.

Aber "rsvg" ist ein guter Ansatz. Du schreibst, dass es etwas mit Stauchen zu tun hat. Auch rsvg kann stauchen (man rsvg). Ist es möglich einen Aufruf zu basteln der mit rsvg alleine den Crash auslöst?

Nett, dass du dich hier einklinkst

Dass es mit oder nur mit dem Stauchen zusämmenhängt, ist bisher nur eine Vermutung. Ich schau mir heute Abend mal rsvg etwas genauer an. Auf jeden Fall wäre es sicher gut, damit einen Crash provozieren zu können. Das ist dann auch allgemein nachvollziehbar. Danke für den Tipp.

Gruß,
Tomas

Moin,

jo das wäre das beste wenn man den Crash unabhängig vom Skindesigner reproduzieren könnte. Dann könnte man einen vernünftigen Bugreport aufmachen.

Ciao Louis

Cool das ihr euch so reinhängt...

Zitat

- als Hintergund für Header und Menübalken, hier kommt es zu keinem Crash, läuft einwandfrei!(kein übermäßiges Stauchen)
- Hintergrund für die Startzeiten in der Kanalinfo, Crash (stauchen des Seitenverhältnisses von 960/17 auf 115/165)
- Scrollbalken, Crash (stauchen des Seitenverhältnisses von 960/17 auf bis zu 29/702 - je nach Höhe des Balkens)

Na.. also sollte tatsächlich das das Problem sein, könnte ich das ja leicht ändern, wobei ich immer dachte svg-Dateien lassen sich skalieren wie man will
Außerdem finde ich eigentlich die Idee ganz gut so wenig svg-Dateien wie möglich einzusetzten, das macht das themen deutlich einfacher

Moin,

aus meiner Sicht darf es keinen Crash in der librsvg2 geben, egal welches SVG man der vorsetzt.

tomas: könntest du bitte auch mal testen, ob der Crash weg ist, wenn der blur Effekt ein bisschen "stärker" oder "schwächer" ist? Das hat man in Inkscape ja schnell gemacht...das wäre dann zumindest mal ein temp. Workaround, bis der Bug in der lib beseitigt ist.

Ciao Louis

BooStar: ich denke, wir haben ja alle etwas davon, wenn das auch mit 2.40.9 und höher sauber läuft. Außerdem sollte die librsvg zumindest nicht 'sang und klanglos' aussteigen, wenn sie sich 'verhaspelt'.

louis: klar, kann ich gerne machen. Teilweise hatte ich das sogar schon getestet. Ohne Weichzeichnung bzw mit einem Wert von 0,1 keine Crashes, ab 0,2 bis 1,0 jeweils Crash. Höher werde ich noch testen.

Ich hatte die header.svg auch schon mit inkscape auf die 'richtigen' Maße für die Kanalinfo und Scrollbars skaliert. Das klappt dann auch.

Gruß,
Tomas

Zitat von M-Reimer

"rsvg" ist ein guter Ansatz. Du schreibst, dass es etwas mit Stauchen zu tun hat. Auch rsvg kann stauchen (man rsvg). Ist es möglich einen Aufruf zu basteln der mit rsvg alleine den Crash auslöst?

Ich meinte eigentlich den Viewer rsvg-view-3.
rsvg ist ja der Konverter, der natürlich auch skalieren kann, aber nach dem Skalieren hat man keine 'echte' svg mehr, sondern das skalierte Original ist als 'image/png' eingebettet. Das meinte ich oben mit 'is not anymore a 'real' svg', was ich aber auch erst bemerkt hatte, als ich mir das Ergebnis im Editor anschaute.

rsvg-view-3 kann man zur Anzeige entweder die Größe oder den Skalierungsfaktor mitgeben.

Ergebnis: Skalierung auf die Größe, die in der Kanalinfo gebraucht wird, ist kein Problem. Das deckt sich auch mit jinx' Beobachtung

Zitat

VDR crashes as soon as try to open any osd except the one that opens with the OK button

Warum es bei mir bei der Kanalinfo kracht, habe ich noch nicht herausgefunden....

Die Skalierung auf die Größe, die für die max Höhe für die Scrollbars gebraucht wird, habe ich mit folgendem Aufruf (x und y sind die jeweiligen Zoomfaktoren) nachgestellt:

rsvg-view-3 -x 0.015 -y 22 header.svg
Gleitkomma-Ausnahme (Speicherabzug geschrieben)

Aha, also hier steigt auch rsvg-view-3 aus....

Der Backtrace zeigt dann im Prinzip das gleiche Ergebnis (rsvg-filter.c:1420) wie der vom skindesigner erzeugte:

#0  0xb767d29b in box_blur_line (box_width=<optimized out>, even_offset=<optimized out>, 
    src=0x92dc958 "\241\241\241\241\237\237\237\237\235\235\235\235\233\233\233\233\231\231\231\231\227\227\227\227\225\225\225\225\223\223\223\223\221\221\221\221\217\217\217\217\215\215\215\215\212\212\212\212\210\210\210\210\206\206\206\206\204\204\204\204\202\202\202\202\200\200\200\200~~~~||||zzzzxxxxvvvvttttqqqqoooommmmkkkkiiiiRRRR\241\241\241\241\237\237\237\237\235\235\235\235\233\233\233\233\231\231\231\231\227\227\227\227\225\225\225\225\223\223\223\223\221\221\221\221\217\217\217\217\215\215\215\215\212\212\212\212\210\210\210\210\206\206\206\206\204\204\204\204\202\202\202\202\200\200\200\200~~~~||||zzzzxxxx"..., dest=0x92bda70 "P\364\213\266", <incomplete sequence \364\213\266>, len=29, bpp=<optimized out>) at rsvg-filter.c:1420
        coverage = 0
        i = 0
        lead = 0
        output = 0
        trail = 0
        ac = 0xbfe95070
        __FUNCTION__ = "box_blur_line"

Zitat von louis

könntest du bitte auch mal testen, ob der Crash weg ist, wenn der blur Effekt ein bisschen "stärker" oder "schwächer" ist? Das hat man in Inkscape ja schnell gemacht...das wäre dann zumindest mal ein temp. Workaround, bis der Bug in der lib beseitigt ist.

Ich habe jetzt noch in Zehntelschritten mit Unschärfe von 1,1% bis 2,0% getestet. 'Bestes' Ergebis hatte ich mit 1,5% Unschärfe. Damit gingen dann zumindest die Menüs (schedules, channels), bei denen die header.svg neben der Stauchung auf 1,5% der Originalbreite nicht wie im Haupt und Setupmenü gleichzeitig auf ca 2200% der ursprünglichen Höhe (ja zweitausend) gestreckt werden müsste. Als sicherer Workaraound taugt IMHO wohl nur eine gesonderte svg für die Scrollbars.

Gruß,
Tomas

Zitat von tomas

Ich meinte eigentlich den Viewer rsvg-view-3.
rsvg ist ja der Konverter, der natürlich auch skalieren kann, aber nach dem Skalieren hat man keine 'echte' svg mehr, sondern das skalierte Original ist als 'image/png' eingebettet. Das meinte ich oben mit 'is not anymore a 'real' svg', was ich aber auch erst bemerkt hatte, als ich mir das Ergebnis im Editor anschaute.

Eigentlich kann man ein SVG auch garnicht skalieren. Also zumindest nicht in dem Sinne wie man das bei Rastergrafik macht. Das ist eine Frage des Maßstabs. Bei Cairo ist es sogar so, dass man erst den Faktor festlegt und dann in 1:1-Skalierung die Zeichenbefehle absetzt. Cairo skaliert dann jeden Zeichenbefehl um den festgelegten Faktor.

Wenn ich alle Werte im SVG z.B. halbiere, dann aber mit Faktor 2 rendere, dann sollte das Endergebnis mehr oder weniger exakt genau so aussehen wie die Ursprungs-SVG, gerendert mit Faktor 1.

Zitat

Die Skalierung auf die Größe, die für die max Höhe für die Scrollbars gebraucht wird, habe ich mit folgendem Aufruf (x und y sind die jeweiligen Zoomfaktoren) nachgestellt:

Code

rsvg-view-3 -x 0.015 -y 22 header.svg
Gleitkomma-Ausnahme (Speicherabzug geschrieben)

Aha, also hier steigt auch rsvg-view-3 aus....

Damit könnte man doch einen Bug-Report machen... Kannst du mal die header.svg, mit der das reproduziert werden kann, hier verlinken? Ggf. erst irgendwo die einzelne SVG hochladen. Da der Thread auseinandergetrennt wurde bin ich ehrlich gesagt nichtmal mehr im Bilde um welchen Skin es hier geht...

Moin,

na da kommen wir der Sache doch langsam näher...vielen Dank für deine Mühen Tomas!

Zumindest kann Boostar jetzt einen Workaround einbauen, und wenn ihr noch einen Bugreport für die librsvg Developer einstellt ist der Bug sicherlich in der nächsten Verison gefixt...

Ciao Louis

Es geht um BooStars stillClassic. Die header.svg findest du hier: header.svg

Zitat von tomas

Die header.svg findest du hier: header.svg

Ok, auf die Idee, diese Graphik als Grundlage für eine vertikale Scrollbar zu benutzen, wäre ich jetzt nicht gekommen

Ciao Louis

Hi...
vielen Dank für deine Mühe tomas, ich werde mir das mal ansehen und die scrollbars als extra svg anbieten

Zitat

Ok, auf die Idee, diese Graphik als Grundlage für eine vertikale Scrollbar zu benutzen, wäre ich jetzt nicht gekommen

Na... ein weiser Mann sagte mal: "Es ist alles erlaubt was geht" Außerdem... dachte ich wie gesagt, das svg-Dateien skaliert werden können wie man will..also warum nicht?

SVGs sollten so skaliert werden können, wie man will. Dafür sind vektorisierte Grafiken ja da.
Wenn der Fehler reproduzierbar ist, muss man das ja nur einmal im Debugger durchspielen, dann bekommen die Entwickler sicherlich eine Idee, was da schief geht.

Lars.

Which Skin did you use?

jinx: the important facts are posted in English:

Zitat von tomas

The problem seems to be caused by the blur-effect in header.svg.

Zitat von louis

seems to be a regression in version 2.40.9. In the according change log different changes regarding blurred images are mentioned...

Meanwhile Boostar provided a workaround for the scrollbar. Newest stillClassic should not crash any more.

BooStar: die neueste scrollbar.svg wird zumindest mal ohne Crash angezeigt, allerdings ohne Weichzeichnung/Unschärfe:

[Blockierte Grafik: http://anthra.de/vdr/blur.png]

links inkscape, rechts rsvg-view-3 (im OSD des VDR sieht es genauso aus). Wenn ich das richtig sehe, hast du für die scrollbar.svg die header.svg um 90° gedreht und vertikal gespiegelt?

Die scrollbar.svg des vorherigen commits crashte übrigens (auch ohne jegliche Skalierung für die Anzeige in rsvg-view-3).

Gruß,
Tomas

Hi tomas,
danke fürs testen,

Zitat

links inkscape, rechts rsvg-view-3 (im OSD des VDR sieht es genauso aus). Wenn ich das richtig sehe, hast du für die scrollbar.svg die header.svg um 90° gedreht und vertikal gespiegelt?

Ja und wenn ich mich recht erinnere habe ich den BlurEffekt entfernt....