VOMP: Foto fullscreen

Hi kuni,
ist ein wenig kompliziert, da es nur eine beschränkte Zahl von Skalierungsfaktoren im client gibt (2/4/8)*1,2,3,...
Dadurch wird man u.U. fullscreen insbesondere bei großen Fotos nicht immer schaffen.
Möglichkeiten:
1. in den Optionen PictureMode auf clipfactor, PictureSize z.B. auf 120 setzen (simuliert einen größerer Screen - schneidet dadurch ggf. etwas weg)
2. ggf. ScaleFactor vergrößern - gibt mehr Möglichkeiten der Skalierung(macht das Laden aber langsamer) - Bsp: Factor=7 schafft dann 2/4/8*(1...7) - 1/2 bis 1/56

Oder:
Bilder (automatisch) auf dem Server konvertieren (siehe Beispiel im script test1.sh unter xjpg) - und script als command für jpg eintragen. Damit verliert man aber im Moment die auto-Rotation und jpeg info (stört aber vielleicht nicht weiter). Bei großen Bildern könnte das Laden damit ggf. sogar schneller gehen - hängt dann vom Server ab. Dazu muß dann gm installiert sein.

Gruß Andreas

avvdr
Für mich stellt sich die Frage ob die mvp Hardware vielleicht die möglichkeit hat ein strechblt zu machen, in der vomp Basisiklasse ist das zwar nicht enthalten aber viielleicht findet man in den mvpmc sourcen etwas und kann die Basiis klasse erweitern.

Marten

marten
ich vermute strechblt würde auch nachträglich skalieren - oder? Das Problem bleibt die decode-time des Jpeg. Schon nachträglich Faktor 5 ist bei großen Jpegs ziemlich nervend. Ich vermute auch, daß man dann erst das gesamte Bild (vergrößert) im Speicher haben muß. Da wird es schnell eng (habe ich zum experimentieren noch im code drin, wenn ich mich recht erinnere ging da schon 5 nicht mehr).
Lohnenswerter wäre eine alternative jpeg lib. Ich hatte da irgendwo ein paar patches aufgetrieben, mit denen hat man beim decodieren mehr Skalierungsmöglichkeiten als 1/2/4/8 - dann wird es etwas besser:
{1,1},{7,8},{3,4},{5,8},{1,2},{3,8},{1,4},{1,8}
Falls jemand damit spielen möchte, könnte ich einen solchen Patch mal posten (heißt dann jpeg lib patchen, diese neu bauen, dann neuen vompclient bauen, Makefile sollte das erkennen).
Aber insbesondere für sehr große Jpegs wird es immer knapp - am Ende ist wahrscheinlich das prescaling auf dem Server besser. Vielleicht finden wir ja noch ein paar schlaue Einstellungen, um die exif daten mitzureichen und auch die Rotation gleich richtig zu machen - der Server hat einfach mehr power...
Ich hatte auch schon mal angedacht alternativ vom Server direkt Rohdatan ala bmp zu schicken - das wäre wahrscheinlich die schnellste Variante.

Gruß Andreas

Zitat

222 /*
223 * XXX: this has not been tested!
224 */
225 static int
226 gfx_blend(osd_surface_t *surface, int x, int y, int w, int h, 227 osd_surface_t *surface2, int x2, int y2, int w2, int h2, 228 unsigned long colour)
229 {
230 gfx_blend_t fblt;
231
232 memset(&fblt, 0, sizeof(fblt));
233
234 fblt.handle1 = surface->data.gfx.sfc.handle;
235 fblt.x = x;
236 fblt.y = y;
237 fblt.w = w;
238 fblt.h = h;
239
240 fblt.handle2 = surface2->data.gfx.sfc.handle;
241 fblt.x1 = x2; 242 fblt.y1 = y2; 243 fblt.w1 = w; 244 fblt.h1 = h; 245 246 fblt.colour1 = colour;
247
248 return ioctl(surface->fd, GFX_FB_OSD_BLEND, &fblt);
249 }

Alles anzeigen

Hier das hab ich aus mvpmc, das wäre die Funktion. Ich meine nicht das die Grafik in der vollen Auflöusng im Speicher sein müßte, das jpeglib kann sie ja vorskalieren so das es ein wenig größer als der Bildschirm ist und strechtblt macht den Rest. Da es in Hardware ist sollte es auch sehr schnell sein.
Sollte es trotzdem Probleme geben, könnte ja zuerst die obere Hälfte gezeichnet werden und dann die untere.
Ich meine das die mvp vermutlich genügend power haben sollte um das jpeg zu skalieren.

Marten