c# Screenshot auf Windows CE Gerät

[Peter (Gast)]

Hi. Ich habe hier ein Gerät, das mit Windows CE 6 läuft.
Ich möchte gerne vom Bildschirm Screenshots erstellen.
Dazu gibt es c# Codebeispiele im Internet. Das bisher einzige, was bei 
mir funktioniert, ist dieses:

using System;
using System.Collections.Generic;
using System.IO;
using System.Runtime.InteropServices;
using System.Windows.Forms;
using System.Drawing;
using System.Drawing.Imaging;

namespace ScreenShot
{
    public class Program
    {
        enum RasterOperation : uint { SRC_COPY = 0x00CC0020 }

        [DllImport("coredll.dll")]
        static extern int BitBlt(IntPtr hdcDest, int nXDest, int nYDest, int nWidth, int nHeight, IntPtr hdcSrc, int nXSrc, int nYSrc, RasterOperation rasterOperation);

        [DllImport("coredll.dll")]
        private static extern IntPtr GetDC(IntPtr hwnd);

        [DllImport("coredll.dll")]
        private static extern int ReleaseDC(IntPtr hwnd, IntPtr hdc);

        static void Main(String[] args)
        {
            Rectangle bounds = Screen.PrimaryScreen.Bounds;
            IntPtr hdc = GetDC(IntPtr.Zero);
            Bitmap bitmap = new Bitmap(bounds.Width, bounds.Height, PixelFormat.Format16bppRgb565);
            using (Graphics graphics = Graphics.FromImage(bitmap))
            {
                IntPtr dstHdc = graphics.GetHdc();
                BitBlt(dstHdc, 0, 0, bounds.Width, bounds.Height, hdc, 0, 0,
                RasterOperation.SRC_COPY);
                graphics.ReleaseHdc(dstHdc);
            }
            bitmap.Save("screenshot.jpg", ImageFormat.Jpeg);
            ReleaseDC(IntPtr.Zero, hdc);
        }
    }
}

Das Problem ist, dass der code relativ langsam ist. Wenn ich ihn z.B. 
alle 250ms aufrufe, reagiert das Gerät relativ träge. Hat jemand eine 
Idee wie man das optimieren könnte?

Gruß Peter

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Peter schrieb:
> reagiert das Gerät relativ träge.
Welche Rechenleistung hat "das Gerät"?

Gibt es für "das Gerät" einen brauchbaren Bildschirmtreiber, oder muss 
BitBlt() jedes einzelne Pixel per Handschlag hin- und herkopieren.

[Peter (Gast)]

Die Verzögerung kommt vom Speichern des Bildes. Dann hab ich nen 
Ansatzpunkt wo ich optimieren kann.

[Peter (Gast)]

Lothar M. schrieb:
> Welche Rechenleistung hat "das Gerät"?

Ca. 1Ghz.

Lothar M. schrieb:
> Gibt es für "das Gerät" einen brauchbaren Bildschirmtreiber

Weiß ich nicht. Keine Ahnung wo man das nachgucken kann.

Der Plan war eigentlich das Bild zu Diagnosezwecken zu speichern und 
dann per Ethernet weiter zu schicken, aber dann verzichte ich aufs 
Speichern und sende es direkt.

[Luther B. (luther-blissett)]

Windows CE 6? Dann könnte die verwendete Hardware sehr alt und langsam 
sein und möglicherweise gibt es auch keine Hardwareunterstützung fürs 
JPEG-komprimieren.

probiere mal, wie es sich auswirkt, wenn du diese Zeile auskommentierst:

    bitmap.Save("screenshot.jpg", ImageFormat.Jpeg);

Falls das weniger träge ist, dann probiere mal andere Bildformate:

    bitmap.Save("screenshot.bmp", ImageFormat.Bmp);

oder

    bitmap.Save("screenshot.gif", ImageFormat.Gif);

oder

    bitmap.Save("screenshot.tif", ImageFormat.Tiff);

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Peter schrieb:
> Die Verzögerung kommt vom Speichern des Bildes.
Wohin wird das Bild gespeichert?

