[Solved]Wrong Size and Positions with OpenGL3 Renderer Linux

[atom]

I'm not sure I understood correctly your question; tell me if I'm mistaking.
I use glfw 3.1 in my code and glfw 2.7 for the CEGUI samples.

[Ident]

Yea, that's what I wanted to know.

Do you correctly notify CEGUI of the display size? With the correct display size sent?

[atom]

Whenever I resize my rendering window, I notify it to CEGUI by calling

Code: Select all

CEGUI::System::getSingleton().notifyDisplaySizeChanged(
    CEGUI::Sizef(
      static_cast<float>(aspect.width),
      static_cast<float>(aspect.height)
    )
);

Maybe I'm making a confusion here. Width and height are what I send to glViewport, so they are numbers of pixels. A resize event is fired at initialization of the application. Still, I tried to notify to CEGUI the size of the window at startup with the same code snippet (just before the main loop): no change in the behavior.

[Ident]

We know your example worked on dermont's computer and on your "PC1". Therefore the issue is very likely not in CEGUI or your CEGUI initialisation/updating directly - it has to be in either drivers of dependencies, at least to some extent (it could be that "wrong handling" of CEGUI still plays a role but I dont see how). Maybe the XML loader messes up?

We know it stopped working on PC1 after a "system update". Could you elaborate on that update and what it entailed? It would be good to have a list of dependencies and to see their version changes. Then we could go through them one by one , I assume you can install older versions of deps in the package manager right? (I dont know how your OS works)

[atom]

Unfortunately, I will never be able to tell you what were the update on that computer.

Out of curiosity, how can it be the XML parser's fault? We checked the widgets have correct positions and sizes in CEGUI by hovering the places they should appear with the system's cursor. Those positions and sizes are the same sent to the driver, no?

As those positions and sizes are correct and as it worked on dermont's computer, I think you're right: something apart from CEGUI itself is messing with the driver. I'll keep my computers up-to-date, maybe one update will fix the issue

[Ident]

Yea the idea about the XML parser seems strange - the reason i considered it was because the rendering also needs to be parsed. But on second thought, this cannot change the wrongly rendered position. In fact, the only way that it is wrongly rendered is if the shader isnt compiled right or the window size isnt right. In your screenshot it looks as everything is compressed vertically and horizontally, thats why I was asking about notifyDisplaySizeChanged.

Can you do one more thing? In your main loop, call notifyDisplaySize with a fixed value that fits your application window dimensions. What happens then?


What bothers me most is that the SampleBrowser is rendered incorrectly. Makes me almost certain it is something with OGL (drivers?) and the interpretation of the shader code. I mean, how else....

[atom]

I've already tried to call notifyDisplaySize in the main loop (it was my first reaction when the problem appeared, calling this method everywhere). No change.

I tried then something else: I changed the size of the window and the size of the main framewindow (I removed everything else from the layout). The frame window was set to take all the display area (<Property name="Area" value="{{0,0},{0,0},{1,0},{1,0}}" /> if I'm not mistaking). And I always have the following situation:

[Ident]

I just realised your layout has no root window. Create a DefaultWindow, set it it to the size you just mentioned and add the frame window and all siblings to this DefaultWindow. You always should have a DefaultWindow spanning 100% width and height as a root.
You also seem to not be injecting timepulses (guicontext and system). See the CEGUI docs for more info.


Btw this wont help the fact that the SampleBrowser does not work. ALso it doesnt explain why it works for dermont or on your old computer setup.

[SirTomsalot]

So was there a solution? I have the same exact problem.

[atom]

No solution yet.
However, I hope that there will be one soon thanks to Issue #1063 on bitbucket.

[dermont]

No solution yet.
However, I hope that there will be one soon thanks to Issue #1063 on bitbucket.

Yeah hopefully, since there have been a number of reports from people there must be a bug somewhere. The only other thing that I could think of on glfw would be checking if your framebuffer size matches your window which may not be the case for high-DPI monitors. Is this problem specific to glfw? , i.e. has anyone tried running a simple OpenGL example not using glfw.
http://www.glfw.org/docs/latest/window.html

[SirTomsalot]

Is this problem specific to glfw? , i.e. has anyone tried running a simple OpenGL example not using glfw.

I use native OpenGL with SDL2, no glfw.

[Ident]

I wanted to do the diff the last two days but I m swamped with writing my master's thesis and an exam tomorrow. I will however do the diff between 0.7 and 0.8 opengl renderers today and see if I can find out anything. Atm. the OpenGL Renderers seem to be the most likely source for such an issue.

Btw., i find it odd that this problem for so many people occur now, the 0.8.0 release however was reported to have the same issue and it is over a year old. But maybe it is just a coincidence. Or maybe some Linux update caused it (or made our bug become visible?). Or maybe you guys all use ultra-hd monitors?

Talking about that - what display resolutions do you guys btw. use? That could be another hint.... maybe.

[SirTomsalot]

This happened to me when I updated my linux from Ubuntu 11.04 to Mint 17.1 and updated my graphics drivers to nvidia-331.113.
I have another computer that has the "old" configurations with working build if thats any help

[Ident]

This happened to me when I updated my linux from Ubuntu 11.04 to Mint 17.1 and updated my graphics drivers to nvidia-331.113.
I have another computer that has the "old" configurations with working build if thats any help

That does help!

Do you use exactly 1:1 the same hardware on both of these setups?