One should use ROOT::EnableThreadSafety() call if canvas have to be used
in multithreaded environment

If same batch job reused second time, one should update drawing
correspondently

When many threads tries to stream same class for first time - it causes
I/O problem while many TClass and TStreamerInfo instances need to be
created. Probably global ROOT mutex has to be used.

Use shared_ptr<WebCommand>, keep it inside lambda.
Command also checked if connection gone 

Only in such case updates will be delivered to clients - also in batch
mode

To create different images canvas will always start headless browser -
at least now. To generate many files same job will be used.

Introduce correspondent constructor signature for contained classes

Probably, one could create special class for canvas

RCanvas::Run(doble) runs canvas functionality for specified time, 
must be regularly called when canvas should be used from user thread

RCanvas::Remove() method remove canvas from global lists, let destroy
canvas regularly

Update tutorials/v7/draw_mt.cxx macro

Mutex is booked in the beginning of operation and unbooked at the end
with specialized guard class. This prevents from complete locking of the
mutex for very long time

* Change v7 (graphics) classes' names from Txxx to Rxxx

* more changes in linkdef.h

* Change the test macros.

* Modify v7 tutorials

* missed a "TPalette"

* T->R translate more tests.

* Update globbing to look for ROOT/R*.h

* webdisplay and fitpanelv7 are not yet converted to "R" naming.

* Fix typo

* Fix typo
increase space between lines

browser)

Add error output when canvas fails to produce image

Main application for such commands - creation of the image files.
ROOT code waits from the client to store image in the file.
By default 100 s will be used. Normally image creation is much faster

Now always on first place connection id should be specified.
Sorry for interface change

There is ROOT standard way to decode such data - use it.
Base64 decoding used to send PNG/GPG/SVG images from clients to server.
For the moment there is no other way to transfer binary data from
clients

Also including subpads

It is base class for painting of drawables in each pad. 
CanvasPainter derived from TPadPainter and adds all kind of
window-management methods

At the moment when window will be created, one requires data which
should be send to the client(s)