Hello Valeri,
VF> 1. How this fits multithreaded applications (otherwise one meets
VF> dead-end) (see last week discussion)
It looks like that the TGX11 implementation of the TVirtualX interface
is not thread safe at all. For example, if there are 2 threads doing
some job and want to draw something at different windows/canvases. The
result might be very funny, because one thread will select its canvas
and will be sure, that this selection will be correct during all
drawing operation. The other thread will "thing" the same. The
question is which one will win?
VF> 2. How Qt event loop will "collaborate" with ROOT event loop.
This is the main direction of my studies right now. The main question
is how to make this cross-platform.
As I know ROOT event loop is more complicated comparing to the Qt
event handler. ROOT deals with a lot types of events and GUI is only
one of them.
VF> 3. To eliminate the peformace penalty it would be good to
VF> introduce some sort of method like:
VF> TVirtualX->PaintBegin(int wid)
VF> TVirtualX->PaintEnd(int wid)
This would make drawing operations much faster and really thread safe
if drawing code will pass some object (paint device descriptor) to the
DrawXXXX functions. Like in Windows (Device Context) or Qt abstraction
as QPainter, and perhaps the same technique is used in GTK.
But this will require to change all ROOT painting architecture.
VF> 4. One should change the double-buffered ROOT schema The small
VF> correction may simplify the TVirtualX implementation (I've sent my
VF> proposal to Fons). to emanate and the logice it entails.
VF> struct SVirtualWnd
VF> {
VF> QPaintDevice *main;
VF> QPaintDevice *buffer;
VF> bool isWidget;
VF> };
VF> TVirtrualX class should do nothing with the "double buffer". It is
VF> a job of TCanvasImp class. TVirtualX should work with ONE
VF> QPaintDevice.
I think this design is much better than current. If TCnavasImp could
draw this will make architecture more flexible. I mean TCanvasImp
would has DrawXXXX functions. For example you could use different
implementations for different canvases like
TCnavasImpBuffered -- it would be reasonable for 2D plots, that
draws a lot of overlapped objects.
TCanvasIpmDirect -- to draw directly to the screen. That is the
best for histograms and 1D functions plots.
and, for example
TCanvasImpRemote -- optimized for network rendering.
What do you think about this?
Thank you very much for your suggestions and comments.
Best regards,
Yriy.
VF> By the way AddWindow should return (int)(QPaintDevice *)
VF> This eliminate your TGQtWndMan.
VF> For example one will be able (it is how the current Win32 impl works)
VF> void TGQt::CopyPixmap(int wid, int xpos, int ypos)
VF> {
VF> assert(((QPaintDevice *)wid)->devType() == QInternal::Pixmap);
VF> if (fSelectedWindow && (int(fSelectedWindow) != wid) )
VF> {
VF> QRect r = GetQRect(*fSelectedWindow);
VF> r.setX(xpos);
VF> r.setY(ypos);
VF> fQPainter.drawPixmap(r,*(QPixmap *)wid);
VF> }
VF> }
VF> There are some othe issues. For example one needs to be able to use RGB with
VF> no color index involved. This this ancient schema ROOT inherited from that age
VF> when we had 8 colors terminals. Eliminating color index will simplify things
VF> tremendously ROOT wide.
VF> Just have a look at http://root.cern.ch/root/htmldoc/src/TColor.cxx.html#TColor:SetRGB
VF> to understand how slow and complex the current schema is.
VF> For example if TColor::GetNumber will return the packed color index (8 bit)
VF> + r ( 8bit) + g (8bit) + b(8bit) = 32 bits, then will be no need for your class TGQtColorMan
VF> with typedef QMap<int, QColor> ColorMap; If r = g= b=0, then thing works as before
VF> for the sake of the backward compatibility. (for this case Qcolor RootColor[256] or
VF> even better vector<QColor> will be just fine (and faster)
VF> As it was proved many times it is not difficult to learn how to draw
VF> the filled rectangular on the screen. The question how to do this drawing
VF> reasonable fast and useful.
VF> This means one has to wait ROOT team word.
VF> If you find my thoughts useful and you do have time to work on,
VF> send me mail.
VF> Cheers,
VF> Valeri
VF> -----
VF> Dr.Valeri Fine
VF> STAR/US Atlas E-mail: fine@bnl.gov
VF> Brookhaven National Lab Phone: +1 631 344 7806
VF> Upton, NY 11973-5000 FAX: +1 631 344 4206
VF> USA
VF> ----- Original Message -----
VF> From: "Yuriy" <yuriypro@mail.ru>
VF> To: <roottalk@pcroot.cern.ch>
VF> Sent: Thursday, November 08, 2001 12:38 PM
VF> Subject: [ROOT] TGQt
>> Dear ROOTer, here is the first draft of the TGQt class (Qt ROOT
>> interface). My approach differs to the Go4 way. I have substituted
>> gVirtualX to Qt implemented drawing class. So it seems to work on
>> different platforms. I tested Linux+Qt3.0 and Windows+Qt2.3, and it
>> works! There are Makefile for Linux and .dsw for VStudio, so you can
>> compile it on both platforms.
>>
>> If somebody will interested on my future Qt ROOT studies just write
>> me a letter.
>>
>> Best regards,
>> Yuriy.
>>
>>
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:07 MET