JUST FOR FUN!

[Łukasz997 117]

 

Inspired by one of the forum's thread I've made a library to plot something in the QA interface. Constructor, plot, line, circle method and conversion to the PNG Base 64.

The plot method is fast, writing to an ordinary 2D table. Displaying needs the table to be converted to PNG base-64 image - and is only called "on demand". 

400x400 px image takes 19 seconds to generate - so, if someone dream about creating a dynamic hi-res game on HC3 - I'm sorry...

 

Code (without the class) and the result:

Please login or register to see this code.

 

Please login or register to see this image.

/monthly_2025_03/image.png.77907dd80c3e564453324a915979162e.png" />

Edited March 11, 2025 by Łukasz997

[Łukasz997 117]

I think that such a library can be useful and maybe it's not just for fun. 

 

Smooth graphs, plans of home, visualisation of installation etc. Here's the sin and cos example - just few lines of code (400x100 px):

Please login or register to see this image.

/monthly_2025_03/image.png.7e4ebcbff2c6e943cd59a411e63626f2.png" />

 

I did some profiling to understand what is so time consuming with rendering (not drawing, it's fast). And the results shows who is the time theft (huge 400x400 px image):

Even with the static image this is not acceptable.

I took base64 encoder from quickapp published in a forum. Never need to do this and don't want to learn.
When I did a deeper look I realise that it iterates byte by byte all the image. After modification function took 3 bytes block in one iteration and use a buffer (+few other opt).

The results after modification:

>6x faster, cool! Then I do a 12 bytes chunk at once with interesting result: in the FIBEMU time decreases to a half, but trying it on HC3 it changes only 2.38->2.20. Why - I have no idea...

This is still considerable cpu load, but maybe acceptable called not very often. For 2x smaller picture the time is >~4x shorter.

There's also some optimisation with PNG function it can be done.

 

Drawing is very fast - it can plot ~128 000 points in one second. User is drawing in a buffer, after completing picture invoke render to display image (what is so time consuming).

 

Such library can be enriched by many functions: text, dotted lines, arrows, library of schematic primitives (pump, motor, hydraulic clutch etc.), layers(!), "static" background from an image, objects.

Text, layers, background - seems to me most usable. It allows to draw static plans in a illustration software and modify only the "front layer" showing the different states of home elements.

Sounds good, much of work, but... I'm not sure if it's worth effort or not, what do you think?

 

[Sankotronic 2,370]

Hi @Łukasz997 ,

 

I see benefit of plotting charts for various measurements, even for those that can be seen in HC3 web GUI, but not on mobile app. Of course if Fibaro is not planning to remove old view that support HTML tags. Since, Fibaro never share their road map and future changes it is difficult for users to know what and how can be coded.

 

[Łukasz997 117]

14 minut temu, Sankotronic napisał:

I see benefit of plotting charts for various measurements, even for those that can be seen in HC3 web GUI, but not on mobile app.

Good morning Sankotronic,

thanks for your opinion. And I agree - about the coding.

The picture look very pretty on mobile app... I can imagine a schematic drawing on the phone, for young, sharp-eyes-owners. Regarding the support of HTML - for me it's essential to be still on. It makes a possibility to communicate with user and - by now - has no alternative.

If it will be continued... good question, but, sometimes I'm in doubt if Fibaro survives on the market at all, which is more fundamental. Maybe there's no will to grow there.

For me it's fun, brain gymnastics, a challenge and usability is not crucial (I'm not making money on it). Because of this I do not think a lot about Fibaro's future. Maybe it's a mistake🙂

Please login or register to see this attachment.

 

[Łukasz997 117]

Encouraged, I will develop this library. After some optimisations I managed to take another second away from rendering (400x400px: 4.5 s). I'm sure that more is possible, but I stop right now afraid of loosing control about all. I'm not skilled programmer when it comes to OOP. Additionally, because of large data representing image, debugging is nearly impossible for me. Now I'm thinking about adding layers and more.
I will inform, I hope, soon.

[Łukasz997 117]

Good morning,

after few days of intensive work (by a cost of sleep time...) I almost completed several ideas:

 

- added layers

- added "sprites". As layers are very memory consuming, "sprites" are objects of given size, often quite small, holding various items of drawing (o.e. valves, sensors), which can be moved on the 'canvas', rotated by any angle(!), hidden/show, colorized by one command (o.e. valve blue->red)

- added special sprite object - a text. And mosty satisfying is that text is editable (sic!). So is easy to implement o.e. changing temperature. Simple and ugly fixed size font 8x12 pixels (letters, digits, few symbols, more possible) is also implemented. As I have no tools to design and write a font it was really challenging, but I know how to do it now. Definition is quite short (encoded on bits not bytes).

