[QtRoot] Problem rendering a canvas on Qt widgets


This is actually a continuation of the thread [url][QtRoot] Canvas update problem
In the test program, the canvas is correctly updated if you do not overlay a TSpline3 on a TGraph using “same” option but draw the TSpline3 with “LP” option.
But the canvas messes up when you resize the window like magnification of a coarse bitmap image.

Could you let me know if this is not reproduced in your environment?

Thank you!

I’ll check that tomorrow (sorry I missed your post).
Meantime can you check whether problem can be ‘fixed’ if you "refresh’ the image (for example, as soon as you click into the TCanvas area after resizing)
Please, attach your last version of the test code to THIS thread.

Hi, thank you for reply.

In this case the view is not corrected by resizing the widget. Rather, resizing itself messes up the canvas unlike the case of TGraph.
Please try the attached program.
test.tar (10 KB)

I tried QtGSI, that is, I replaced TQtWidget with TQRootCanvas.
It works fine except that the canvas once disappears after resizing.
The canvas correctly updates the view right after the graph is recreated.
I attached a test program.
test_qtgsi.tar (1.25 KB)

Sorry for delay.
I reproduced your issue.
For me this sounds like the TSpline3::Paint method bug the Qt plugins just reveals.
By some reason, it, TSpline3::Paint, paints things twice (including all axes and backgrounds etc).
The patch

[code]— test.cc.original 2011-09-16 08:07:00.000000000 +0200
+++ test.cc 2011-10-04 20:31:13.000000000 +0200
@@ -28,15 +28,15 @@
for (int i = 0; i < 10; ++i)
g->SetPoint(i, i, gRandom->Gaus());

  • // g->Draw(“ap”);
  • g->Draw(“ap”);

    delete s;
    s = new TSpline3("", g);
    s->SetBit(kCanDelete, kFALSE);

  • // s->Draw(“same”);
  • s->Draw(“LP”);
  • s->Draw(“same”);

  • // s->Draw(“LP”);

    // w->GetCanvas()->Modified();
    // w->GetCanvas()->Update();
    [/code]solves the “resize” issue and brought back ](*,) the “re-draw” one. behavior is consistent with what I see with the TSpline3::Paint method.

Can you confirm that this issue is TSpline3 related only?
Did you see such trouble with the other ROOT classes ?

See TSpline3 problems


permalink.gmane.org/gmane.comp.l … .root/7522 also.

Hi, thank you for reply.

Yes, and it is the real problem.
I wonder if none of QtRoot users had ever encountered this issue.

[quote]Can you confirm that this issue is TSpline3 related only?
Did you see such trouble with the other ROOT classes ?[/quote]
Actually, yes.
“Re-draw” problem also happens with histogram.
As you can see in the attached program, even a simple histogram is not redrawn correctly.
But strangely, the malfunction disappers if you set “fill color” of the histogram by uncommenting 29th line of test.cc.
test3.tar (10 KB)

[quote=“kame”]As you can see in the attached program, even a simple histogram is not redrawn correctly.
But strangely, the malfunction disappers if you set “fill color” of the histogram by uncommenting 29th line of test.cc.[/quote]
Great, thank you for your remark. I did suspect such kind of thing. Alas, I had no time to track it down yet. My guess ROOT "cleans "the canvas/pad/frame using what the Qt layer interprets as “transparent color”. I.e. doesn’t clean. My guess the fill color was changed somewhere between version 5.26 and 5.28 (That is when people start complaining. There is open Bug Report on the issue indeed)

Since "full-fledged transparency was implemented by Qt plugin only the other implementation may not be affected. ( one promised the full-fledged transparency will be available for the other ROOT platforms with the OpenGL rendering engine)

I;ll try to use your new example to track things. With the histogram example it is simpler. Thank you

Thank you. I wish I could do more than just wait…

