|
|
Home » Community » U++ community news and announcements » Critical issues to resolve for U++ 2018.1 - please suggest
|
Issues with OpenGL [message #49285 is a reply to message #49280] |
Mon, 15 January 2018 22:00 |
ren42
Messages: 12 Registered: July 2006
|
Promising Member |
|
|
Hi Mirek,
I tried to compile the reference/GLDrawDemo example but compiling fails:
/home/thomas/upp/uppsrc/GLDraw/GLDrawS.cpp (245):
error: non-constant-expression cannot be narrowed from type 'int' to 'GLshort' (aka 'short') in initializer list [-Wc++11-narrowing]
I was able to fix these errors with three changes in GLDrawS.cpp:
Line 244
// GLshort vertex[] = {
GLint vertex[] = {
rect.left, rect.top,
rect.left, rect.bottom,
rect.right, rect.bottom,
rect.right, rect.top,
};
Line 307
// GLshort vertex[] = {
GLint vertex[] = {
r.left, r.top,
r.left, r.bottom,
r.right, r.bottom,
r.right, r.top,
};
Line 373
// GLshort vertex[] = {
GLint vertex[] = {
rect.left, rect.top,
rect.left, rect.bottom,
rect.right, rect.bottom,
rect.right, rect.top,
};
With this changes it compiled and run but...
the window shows only a copy of the screen "behind" it
instead of rendering what this example want.
Is the type change from GLshort to GLint ok?
Or is there something wrong with OpenGL?
my System:OpenSuse Leap42.2 Upp2017.2 clang
Thanks in advance,
Thomas
|
|
|
Re: Issues with OpenGL [message #49286 is a reply to message #49285] |
Mon, 15 January 2018 22:27 |
|
Klugier
Messages: 1083 Registered: September 2012 Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello,
I am aware that OpenGL implementation is not working as it should be on Linux. The first reason is that our GTK backend doesn't support DHCtrl. Which is require for high performance OpenGL. On the other hand our X11 implementation that worked previously for some reasons stops working (Due to Mirek's patch to CtrlCore). And there is no obvious way how to fix it - I spent some time try to fix it without success.
However, from Linux our goal should be developing DHCtrl for GTK and after that build OpenGL ctrl. The X11 back-end has got lower priority for us. I believe for now we should only fix crashes - nothing else.
Mirek fix GLDraw compilation at 9th January of 2018. It should be fixed in next release.
+Mirek
I prioritize some redmines ticket and set them with hight priority. Can you look at this and analyze that should we fix it in 2018.1 (Service pack for 2017.1). Just sort "Issues" with priority.
Sincerely,
Klugier
U++ - one framework to rule them all.
[Updated on: Mon, 15 January 2018 22:43] Report message to a moderator
|
|
|
|
Re: Issues with OpenGL [message #49353 is a reply to message #49351] |
Tue, 30 January 2018 18:24 |
|
mirek
Messages: 14105 Registered: November 2005
|
Ultimate Member |
|
|
cbpporter wrote on Tue, 30 January 2018 15:41Here is a problem I'm having: sometimes, the apps that TheIDE launches for debugging remain hung up.
This is an ancient issue, at least 3 years old, but in the past it happened incredibly rarely, like single digit times/a year.
Now it happens between 2-3 times a week up to 5-6 times a day.
The executable becomes impossible to write to and I can't close it at all, even with End process tree from task manager. I used to have to restart Windows to fix it.
But now I found a solution. Close TheIDE, delete the file and restart TheIDE. The delete might be optional.
So TheIDE must be keeping my application "closed" but still loaded in memory.
Anybody else having this problem?
Maybe we should add a check to TheIDE: if it thinks that the application is closed, maybe it should go over the process tree and if the application is found, give a message? At least for debugging this hang up?
a) this is not really related to opengl, right?
b) you should specify the host platform and compiler
Anyway, I suppose its Windows and MSC.
I have to say this is long term issue which I have problems with too - I think this happens when you start pdb debugger and then stop debugging (Shift+F5). Workaround is to restart theide (no need to delete the file).
The problem is likely that I have not figured out how to kill debugged process correctly in all cases. The critical part of code is in void Pdb::Stop(), it is really only a couple of lines, so maybe if anybody could look into it and fix this, it would be great.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Nov 01 01:17:43 CET 2024
Total time taken to generate the page: 0.02904 seconds
|
|
|