Am 26.10.2012 um 11:13 schrieb [email protected]: > Quoting Max <[email protected]>: >> So i tried this for Pd and found that it is not affecting the graphics card >> switch until the moment you are loading Gem. So if you are patching with Gem >> loaded even without the window open the discreete card is used. > > i think the logic behind automatically disabling the internal gfx-card is > very simple: as soon as an application loads the libGL dylib, power-save mode > is deactivated. > if no application references libGL anymore, powersave mode is disabled. > > now Gem is dynamically linked against libGL, which means that libGL is loaded > as soon as Gem is loaded (opera is probably linked against libGL too, so as > soon as you start opera, power-save mode is disabled). > deferring the loading of libGL until Gem is used, might turn out to be quite > tricky (note to myself: though it really might be possible, given that Gem > uses glew to wrap around GL).
i've asked the programmer of gfxcardstatus, cody krieger, if that is how it works, and he replied: > That's not quite right, but it's close. > > It's not linking against any particular library or framework that's the issue > - it's when you actually use anything OpenGL-related in practice. For > example, as soon as you lay down a CALayer in a Cocoa application, the > discrete GPU will power up in 10.7 and below (because CALayers are > OpenGL-backed). In 10.8, this behavior changed a little, and just using > CALayers (or anything from Core Animation) will no longer cause the discrete > GPU to turn on, but direct use of OpenGL, among other things, will. > > Hope that helps! :) > > Cody so IOhannes, it's not something what's particularly bugging me or what I find über important. It's a mere observation which I wanted to share. max _______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
