Yes, I am also seeing the OpenGLSurface refresh issue when running the tutorial001.xojo_binary_project on Xojo 2018r1 on my Windows Book I machine with Windows 10.
I also use Windows 10 and as you say, your example (the one that is in the Feedback) doesn’t work in 2018r1.1 but it works on 2017r3.
However, my application that uses OpenGLSurface extensively works normally in 2018r1.1
So something happens, but I have no idea what it is.
It appears that the refresh code is somehow being called twice. When I add a msgbox test at the end of the glend command, starting the program shows the message box twice.
I’ve discovered something:
When the application starts it draws the OpenGLSurface but deletes it immediately, but if I pay attention I can see something.
Then if you Render again it works normally.
In your example I created an event on the OpenGLSurface:
Function MouseDown(x as Integer, y as Integer) As Boolean
me.Render
End Function
and when you click on the window the triangle is drawn.
So, the problem is: Why the OpenGLSurface is deleted the first time?
It looks like the problem has something to do with trying to call Surface.Render from the Window.Paint event. I suspect something changed in Xojo 2018r1 causing this behaviour?
Alwyn, In fact I think the problem is related with trying to draw from the open event (first paint event).
I made a test and it works.
I’ve created a method
Sub draw()
Surface.Render ' refresh the OpenGL surface
End Sub
and substituted your line in paint event:
It takes 0.5 second but now it works. I have not checked how small the time can be, but probably it can be much less than 500.
And more about it. I must thank you because with this issue I’ve discovered what happened to my application: I had noticed that after some past releases (may be one year or more) I had a problem with the first rendering in my OpenGLSurface. I though it was some problem with my code that had been modified, but I paid no attention because with a single click on the window it was rendered again. Now, I can imagine that this is something related with this issue.
Not stupid at all. In many cases a Calllater with a latency of 0 is the most elegant way to decouple things, like when you want to update the GUI from within a thread or when you want to separate a method call from the event handler where it is triggered.
A timer with a 0 delay does not mean your code is interrupted and the timer action event will fire immediately. It is rather a request to the system to perform the timer code as soon as possible. Thats why it can be useful to invoke an app.YieldToNextThread in a thread after calling a GUI update via timer because by default the thread will yield at the next loop end. Which, depending on your code, could cause an unwanted delay.
I am still not getting the Xojo3D.com ‘tutorial011’ running in all circumstances. I have implemented @Ramon SASTRE 's Xojo.Core.Timer.CallLater(500, AddressOf draw) suggestion above.
On the latest 2018r1.1, latest macOS and latest Windows 10, I am trying to run this tutorial but I get the following results.
With HiDPI turned on:
Both macOS/Windows 32-bit and macOS 64-bit gives a NilObjectException error in the Constructor of X3Texture since, while texture exists, it cannot get the Mask property:
Windows Windows 64-bit fails with the error below, NilObjectException error in X3_RenderModel as the model object is nil
With HiDPI turned off:
Runs OK with macOS 32/64-bit
Runs OK with Windows 32-bit
Runs OK with Windows 64-bit gives a NilObjectException error in X3_RenderModel as the model object is nil:
Any clues on how to get 3D cube rendering with HiDPI on across macOS and Windows with both 32/64-bit?