# Wincc Flexible 2008 SP1 - Performance Grafikanzeige



## rastus (3 Januar 2010)

Hallo!

Ich habe hier ein MP377 mit 800x600. Bei unseren Bildern setzten wir bei jedem Bild eine andere Hintergrunggrafik (BMP 256 Farben) mit 800x385 ein und platzieren auf ihr Schalter und Lampen. Wenn diese Grafik eingefügt ist, wird Winncc unglaublich langsam. Wenn ich eine Schaltfläche anklicke, dauert es mehrer Sekunden, bis sich etwas tut. Das arbeiten geht dann nicht mehr flüssig von der Hand. Entferne ich diese Grafik, geht alles wieder reibunglos. Gibt es da einen Trick? Vorlage kommt ja nicht in Frage, da es nur eine für alle Bilder gibt. Oder sehe ich das falsch. Es ist mein erstes Wincc. Sonst benutzen wir nur Sütron und Movicon.

Am Rechner liegt es nicht. Intel mit 2 Kernen a 2,6 Ghz und 2GB Ram.


----------



## marlob (3 Januar 2010)

Dauert alles langsam oder nur wenn du einen Bildwechsel durchführst?
Wie gross ist dein bmp denn? Hast du mal versucht ein gif oder ein jpg einzufügen? Die sind meist wesentlich kleiner.


----------



## rastus (3 Januar 2010)

Egal, was ich anklicke. Alles dauert lange. Muss echt an der Grafik liegen. Ich hab mal nur eine Grafikanzeige ohne Bilddatei mit 800 x 385 eingefügt. Dann bleibt es flüssig beim arbeiten. Jpg oder gif hab ich noch nicht versucht. Ich habe Angst, dass dann der Bildaufbau auf dem Terminal sich verlängert, da das Terminal die Grafik erst entpacken muss. Oder sehe ich das falsch? Bildgröße ist 308 KB


----------



## marlob (3 Januar 2010)

rastus schrieb:


> ...Ich habe Angst, dass dann der Bildaufbau auf dem Terminal sich verlängert, da das Terminal die Grafik erst entpacken muss. Oder sehe ich das falsch? Bildgröße ist 308 KB


Wie kommst du denn darauf? Da muss nichts entpackt werden. Ein jpg oder gif ist auf jeden Fall kleiner


----------



## rastus (3 Januar 2010)

Naja, bei Movicon ist das so. Der Benutzer merkt davon sicherlich nichts. Aber intern belastet das halt schon den Prozessor. Ich werd es mal versuchen.

Nachtrag: Die Performance ist bei jpg auch nicht besser.

Hier mal ein Beispielbild..


----------



## Thomas_v2.1 (3 Januar 2010)

Ich habe es letztens so gemacht, dass ich beim Projektieren das Bild erst wieder rausgelöscht habe und ganz zum Schluss erst wieder eingefügt, weil das Arbeiten damit wirklich unerträglich langsam wurde.
Ich weiß auch nicht wie Siemens das bei WinCCflex so programmiert hat, dass ein simples Bild die Software so in die Knie zwingt.

In der Runtime macht ein großes Bild den Bildwechsel oder die Bedienung jedenfalls nicht großartig langsamer. Ich hatte ein MP277.


----------



## Blockmove (4 Januar 2010)

marlob schrieb:


> Wie kommst du denn darauf? Da muss nichts entpackt werden. Ein jpg oder gif ist auf jeden Fall kleiner


 
Erst denken, dann schreiben Mario 
Warum sind gif und jpg bei gleicher Bildgröße und Farbanzahl wohl kleiner?
Es sind komprimierte (gepackte) Bildformate. Bei der Darstellung muss das Bild also sehr wohl entpackt werden.

Gruß und gutes Neues
Dieter


----------



## erzteufele (4 Januar 2010)

Blockmove schrieb:


> Erst denken, dann schreiben Mario
> Warum sind gif und jpg bei gleicher Bildgröße und Farbanzahl wohl kleiner?
> Es sind komprimierte (gepackte) Bildformate. Bei der Darstellung muss das Bild also sehr wohl entpackt werden.
> 
> ...



oh gepacktes bildformat ist aber auch falsch 

