Re: Proposed widget type: image

Hallo!

Am 21.02.2014 07:07, Markus Dolze wrote:
>
> Hi,
>
> there are two things to keep in mind:
>
> 1. The original patch was for the glcd driver. For those graphical
> driver you can use any size of an image and are not restricted to 8
> characters.
It was just an estimation of amount of data i expect in a typical 
combined text/ image usage.

In the worst case 320 x 240 pixels (that was the size of the largest 
display with bus interface I've seen so far) would be 9600 byte, if one 
uses the hole display for the image. This is still to handle if this 
feature is used like it is intended to, as a picture for illustration.

Animated pictures with several fps might be an issue. But as you wrote, 
there is already better software for that purpose.
Perhaps we need some kind of bandwith limiting to prevent LCDd / the 
display from flooding.
> 2. LCDproc protocol is not designed for transmitting binary values. One
> will need to encode/decode the image part somehow.
My suggestion: Set the most significant bit of the char values to "1" 
and use the remaining 7 bits for data.

> Still I believe, if we turn LCDproc into a program where the client
> submits a fully client drawn image that is just displayed by the server,
> one should use some other existing program that already has that feature.
It is not my main intension to transfer complete rendered screen to the 
LCDd.
My intension is to use one or more small images within the text based 
screen.
The concept I had in mind is very similar to the one Ethan explained.

-The client requests a picture widget in character coordinates. The 
LCDproc screens are defined in characters, so we can't change that if we 
will remain compatibility.
-The LCDd will respond with the actual picture size in pixels (which is 
display dependent). The picture size (width & hight) has to be used by 
the client to generate the pictures for that picture widget.
-When setting the picture content the LCDd will expect exactly width * 
hight bits of pixel data.

With this mechanism LCDd does not need to scale the pictures, the code 
stays compact and we avoid dependencies with external libs.

The LCDd might also be able to store several pictures for one picture 
widget. With this the client will be able to switch between this 
pictures without the need to upload the picture every time.



Regards
Stefan