TCanvas::Print PNG outputs fraction of figure when canvas size is declared

When declaring the size of a canvas in the constructor the Print method to png outputs only the upper right corner of the figure. Without specification of the dimension the Print method works as expected. (I assume I will have to wait until @couet returns for an answer.)



c3
(The third figure is not uploading correctly here for some reason.)

{
   TH1F *h = new TH1F("h","",100, -2, 2);
   h->FillRandom("gaus",5000);

   TCanvas *c1 = new TCanvas("c1");
   c1->cd();
   h->SetTitle("No Canvas Position or Size Info");
   h->Draw();
   c1->Print("c1.png");

   TCanvas *c2 = new TCanvas("c2", "", 800, 600);
   c2->cd();
   h->SetTitle("Canvas with Size Information");
   h->Draw();
   c2->Print("c2.png");

   TCanvas *c3 = new TCanvas("c3", "", 0,0, 800, 600);
   c3->cd();
   h->SetTitle("Canvas with Position and Size Information");
   h->Draw();
   c3->Print("c3.png");
}

Generated on ROOT 6.10.04 MacOS X 10.12.6

I’m not sure that exactly covers what is going on here. I know for sure that my screen is larger than 800x600 pixels.

This is definitely the same issue as:

Also, the output is the same dimension in all three cases roughly 800x600. It seems that the c2 canvas is exploded.

I think all these problems are related to some misbehaviour during interaction between ROOT and the window manager.

There are two JIRA reports that I know of:
https://sft.its.cern.ch/jira/browse/ROOT-7469
https://sft.its.cern.ch/jira/browse/ROOT-7552

BTW. I have just checked them and I can confirm that both reported problems (the completely unreliable TCanvas::SetWindowSize and the one related to “RequestedH” and/or “RequestedW”) are still there in the newest ROOT v5-34-00-patches and in 6.10.04.

To make this even worse I discovered today that the outcome of the png depends on which monitor my terminal is sitting it. I can run the script with the terminal in a small monitor and get a corner and then move the terminal to a large monitor and get the entire image.

Just a bump so this doesn’t get locked before it is resolved.

I just ran your macro on Mac with ROOT version 6.11/01 . I ran it in interactive mode and in batch mode. The 3 png files it produces are correct in both cases. I do not see the effect you are mentioning in your first post.

I believe this is dependent on the monitor configuration. I have a somewhat unusual setup on this machine with four monitor all over various dimensions. I have the following (I don’t know how to have it list the relative positions, but I’d be willing to experiment if needed.):

Monitor Dimension Rotation
1 3360 x 1890 0
2 1200 x 1920 0
3 1920 x 1080 270
4 1200 x 1600 90

The total resolution reported from xrandr is is 7680 x 1898

In addition, the clipping only occurs when the terminal is placed in either of the rotated monitors. The problem does not show up in batch mode (I have noticed that images made in batch mode are sharper than those created outside.)

Is there something else I can provide to help your investigation?

After some further testing, I seem to have narrowed it down to the fact that there are three rotations. If I reduce the number of rotations to one (All 0 degrees) or two (0 deg and 90 deg OR 0 deg and 270 deg) then the issue seems to go away. I didn’t realize initially that this would be such a strange corner case.

I don’t use any fancy rotations and I clearly get today both problems that were reported more than 2 years ago.

@Wile_E_Coyote would you be willing to provide your display setup?

This is an old HP EliteBook 8530p laptop running Ubuntu 14.04.5 LTS / x86_64:

[...] $ xrandr
Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 8192 x 8192
VGA-0 disconnected (normal left inverted right x axis y axis)
LVDS connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   1680x1050      60.0*+
   1400x1050      60.0
(...)
   640x480        59.4
DVI-0 disconnected (normal left inverted right x axis y axis)
HDMI-0 disconnected (normal left inverted right x axis y axis)

I ran again the macro using the X11 backend on Mac both in natch and interactive mode and the 3 png files are correct. It was hard to debug a problem I cannot reproduce …

I’ve further narrowed this issue down. It doesn’t have anything to do with the construction of the Canvas. It just so happened that when specifying the size alone the canvas was created on the largest monitor in my setup (3360 x 1890), while in the other two case the canvases were created on other windows. If I move any canvas to the large monitor and select print I only get a corner of the image. Further more this screen has the resolution scaled, if I remove the scaling and use the native resolution (3840 x 1920) then the issue disappears.

I see. I am sorry but i do not have such setup to test/debug that.

You do not have access to a Mac? Wile, indicated that the problem is also visible on Ubuntu. I believe all that needs to be done is to scale the resolution through the Display Settings. Is there something I can do on my end to provide more debugging information? I probably just need a couple of ideas of where to look to get started.

Yes that’s my machine. But the macro you provided are giving me the right png output whatever I try. May be I missed something.

I think the problem originates somewhere in TCanvas::SetWindowSize which sometimes fails in interactive mode, but here’s your own, more than 2 years old, post concerning the second problem:

Thanks for the reminder. I am looking at it again now. There is an even simpler reproducer.

void png_double_x_axis_title(){
   TCanvas *c1 = new TCanvas("c1","c1",0,0,1000,2000);
   c1->DrawFrame(0.,0.,10.,10.);
   c1->Print("test1.gif");
   c1->Print("test1.png");
   c1->Print("test1.pdf");
}

So it shows only with the X11 version in interactive mode. It works in batch mode. gif and pdf work in both mode. The Cocoa version is fine in all cases.