[Schlaumaier (Gast)]

Peter schrieb:
> Hat jemand eine
> Idee wie man das optimieren könnte?

Win-CE ist eh eine tote und lahmes System.

Davon abgesehen. Wie schnell ist die SD-Karte falls es eine hat. Die 
Win-CE Teile die ich kenne haben die lahmen CF-Karten.

Davon abgesehen. Bist du sicher das das JPG-Dateien sind. ?? Bitsave 
lässt i.d.R. auf BMP Dateien schließen. Schau dir mal den Hex-Code des 
Bildes an.

Wenn es JPG ist, muss die Bitmap in ein komprimiertes JPG umgewandelt 
werden. Und da die Kisten wie gesagt nicht die schnellsten sind....

Bei BMP (was ich glaube) ist die Datenmenge relativ hoch, und das muss 
auf eine lahme Karte.


Alles in allen sind 250ms  viel zu kurz. Da hängt den Teil die Zunge aus 
den Hals.

[Peter (Gast)]

Luther B. schrieb:
> Falls das weniger träge ist, dann probiere mal andere Bildformate:

Als bmp ist es auch träge, und das Bild kann nicht betrachtet werden.

Als Gif ist es erträglich, jedoch sind unten leichte 
Bildfehler/Artefakte am Rand.

Tiff lässt sich nicht kompilieren.
"System.Drawing.Imaging.ImageFormat" enthält keine Definition für 
"Tiff". (CS0117)

[Peter (Gast)]

Schlaumaier schrieb:
> Alles in allen sind 250ms  viel zu kurz. Da hängt den Teil die Zunge aus
> den Hals.

Ja, ich schätze auch ich muss mir was anderes überlegen.
Aber per Screenshot wäre es am wenigsten Arbeit gewesen.

[J. S. (jojos)]

vielleicht findet man einen VNC Server für WinCE?
Ist das Pixelformat RGB565 auch das was nativ auf dem Gerät läuft? Nicht 
das da noch eine langsame Konvertierung stattfindet.

[Peter (Gast)]

J. S. schrieb:
> vielleicht findet man einen VNC Server für WinCE?

Was ich kenne ist ein Programm namens CERDISP. Das ist jedoch nur für 
Verbindungen zwischen Windows CE und Windows XP/7 ausgelegt. Das fällt 
bei mir flach.

J. S. schrieb:
> Ist das Pixelformat RGB565 auch das was nativ auf dem Gerät läuft?

Gute Frage, keine Ahnung.

[Stefan F. (Gast)]

4 Screenshots pro Sekunde machen und per Netzwerk zu übertragen klingt 
für mich nach einem Fall für RDP oder VNC.

[c-hater (Gast)]

Stefan ⛄ F. schrieb:
> 4 Screenshots pro Sekunde machen und per Netzwerk zu übertragen klingt
> für mich nach einem Fall für RDP oder VNC.

Tja, das Problem ist halt bloß, dass CE keinen RDP-Server eingebaut hat 
und VNC letztlich dasselbe machen muss, was er da tut (bzw. der von ihm 
zusammengeklaute Code).

Das eigentliche Problem ist aber, das CE uralt ist und auf alten Geräten 
mit geringen Reserven bei Rechenleistung und insbesondere Busbandbreite 
läuft. Das sind einfach keine guten Voraussetzungen für Screen-Kopien.

Peter schrieb:

> J. S. schrieb:
>> Ist das Pixelformat RGB565 auch das was nativ auf dem Gerät läuft?

> Gute Frage, keine Ahnung.

Das wäre aber wichtig, denn das ist so ziemlich das einzige, wo 
eventuell noch etwas herauszuholen wäre. Allerdings ist RGB565 
tatsächlich ein sehr verbreitetes Pixelformat bei WindowsCE-Geräten, es 
ist also recht wahrscheinlich, dass das schon so passt, also auch hier 
nix mehr zu verbessern geht.

[Keks F. (keksliebhaber)]

