Qapplication, TQtWidget and histogram drawing

ROOT
1

Hi everybody,

I’m asking for help because I’m writing an acquisition program that controls some digitizers, and I need to show and update a couple of histograms while the data keeps coming. The problem is that I can not have a reliable update of the histograms, they are all stacked and trasparent (N histos for N seconds, all visible) or they have a black background that hides axes.

The problem is similar as the one discussed here Test other language but the workaround described there doesn’t work anymore.

I tested the problem on two systems: Ubuntu 12.04, Qt4, root 5.34.14, and Ubuntu 13.10, Qt4, root 5.34.14. As you can see from the discussion linked above, the problem was present also in root 5.30 and probably 5.32.

I’m attaching a small working example of my interface. The makefile is the same as generated by qmake, with the only addition of root-config --glibs and root-config --cflags.

Some more details: without the workaround described in the other topic, I can not clear the canvas and the histos are superimposed, as you can see with the attachments. With the workaround (SetFillStyle and SetFillColor) everything works for TH1F but the first histo drawn after a TH2F has a black background. I mean, if I draw TH1F, then TH2F, then TH1F again, the last TH1F has a black background. If I draw TH1F, TH1F, TH2F, TH2F, TH1F, the second TH2F and the last TH1F will be black, and so on. I couldn’t find any way to remove this black, except for drawing one fake TH1F after each TH2F (sounds crazy, I know).

What I’m looking for is either an affordable way to clear the canvas (Erase, Clean, Update, GetPad(0)->Modified() do not work!) or a workaround that do not cause black backgrounds.

What is the correct sequence of declaring a TQtWidget, cleaning the canvas and updating a histo?

Any help would be REALLY appreciated! 8)

PS: I googled a lot on the subject and I played with SetFillStyle, SetFillColor, Update, Modified, in several combinations. Sometimes I was simply shooting in the dark, I admit… but with no results. :blush:
testGUI.zip (3.75 KB)

2

Testing with ROOT 5.32.01 and Qt 4.8.1 on Windows with slightly tweaked TGQt (added initialization of gPtr2VirtualX), the example worked except that the background colour changed from white to grey on first radio button click and remained grey. That could be fixed by adding gVirtualX->SetFillColor(x); before Draw()-calls in updatePlot(), where x is not kWhite, e.g. 1. It’s worth noting that replacing the suggested call with
screen->GetCanvas()->SetFillColor(1);
did not behave the same.

3

Any update on the issue?

4

Hi,

I spent last days trying to fox some other issues… how exactly did you tweak TGQt?

5

Sorry for the confusion: the changes in TGQt (added gPtr2VirtualX = GetVirtualX; in TGQt constructors) were not really related this problem, but I just mentioned those for completeness (i.e. running the example without those changes shows no histogram graphs at all, I reckon that to be Windows-specific).

So the gVirtualX->SetFillColor(x); call is really the only relevant part here.

6

Excuse me, I was on vacation and did follow the forum.I am trying to catch up. I’ll try to reproduce your issue and come back with the remedy (sorry, tomorrow only, our lab is closed due the weather condition) . Please, be patient.

           Valeri
7

In case this is of any use, here’s what I found out while examining the issue. It looked like a possible buggy handling of colour alpha-parameter around TQtBrush::SetStyle. The thing that fixed the issue for me was a way to force resetting alpha-parameter through colour change in TGQt::ColorIndex. Another way to diagnose the problem was to note that removing parameter “s” from TPad::PaintBox that gets called from THistPainter::PaintFrame() also seems to fix the problem (at least the one I had).

8

[quote=“tc3t”]… Another way to diagnose the problem was to note that removing parameter “s” from TPad::PaintBox that gets called from THistPainter::PaintFrame() also seems to fix the problem (at least the one I had).[/quote] Thank you. It makes sense. In my mind I did file a ROOT bug report regarding the redundant “s” parameter. I’ll re-check tomorrow.

9

Thank you both… I’ll stay tuned!

10

2davide84
Did you try the gVirtualX->SetFillColor(1); trick (it’s a one line addition in two places in testGui.cpp so it’s easy to test)?

11

It partially works.

I mean, if I switch from TH1F to TH2F, both have white background and they are not superimposed anymore.

But…

  • legends are transparent
  • in TH1F old legend is visible when updating
  • in TH2F leged is updated correctly
  • when moving legends they are drawn multiple times

This can be an interesting workaround if I do not use legends, but the problem with canvas updates is still present.

(updated code to demonstrate workaround)

PS: but thank you, in a couple of projects this trick will probably do the work :wink:

refresh.jpg642×509 47.5 KB


testGUI.cpp (1.53 KB)

12

It sounds it is the same issue reported with Test other language

In my mind one needs to patch the vanilla ROOT and I did submit that patch

One can find the links to the patches within my INSTALL_QTROOT.sh ( see root.bnl.gov/QtRoot/How2Install4 … complement also )

I need to re-apply it yet to the newest ROOT version to see whether it fixed this issue

Stay tuned.

13

It is… but the workaround described therein is not working anymore.

14

Yes, I did say this with my [QtRoot] Canvas update problem
The core reasons were not fixed, namely,

  1. The ROOT core tries to paint the TCanvas several times one image over another one. On X11 it is just slow down the rendering
  2. Each time the ROOT tries to guess the actual widget pixel size. That size is slightly different due rounding between Qt and X11 Windows manager and between the rendering passes. This can be neglected if one paints the canvas one time only and /or the size remains the same between passes. With several paintings the effect may become visible.

The solution:

1) Paint the TCanvas at once ( All platforms will benefit.  It will be faster)

2) Do not guess the widget size. Always ask the lower level "window manager" (X11 or Qt or Win32 ) about the canvas current actual size or something like this.  The current approach was adopt a whi-i-i-i-i-le  ago.  It was likely chosen at the time the network connection was slow and expansive.  I am wondering if ROOT (PAW in fact) could not afford  to ask  the remote X-terminal what the real widget pixel size is frequently.
  1. ROOT should not use the transparent color code to wipe the TCanvas. The lower GUI level is given no clue whether the user code wanted the real transparent layer over the existing one or wanted the clean the TCanvas. That has been working for X11 for years because X11 ROOT implementations did not provide any transparency at all

Mean time , there is no magic wand . One has to spend time digging the recent ROOT code to look for 1) ,2) or 3) “new” violations and/ or use the older version.

I’ll check whether some workaround can be done from within QtRoot layer ( I did not find that last time. It was simpler for me to find the core ROOT issue and patch it)