Remaining bugs in the Juce Demo


#1

Well, it’s always a PITA to maintain a todo list with bad news, but I’m doing a post to list the bugs in the Juce demo.
When using Windows “Use OpenGL renderer”

  • When switching the renderer, the windows’s inner border and menu are being overlaid by the last content of the component. A resize of the main window fix this.
  • Drop shadow around menus are flickering like crazy
  • The colour chooser component flicker like crazy too, up to being never drawn on the screen at any time
  • There is some 1px issue in the drawing of background tab header components (like if it’s was missing to draw 1 pixel). If you over the mouse, sometimes it fixes it, sometimes it doesn’t (see attachment)
  • In the OpenGL demo component, there is sometimes some “pink texture flash”, it stays for a single frame, where one texture of the cube becomes plain pink/blue. I wonder if there is some OpenGL error that is being ignored ?
  • (Minor) There is flickering in the OpenGL demo (probably need to call glSetSwapInterval() ?)
  • Sometimes, it quite rare but it happens, when going from the Rendering demo with OpenGL renderer selected to the OpenGL demo, the Juce demo crash, and stack show that the message thread is either killing the OpenGL rendering thread by force (in that case, the OpenGL thread is in a “purecall()” and the frame above seems to be “renderOpenGL()”), either it’s crashing because the main thread has deleted the OpenGL component, yet the OpenGL thread is struck in a Pimpl destructor trying to double free something).
    [color=#808080]- No shadow anymore in the text boxes (but that might be fixed soon as it’s reported on the forum).[/color]

see the effect:
[attachment=0]juceBug.PNG[/attachment]


#2

Thanks - I think a lot of this may be driver-specific, as I’ve not seen all of these symptoms myself. I am aware of a few of them though, and will investigate asap!

(The textbox shadow is fixed, BTW, it wasn’t an openGL issue at all, just a silly mistake I’d made in the bevel code).


#3

On Mac (so probably not a driver issue)

Go to the Widgets Demo
Select misc widgets
and change the rotation to 2.0 degree

The floating circle in the box draw have a white line that follow them which stay on the display.


#4

Thanks, just looks like an accuracy error… I’ll track it down…


#5

Regarding the OpenGL renderer, would it be possible in the future for it to be as transparent as other renderer regarding its use and interchangeability with other renderer ?

So far the Juce Demo does custom thing to enables it.

Thanks,


#6

I think the way it is currently is good. You should allow your user to change the renderer if the OpenGL one does “strange” things, having it selected by default seems to me a can of worm.


#7

This is not what I’m saying.
It’s just that currently the switch from standard renderer to an opengl renderer is not as trivial as it is from software to CG on mac.


#8

Yeah, it’s far more difficult to swap to the GL renderer than the CG/software renderers, because they don’t involve any changes to the window itself. But as everything progresses, I’ll see what I can do. For the moment I only really foresee people using the GL renderer when they want to mix 3D and 2D elements.


#9

oki doki.

IMHO OpenGL rendering is very interesting for its performance boost in 2D as well.

The previous UI toolkit that I was using is based natively on it. (libnui.net
The issues were mainly driver related and differences of support between cards but with time things are getting better.

On OSX this is now quite stable and on Windows, maybe the right move would be to have a Direct2D renderer (of course since Vista or 7)


#10

Hmm. I’m starting to think that if the GL stuff works well enough, I might just use that on Windows instead of adding yet another graphics library to support.


#11

I hope you’ll reconsider.
Per the latest information coming out of Microsoft, OpenGL won’t be supported in Windows 8 Metro apps and only Metro apps will run on Windows 8 ARM. I am pretty sure the only way for Juce apps to work on Windows 8 ARM is for you to finish the Direct2D renderer.

Edit: And if you want even more reasons, it was just leaked today that the next Windows Phone OS (Windows Phone 8 ) will be based off the Windows 8 kernel and may run metro apps as well. This jives with the recent info that C++ is coming to Windows Phone. So with Direct2D support you should be able to create Metro Juce Apps that work on Windows 8 x86/x64/ARM and Windows Phone 8.


#12

As usual, I doubt Microsoft will drop OpenGL. They already said this for Vista, windows 7 and now Windows 8. Each time, the industry using Windows for their CAD software (Autodesk, Maya, Photoshop, etc…) need OpenGL, and they will not do anything specific for Microsoft. Microsoft can’t afford loosing that market share (you know, the “it runs software made for Windows 98”).
Another issue for Microsoft is that they have to convince developper to port their existing software to their platform (they are paying developper to fill the WP7 store). The biggest players already use OpenGL (since it’s the GCD between iOS and Android) and I really doubt they’ll rewrite their software for whatever price Microsoft would be giving them).
And finally, the ARM vendors (Texas Instrument, NVidia, Qualcomm, Samsung) all provide OpenGL ES drivers. I’m not sure Microsoft is able to fund all these vendors to develop Direct3D drivers, so either they’ll have to limit to one or two vendor for their phone & tablet (which I doubt), either they’ll work out some converting software to emulate Direct3D over OpenGL.

Anyway, OpenGL is not in the state it was 4 years ago (where Direct3D dominated), I’d say that it’s now the standard. Let’s see if my bet will be followed.


#13

Sorry i which i could but i cannot agree, all OpenGL stuff (also the GUI rendering stuff) is very very unstable on both windows systems Vista 32/64 since 2-3 month.


#14

Yeah, but I’m going to have to make it nice and stable, regardless of whether I use GL as the main rendering engine or not.

It’s just unstable at the moment because as a GL novice, I jumped in and wrote a massive rendering engine in it! Wouldn’t really expect it to be perfect immediately, but it’s getting there.

BTW anyone still having problems in OSX after my last check-in? I think it was otristan who had reported the bugs I fixed.


#15

One last bug that I just have discovered
Open the Juce Demo, switch to OpenGL Renderer, then click use native window title bar, assert/crash

Regarding the rendering, I have an issue which now only happen in the debug version
See attachement.

No glitch in Release version.

Otherwise rendering is now perfectly fine on OSX.(10.7.3)