Verstehe die Raterei nicht.
Laufzeiten lassen sich extern oder im Code messen und entsprechend 
auswerten.
Führe Messungen durch und teile die Werte. Dann kann man zielgerichtet 
optimieren.

Pauschal kann man nur sagen, wenn die Gesamtheit des Codes langsam ist, 
den weniger häufig auszuführen, oder schnellere Hardware zu benutzen.
Dazu sagst du auch noch, "das Gerät reagiert relativ träge". Das ist 
auch ein komplett anderes Problem.
Ich denke hier wird nur ein Bruchteil des Codes gezeigt.

[db8fs (Gast)]

Was du machen kannst, falls das nicht schon der Fall ist: die Screenshot 
versuchen ins Ram-Filesystem zu legen und nicht auf den Flash, das 
könnte vielleicht was bringen.

Den Tipp mit dem Pixelformat-Konvertierung finde ich auch sehr wichtig, 
manchmal haben die CE-Teile auch 5551 oder solche exotischen Sachen 
verbaut.

Ansonsten kommt's wahrscheinlich auch drauf an, wie schnell solche 
Speicheroperationen an sich sind, denn wenn der RAM nicht viel 
Geschwindigkeit hergibt, musst du eben dann damit leben.

[db8fs (Gast)]

Schlaumaier schrieb:
> Win-CE ist eh eine tote und lahmes System.

Das System selber ist schnell, denk ich. Gebootet haben die Dinger 
meistens schneller als ein relativ moderner Raspberry mit Raspbian 
drauf.

Das übel lahme sind meistens die Flash-Speicher, die auch dazumal 
ziemlich fix durchgeschrieben worden sind, das mit dem Flash-Schonen ist 
später erst Mode geworden glaube ich.

> Davon abgesehen. Wie schnell ist die SD-Karte falls es eine hat. Die
> Win-CE Teile die ich kenne haben die lahmen CF-Karten.

Das stimmt, SD kann noch schlimmer als der Flash sein, aber selbst der 
ist lichtjahre-weit von den SSDs heute entfernt...

> Davon abgesehen. Bist du sicher das das JPG-Dateien sind. ?? Bitsave
> lässt i.d.R. auf BMP Dateien schließen. Schau dir mal den Hex-Code des
> Bildes an.

Wenns BMP wäre, würde das sogar noch schneller gehen vermutlich. Einfach 
weil nix mehr komprimiert werden muss. Bei 16bit und 640x480 biste bei 
~0.5MB pro Bild, das könnte helfen. Wenns nicht gerade ein 
FullHD-Display ist ^^

> Alles in allen sind 250ms  viel zu kurz. Da hängt den Teil die Zunge aus
> den Hals.

Zeichnen in 3Hz bei 640x480 sollte auf den Dingern locker möglich sein 
mit Double-Buffering, selbst bei nem steinalten 200Mhz ARM ohne FPU und 
alles geht das. Ob das Grabben aus dem Videomemory viel langsamer ist, 
glaub ich nicht, oft ist bei den CE-Dingern ein gemeinsamer Speicher, wo 
8MB für Grafik abgezwackt werden.

[Achim M. (minifloat)]

Was hat DerGerät denn für einen Ausgang für seinen Bildschirm? Eventuell 
kann man das abgreifen und mit einem modernen Einplatinenrechner "auf 
RJ45 konvertieren"?

mfg mf

[Peter (Gast)]

Danke für die hilfreichen Antworten!
Ich werde mal was einbauen um die Zeiten zu messen.
Und ich werde versuchen das Bild direkt aus dem RAM per Ethernet 
weiterzusenden.

[Schlaumaier (Gast)]

Naja. Das einzige Gerät mit Win-CE 6.0 was ich je hatte, war ein 
HP-5450.

Und das war /ist ein Pocket-PC. Der Vorgänger eines Smartphone. Falls es 
Leute gibt die die Teile nicht kennen.

Und der war damals schon nicht der schnellste. Trotz 1 GB CF-Karte.