- further optimisation of rendering. After adding all of these complexities 400x400 px with few layers  rendering time is about 5s (can be still faster, I hope).

- all the objects (sprites, layers, text) handles transparency!

 

What I did not add:

- loading image as a background - very powerful yet questionable idea. I'll explain it later to shorten this text

- dashed lines (only solid ones are available)

- lines with arrows

 

I have no further ideas.

 

Generally, I'm satisfied of results. Especially "sprites" and text layer with transparency I'm proud of...

The library is not very big (~900 lines), even not very complex (excluding PNG encoding). It's very memory hungry. I think, that code is not optimal. I had many troubles with OOP - scope of visibility, inheritance between classes. It's still hard to do for me. I undertake OOP approach only because of ease of use and elegant in final application.

 

Usage is very easy:

 

Please login or register to see this code.

 

And you will see:

Please login or register to see this image.

/monthly_2025_03/image.png.4e67d7b2d23c659a672d5d9ee01b9e25.png" />

 

On the phone you will see:

Please login or register to see this attachment.

 

 

There's many remarks to say when using and some changes I would like to do.

The library is not heavily tested - only basic ones.

Now,  I start tunning and tests. Share with results when ready.

Edited March 17, 2025 by Łukasz997

[Łukasz997 117]

I would write few words about background image: It will make very easy to draw in o.e. Adobe Illustrator a schema of house and then visualise only devices/sensors or whatever. 

Unfortunately, I will not do this super feature. 

Why not? LUA on HC3 is a "sandbox" with no access to file systems, so storing and processing larger amount of data will be always problematic. Only solution to store image is a variable. 360x600 px uncompressed image occupies over 650 thousands of bytes (TIFF). Encoded to base 64 we add 25% (groups of 3 bytes encoded on 4 characters). Do you imagine:

Please login or register to see this code.

After a compression schematic-type image is about 10-12 lesser. It's 67 thousand of characters.

Let's assume it's OK. However it needs to built a complete "inflate" mechanism for compressed images (o.e. Huffman algorithm). It's very complicated, cpu and memory-consuming, needs many learning of one-time-use. Ready libraries as I research is not written in pure LUA, but with C injections. I hope it's possible to create appropriate data bytes outside and sent it to HC3 (one time, just at QA start), but I can't do it.

Therefore, drawing by line, plot, circle, rectangle methods seems the only practical method. If someone has different (and simple) solution...
 

Edited March 17, 2025 by Łukasz997

[jgab 2,647]

Why not draw the background in a SVG program and paste the svg code into the app? Like 

Please login or register to see this link.

 

[Łukasz997 117]

7 godzin temu, jgab napisał:

Why not draw the background in a SVG program and paste the svg code into the app? Like 

Please login or register to see this link.

 

I think it's very good idea. Actually, it comes down to write a translator from XML "tags" to calls of methods available in my Image class, especially since they are similar (circle, line etc, others can be added). Obviously, the images will be very simple.

Edited March 18, 2025 by Łukasz997

[Łukasz997 117]

2 godziny temu, Łukasz997 napisał:

I think it's very good idea. Actually, it comes down to write a translator from XML "tags" to calls of methods available in my Image class, especially since they are similar (circle, line etc, others can be added). Obviously, the images will be very simple.

Ok, I will write the translator - shouldn't be complex.

Edited March 18, 2025 by Łukasz997

[jgab 2,647]

OK, so you are generating bitmaps/png? Why not SVG, like in

much smaller footprint, and you have all the graphics primitives, including layers, fonts and styles ?

[Łukasz997 117]

I have no time now to study deeply the thread you mention. So I ask, if I understand correctly:

- your idea is to deposit "static" home sketch in a variable as a background PNG bitmap.

- then draw and store objects (sensors etc) using SVG structure.

- finally render the SVG structure "on the top" of static PNG to display.

- HC3 has no ability to display SVG, so at the end we need to rasterise the SVG structure, encode it to base64.

Is it like that?

Edited March 18, 2025 by Łukasz997

[jgab 2,647]

No bitmap, only svg- also for the background. And yes, as the thread shows, it is possible to show svgs in the legacy view that allows for html

[Łukasz997 117]

Godzinę temu, jgab napisał:

No bitmap, only svg- also for the background. And yes, as the thread shows, it is possible to show svgs in the legacy view that allows for html

Thank you for information. So my work is worthless 😐, only value and maybe worth such effort, is upgrading skills (I bravely added dotted lines and arrows along them). I didn't know that SVG can be displayed by HC3.... However it makes things easier & faster.