#16841 closed enhancement (invalid)
Provide BDirectGLWindow functionality
Reported by: | cocobean | Owned by: | kallisti5 |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Kits/OpenGL Kit | Version: | R1/Development |
Keywords: | BDirectGLWindow | Cc: | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
Provide BDirectGLWindow functionality. Haiku lacks DirectGLWindow.h which provides the BDirectGLWindow class and a newer locking model (i.e. MakeCurrent()/ReleaseCurrent()/YieldCurrent()) presented in BeOS 5.0.
Ref: https://www.haiku-os.org/legacy-docs/benewsletter/Issue5-13.html#Engineering5-13
Benefits: "The latest changes dramatically improve both performance and stability with (i.e. video - 3D computer graphics (OpenGL)) hardware acceleration. The triangle throughput and texture upload speeds have been greatly enhanced and multitexture support has been added. Device enumeration now allows the application to properly determine if it is using a full screen device, eliminating the annoying problem of apps taking over the entire screen."
Change History (8)
comment:1 by , 4 years ago
comment:2 by , 4 years ago
Is it used by existing BeOS software? If not, it is probably better to design new API that is compatible with OpenGL and Vulkan. Special fullscreen API is obsolete nowadays.
comment:3 by , 4 years ago
@X512 - The work was unfinished for the BEOS 5.0.x releases. I think this functionality request was modernized for Haiku through the new DirectWindow class (https://github.com/haiku/haiku/commit/d9cebac2b77547b7064f22497514eecd2d047160). This includes some locking model (i.e. (_LockDirect/_UnlockDirect)) - but need to review further.
Note this info:
// Unimplemented in (BeOS) R5. // This function is probably here because they wanted, in a future time, // to implement graphic acceleration within BDirectWindow // (in fact, there is also a BDirectDriver member in BDirectWindow, // though it's not used).
comment:4 by , 4 years ago
BDirectWindow class should be considered obsolete and not used because modern graphics hardware do not work in this way (this is something like obsolete DirectDraw) and correct mouse cursor implementation is not possible when hardware cursor is not available. Hardware acceleration should work with BGLView inside regular BWindow.
comment:5 by , 4 years ago
Ok. I'll reference your BGLView/BWindow work here for SDL: https://github.com/X547/haikuports/commit/729dd67541c00d9e022206239e5baa479b7e0787
We can close this ticket and review enhancement for a newer API task as suggested.
comment:6 by , 4 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Closing as invalid because we don't plan to provide support for things that were not in BeOS 5.0.3.
Note that this API was available in Zeta and used in some software released for it. However, we can make something better and more adapted to modern 3D acceleration needs.
comment:7 by , 4 years ago
Correction trivia: BDirectWindow was in BeOS 5. Be demonstrated the BDirectWindow class using slightly modified 3Dlife and GLTeapot apps - to show off 3D hardware acceleration using the 3dfx Voodoo2 video card. A Be engioneer (i.e. M. Ryon) mentions achieving 200 FPS (versus 40 FPS) with GLTeapot using BDirectWindow/DirectMode versus previous BeOS 4.x methods.
comment:8 by , 4 years ago
BDirectWindow is different from BDirectGLWindow.
What it does is allow application to draw directly to the frontbuffer (video card memory). It was available in BeOS R5, and the OpenGL implementation in BeOS and in Haiku can make use of it already.
In fact our GLTeapot implementation uses it: https://git.haiku-os.org/haiku/tree/src/apps/glteapot/TeapotWindow.cpp#n22
This is in reference to the specific Be Newsletter article: "Issue 5-13, March 29, 2000 Be Engineering Insights: The World of OpenGL® After BeOS 5".