Closed bakercp closed 11 years ago
Is there currently a way to make it not transparent?
I sort of like the option. For example, looks cool with the default raspbian background in my test: http://www.youtube.com/watch?v=Ah83YCIzuu8&feature=g-crec
But I would definitely like a way to make it NOT transparent. Even calling ofBackground() doesn't seem to do the trick.
Indeed -- "somewhere between a feature and a bug". Does the raspberrypi_hello_world cover over your background? We should be able to set a "glClear" color that is opaque. A workaround would be to draw a full-screen rect ... perhaps you could do a little more testing to help figure out a best approach to this?
So the alpha of the window is set at the time of window creation. It looks as though we won't be able to have runtime control of this without calling setupRPiNativeWindow. I think that this is just how openFrameworks is built. For example calling background(color, alpha) doesn't change when alpha changes. (on raspi and ubuntu.)
To my limited knowledge, this means we can either
Any thoughts/ preferences? Thanks
Nice research. I'm in favor of leaving the option available in some way. In my mind, ideally the examples should look the same on all platforms, so the "default" behavior in my opinion should mirror the normal opaque OF window.
This could be at construction when we specify a specific kind of window (i.e. ofAppNoWindow
, ofAppGlutWindow
, etc)
e.g.
#include "testApp.h"
#include "ofAppEGLWindow.h"
//--------------------------------------------------------------
int main(){
ofAppEGLWindow window(eglWindowSetttings); // create a transparent window ...
ofSetupOpenGL(&window, 1024, 768, OF_WINDOW);
ofRunApp(new testApp()); // start the app
}
In this case, we could define some small struct like `ofEGLWindowSettings
that could optionally be used during initial construction.
It would could include all sorts of stuff, like use x11 or not, transparency, and all of the info info presented in the EGLint attribute_list
to be passed to eglChooseConfig
, etc.
I'm working on a little overhaul of ofAppEGLWindow
as I write this, so if you have some ideas for how to set up this new default setting, let me know and I'll add it in.
Sure. Settings sounds like a good idea. Have a bunch of defaults so you just have to change what you want.
ofEGLWindowSettings could look something like this:
{
.
bool isTransparent; //For fully or not
or
float windowAlpha: //For more control
.
}
Then in setupRpiNativeWindow, make it look something like
.
//new Code
VC_DISPMANX_ALPHA_T alpha;
alpha.flags = DISPMANX_FLAGS_ALPHA_FIXED_ALL_PIXELS;
alpha.opacity = mOfEGLWindowSettings.windowAlpha; // From new struct
alpha.mask = 0;
dispman_display = vc_dispmanx_display_open( 0 /* LCD */);
dispman_update = vc_dispmanx_update_start( 0 );
//Small change to this line:
dispman_element = vc_dispmanx_element_add ( dispman_update,
dispman_display,
0/*layer*/,
&dst_rect,
0/*src*/,
&src_rect,
DISPMANX_PROTECTION_NONE,
&alpha,
0/*clamp*/,
(DISPMANX_TRANSFORM_T)0/*transform*/
);
.//^^Adds &alpha parameter where it was just 0 before.
.
Do you know off hand what range VC_DISPMANX_ALPHA_T
uses for it's opacity
value? 0-1 or 0-255?
Sorry, I should have looked before I asked :) looks like 0-255. A discussion here:
http://www.raspberrypi.org/phpBB3/viewtopic.php?t=8826&p=104718
btw, if you want to check it out, here is where I've added your updates.
https://github.com/bakercp/openFrameworks/tree/feature-nox11-keyboard/libs/openFrameworks/app
I'm going to continue working on this one to add keyboard stuff, settings, etc. Am taking a break for the moment though.
Basic default support for this is now in develop-raspberrypi
. Configurable support is next.
Initial support added with 56bd57f012162c75aead9fffdc446e0519ef8839. Example added with 9a6518f05ef93f860dd19221087fdeb12b941f6c
Testing needed folks :)
Currently, if the window does not take up the full screen, or the app has transparent sections, the fb underneath (usually console stuff), can be seen through the app. It's great to have that flexibility, but I'm wondering if there is a better way to do this?
Perhaps we always create an a fullScreen EGLWindow and move our "render" window around on the FullScreen EGL surface?