Re: [Xenomai] Heads up: I-pipe patch status on ARM

[xenophile <xenophile@piments.com>]

On 07/29/12 13:32, Gilles Chanteperdrix wrote:
> On 07/29/2012 01:24 PM, xenophile wrote:
>
>> On 07/29/12 13:16, Gilles Chanteperdrix wrote:
>>> On 07/29/2012 01:09 PM, xenophile wrote:
>>>
>>>> bitmap rendered graphs should be a relic of  the 1990's ;)
>>>
>>>
>>> On the other hand, a bitmap is rendered once and only once, which really
>>> makes sense for a static page, will appear the same in all navigators,
>>> including those which do not support svg.
>>>
>>
>> How often it is rendered depends upon the viewer. I don't see how this
>> relates to whether the page is "static". (I'm assuming you are talking
>> about static vs dyanamic content at the server end).
>>
>> I don't see any fundamental difference in whether you _create_ (as
>> opposed to render) a graphic in svg , png or jpeg.
>>
>> There is nothing about svg/svgz that means you have to create it on the
>> fly each time you serve a page. It is an XML format but as I said it can
>> be embedded (hence the svg part can be pre-made).
>>
>> I do this on a 200MHz embedded ARM system running lighttpd. The pseudo
>> real-time output is created in svg every 15min or on demand. The
>> surrounding html template is static.
>
>
> As far as I understand, the rendering (I am talking about the graphical
> rendering) is done by every client which wants to view the graph, which
> is stupid if it is always the same graph (that is what I meant by
> static). And has a number of issue.
>
> I do not understand why you do not want to do the rendering on a 200 MHz
> ARM, but if the machine serving the page is powerful enough, and the
> graph not updated frequently, I find it makes a lot of sense to do the
> rendering only once.
>
>> Gnuplot runs on the ARM.
>
> I do not discuss the fact that getting gnuplot to generate an svg will
> consume less power. But overall, it will get all viewer to consume power
> to do the rendering, which the static bitmap file avoids.
>

The whole point of SVG is the S: scalable. If you "render" it to a 
bitmap on the server no one scale it in their viewer (web browser in 
this case).

Now whether decoding png or jpeg compression of an image (including much 
blank white area) and then interpolating to the final screen rendered 
size raster image in the users browser is more or less "power efficient" 
that sending a textual vector description that the viewer draws line by 
line I have no idea.

Since the PC is probably consuming about 150W just sitting there I'm not 
sure what the point aiming for is.

SVG, basically gives the browser and the user total freedom of what size 
to scale the output. rather than sending a series of dots which have a 
predetermined resolution.

My reason for using SVG on the ARM is not save power or because it could 
not handle producing a png , it is to give the viewer of the graphic the 
ability to zoom in to any desired level and benefit from things like 
toggling off lines that obscure the one he's interested in and getting 
cursor readout of data points on the graph.

No way is that sort of thing possible with png.

I don't quite think you are appreciating all the differences between 
vectorial and bitmap formats.  Hopefully, I've explained some of our 
confusion over the term "render". The image is only rendered in the 
viewer, Both vector and bitmap are descriptions of what has to be rendered.

regards