Hi Robert,
>> My inclination is that GraphicsContext::Traits should just be for
>> pbuffer and graphics window creation, not for control of screen
>> properties such as screen resolution, depth or refresh rate. Such
>> parameters should probably go into the WindowSystemInterface such as a
>> setScreenResolution, setScreenRefreshRate to compliment the existing
>> getScreenResolution, getNumScreens etc.
>>
>> I'm also thinking about putting WindowSystemInterface out into a
>> seperate header rather than being part of the GraphicsContext class.
>> I'll notify everybody if/when I make this change.
>
> OK I'm currently look to add these methods to
> WindowingSystemInterface, currently they look like:
>
> virtual bool setScreenResolution(const ScreenIdentifier&
>/*screenIdentifier*/, unsigned int /*width*/, unsigned int /*height*/)
> { return false; }
>
> virtual bool setScreenRefreshRate(const ScreenIdentifier&
> /*screenIdentifier*/, double /*refreshRate*/) { return false; }
> Note the default return of false indificating the action has taken no
> effect. I am wondering about if we need to add an extra uint depth
> parameter to the setScreenResolution. I am not familiar with API's
> for change a screens resolution so need to defer to others for
> guidance, but I presume we'll need more than just width and height to
> set up the screen.
>
> Thoughts?
> Robert.
How about going with a Screen::Traits structure and having
WindowSystemInterface::setScreenProperties/Attributes/Traits(traits);
That would be symmetric with the way you are defining graphics windows and
would use the same update protocol (0 value or some other
default-constructed value for fields whose trait is not being changed). It
would allow the back-end to do updates one at a time or many at once
depending on the available display management system services.
On Windows, many functions such as setting screen resolution, refresh rate,
etc. take place within one function call (ChangeDisplaySettings() ). For
users familiar with Win32, this is the function call that is causing the
screen to flash briefly when called (having all screen settings take place
within the same call would have the benefit of reducing this effect on
Windows; I don't know if it would be the same on Linux).
FYI, here are the other fields present on Windows:
dmBitsPerPel -> depth
dmPelsWidth -> resolution in x
dmPelsHeight -> resolution in y
dmDisplayFlags -> which fields we are changing in the call (bitmask)
dmDisplayFrequency
dmPosition -> position of the display device in the virtual
screen (aggregation of all display devices).
André
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