die verschiedenen typen sagen nur aus wie das Bild gespeichert wird!
ein BMP ist deshalb größer weil jeder pixel einzel beschrieben ist! (pixel1 * pixel1 = #FF0000)
bei JPG ist das Speichertverhalten nur anders! das Bild wird Codiert gespeichert und somit komprimiert (Primitives beispiel: pixel 1 - 100 * pixel 1 - 100 = #FF0000)

aber zum eigentlich problem wieviel speicher hast du der runtime zur verfügung gestellt ? in der systemsteuerung des mp377 gibt es irgendwo einen schieber wieviel speicher das programm nutzen darf

grüße


----------



## marlob (4 Januar 2010)

Blockmove schrieb:


> Erst denken, dann schreiben Mario
> Warum sind gif und jpg bei gleicher Bildgröße und Farbanzahl wohl kleiner?
> Es sind komprimierte (gepackte) Bildformate. Bei der Darstellung muss das Bild also sehr wohl entpackt werden.
> 
> ...


Erst mal auch ein frohes neues Jahr  Dann bitte nicht mit Mario verwechseln (Erst denken, dann schreiben;-))
Natürlich müssen jpg erst dekodiert werden (habe bei entpacken, an was anderes gedacht, vom Prinzip aber ähnlich/gleich). Da diese Bilder aber meist wesentlich kleiner als bmp sind (falls man richtig speichert) sollte dieser Vorgang wesentlich schneller vonstatten gehen, als ein bmp zu laden und darzustellen.


----------



## Sinix (4 Januar 2010)

Thomas_v2.1 schrieb:


> Ich habe es letztens so gemacht, dass ich beim Projektieren das Bild erst wieder rausgelöscht habe und ganz zum Schluss erst wieder eingefügt, weil das Arbeiten damit wirklich unerträglich langsam wurde.



Was passiert wenn du das Hintergrundbild statt zu löschen auf eine höhere Ebene legst und diese Ebene ausblendest?

@rastus

Dein Bild hat nur wenige Uni-Farben, vielleicht hilft eine Farbreduktion z.B. mit irfanView um die Bildgröße(Speicherbedarf) zu reduzieren.

MfG


----------



## rastus (4 Januar 2010)

erzteufele schrieb:


> ...aber zum eigentlich problem wieviel speicher hast du der runtime zur verfügung gestellt ? in der systemsteuerung des mp377 gibt es irgendwo einen schieber wieviel speicher das programm nutzen darf
> grüße



Auf dem MP377 läuft alles (bis jetzt) perfekt. Das Problem gibt es nur auf dem Projektierungsrechner. Ich behelfe mir, indem ich bei jedem Bild, welches ich bearbeite einfach die Vorlage ändere. Dann sehe ich meine "Hintergrundgrafik" und die Performance beim bearbeiten passt auch.


----------



## rastus (22 August 2010)

Nach der Installation des SP2 ist die Performance gestiegen.


----------



## Paule (27 August 2010)

rastus schrieb:


> Nach der Installation des SP2 ist die Performance gestiegen.


*ACK* Absolut, ich bin begeistert. 

Selbst bei richtig großen Grafiken war es vorher so, das bei jedem verschieben eines Objektes die Sanduhr kam.
Das Problem ist behoben, als ob keine Grafik mehr drin wäre.  

Seltsam ist allerdings folgendes:
Wenn ich ein Ein-Ausgabefeld markiere und es mit "CTRL+C" kopieren will, werden sofort alle Ein-Ausgabefelder der Seite markiert.
Genauso verhält es sich bei z.B. Textfelder, wenn ich eins markiere und mit "CTRL+C" kopieren will, werden sofort alle Textfelder markiert.
Wenn ich das entsprechende Feld mit der rechten Maustaste kopiere ist alles ganz normal.

Dieses Phänomen habe ich allerdings nur auf dem Laptop, am PC funzt es wie eh und je.


----------



## rostiger Nagel (27 August 2010)

Paule schrieb:


> *ACK* Absolut, ich bin begeistert.
> 
> Selbst bei richtig großen Grafiken war es vorher so, das bei jedem verschieben eines Objektes die Sanduhr kam.
> Das Problem ist behoben, als ob keine Grafik mehr drin wäre.
> ...


 
wie du hast den SP2 schon drauf...du bist verrückt 
das hätte ich mich nicht getraut


----------



## rastus (29 August 2010)

Paule schrieb:


> *ACK* Absolut, ich bin begeistert.
> 
> Selbst bei richtig großen Grafiken war es vorher so, das bei jedem verschieben eines Objektes die Sanduhr kam.
> Das Problem ist behoben, als ob keine Grafik mehr drin wäre.
> ...



Es gibt zum SP2 schon ein Update. Soweit ich weiss, wurde dort ein Bug mit den EA-Feldern behoben. Vielleicht hilft es dir ja.


----------



## Paule (29 August 2010)

rastus schrieb:


> Es gibt zum SP2 schon ein Update. Soweit ich weiss, wurde dort ein Bug mit den EA-Feldern behoben. Vielleicht hilft es dir ja.


Hallo rastus,
ich sehe das eigentlich nicht als Bug an, denn es kann ja auch recht nützlich sein wenn gleiche alle gleichen Felder mit einem Klick markiert werden, z.B. bei der Änderung der gleichen Eigenschaften.
Ich glaube auch eher das es an meinem Laptop liegt oder an irgend einer Einstellung von Flex.
Was mich eher stört, ist dass diese Funktion auf der Tastenkombination "CTRL+C" liegt.


----------