By the way, reading this ([url]Clickable ROOT histograms in QT thread, I got a little anxious about the future of QtRoot.
I guess that ROOT team had repeated a lot of discussions to reach a conclusion, but I wonder how they decided to re-invent the wheel rather than take advantage of Qt, which is nearly complete toolkit for developing GUI application.
I once wrote a GUI app using native ROOT’s TG* classes, but switched to QtRoot. The biggest reason is that Qt has “Designer”. I believe that everyone agrees that using such tool is much more intuitive and productive in layouting widgets than coding by hand. ROOT’s “GUI Builder” seems still under development…

Hello, I have found that the patch:

[code]Index: graf2d/gpad/src/TPad.cxx

— graf2d/gpad/src/TPad.cxx (revision 41538)
+++ graf2d/gpad/src/TPad.cxx (working copy)
@@ -3123,7 +3123,6 @@
Int_t style0 = GetPainter()->GetFillStyle();
Int_t style = style0;
if (option[0] == ‘s’) {

  •     GetPainter()->SetFillStyle(0);
        style = 0;
     if (style) {

[/code]resolves :exclamation: your issue. Can you check that?

I found another fix too

[code]Index: src/TQtBrush.cxx

— src/TQtBrush.cxx (revision 3504)
+++ src/TQtBrush.cxx (working copy)
@@ -213,8 +213,6 @@

case 0:
setStyle(Qt::NoBrush); // hollow

  • fBackground = Qt::transparent;
  •    fAlpha = 0;
    case 1: // solid
    setStyle(Qt::SolidPattern);[/code] One can try to apply either one or both of them. Two fixes should provide slightly better performance because they eliminate the redundant operations.

Do not forget to initialize your “h1f” data-member in your class ctor to avoid the crash :wink:
The entire thing was started somehow in 2003 #-o with the workaround root.cern.ch/viewvc/trunk/graf2d … 57&r2=6987

By the way if you want to improve the performance of your example, please, consider the patch:[code]
lxplus412.cern.ch> diff -uwb test.cc test.cc.update
— test.cc 2011-10-05 02:17:12.000000000 +0200
+++ test.cc.update 2011-10-24 01:42:25.000000000 +0200
@@ -7,7 +7,7 @@
#include “TRandom.h”
#include “TH1.h”

-MainWindow::MainWindow(): w(0), g(0), s(0)
+MainWindow::MainWindow(): w(0), g(), s(),h1f()
w = new TQtWidget(this);
@@ -23,13 +23,15 @@

  • delete h1f;
  • if (!h1f) {
    h1f = new TH1F(“h1f”,“Test random numbers”,200,-2,2);
  • h1f->SetBit(kCanDelete, kFALSE);
  •  h1f->SetDirectory(0);
  •  h1f->Draw();
  • } else {
  •  h1f->Reset();
  • }
    // h1f->SetFillColor(45);
  • h1f->Draw();
  • w->Refresh();

Hi Valeri,
I applied the patch for TPad (removing the line GetPainter()->SetFillStyle(0):wink: but still the problem persists. I am attaching the screenshot of the hstack.C program in root tutorials. I am still trying to find the causes and will post to you if I can get a workaround.

Hi Samuel,

Yes, I can still reproduce your issue. The last fixes did not change it. By some reason, I can not check right now the regular X11 GUI. Can you confirm that you get this issue with the Qt-plugin only?
Thank you.

I can confirm that this is only with the QtPlugin. I have attached the screenshot of the output from the “without qt” version of root.

Can you try another patch:

[code]Index: hist/hist/src/THStack.cxx

— hist/hist/src/THStack.cxx (revision 41538)
+++ hist/hist/src/THStack.cxx (working copy)
@@ -808,7 +808,7 @@
lnk = (TObjOptLink*)lnk->Prev();

  • if (!lsame) fHistogram->Paint(“axissame”);
  • if (!lsame) fHistogram->Paint(“same”);
    }[/code] I am not [-X sure whether it fixes the issue without any “side effect” elsewhere. However it does show the origin :bulb: of your issue.

Just search Forum for THStack to discover the bunch of the useful tricks one needs to apply to get THStack right.

It still did not help :frowning: . I am searching the forum now for some tricks !

Umm, it is strange I got the correct result with those patches.

Thanks for the reply, I have now messed up a lot of things in the installation hunting for a solution. I will now install once again from the scratch and let you know soon.

I have now made a clean install with version 5.30 and here are my observations:
With the patches for TPad and THStack, the hStack.c tutorials output was clean. However, in a TQtWidget embedded in my Qt application, though the stack is plotted properly, the moment it is resized or moved, the problems comes once again. This is slightly different from the original problem where the overlapping happened even while plotting. You can see the screenshots attached here. Anyway, thanks a lot for your kind help and spending your valuable time in such a wonderful project.
I shall update you with more details

Issue resolved. The patch really works! It was my mistake that I had a line like
after the plotting of the stack (I had added this while searching this forum for various workarounds).
Thank you Valeri once again!

[quote=“samcy”]Hi, …
Issue resolved. The patch really works …[/quote] =D> I would like to hear from kame to confirm that his issue was resolved as well [-o< .

I am sorry that I had missed your post.
Now it works perfectly!
Thank you very much !! :smiley:
Will your patch for TPad be included in the next ROOT release?