Question: Is it possible to make a responsive visualizatoin with WebHMI? 

Starting from 3.6 version and screens it is possible to make responsive visualization with WebHMI.

Please follow the screen documentaion page to make an idea of its possibiliies.

E.g. if your screen looks like this one on the desktop large monitor:

then on the mobile device it will fold in into these:

If you want your widgets with dashboard to take all available space of the widget, set his option:

Other project parts like graphs etc. will also adjust their size:

Question: In my screen widget I want the register values have custom colour. I set a color for them, but still 
they are black/white colours (depending on theme)

There are many reasons why your device may slow down, a “disable function & try” method should be applied to detect the source of this problem.

Below a summary of the possible causes is provided:

• Use screens wherever is possible for visualisation, and use dashboards as a part of screens for graphic part, which can not be done with the screens.
• Avoid using bulky DASHBOARDS (too rich in elements, having heavy-weight pictures , trends with long time window etc. ) , normal dashboard is about tens of KB, not MB!
• Set appropriate refresh time in the settings.
• Keep the number of open tabs minimal for the current sessions. If you need multiple tabs, use auto-close session checkbox to prevent unattended access.

• Avoid using many scripts (like dashboards scripts or upon change value scripts). The better way is using a few big scripts or scripts with libraries instead of a lot of small scripts (each script takes some os environment)
• Run scripts upon changing value, minimize the number of scripts, running in each scan
• Minimize “WriteReg” Lua instructions in each scan. It is better to use wrapping function UpdReg(), which writes to register only if value has changed.

• Group register to read on external device and use group reading.
• Decrease timeout and tries in external connections if it possible. Use auto-drop&try for not available connections.
• Organize and set different reading periods for variables.
• Keep the actual T1 time less than system scan set in the settings. this will give more “room” for OS' background processes.

• Minimize logging many registers to DB,
• Set appropriate log speed for the registers.check you don't have many events logged each scan.

• Keep the number of registers in the project below 2-3K
• During development, keep track of the Load Average parameter it should be below 1 (but can have short bursts above this value, which ought to fall soon)
• Avoid making simultaneous changes at once, like turning OFF-ON many regs, connection, scripts etc. Use save & apply feature of the latest fw. (apply all changes at once, instead of creating a queue for changes..)
• In the comm. log, you can set TRACE level and see what times each operation takes (each connection, script, communication with device etc.), checking timestamps