MantisBT - Open CASCADE
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0032206||Open CASCADE||[OCCT] OCCT:Visualization||public||2021-03-14 11:11||2021-04-03 12:52|
|Assigned To||bugmaster|| |
|Priority||normal||Severity||integration request|| |
|Product Version|| |
|Target Version||[OCCT] 7.6.0*||Fixed in Version|| |
|Test case number||Not required|
|Summary||0032206: Visualization, TKOpenGl - move out OpenGL ES support to dedicated library TKOpenGles|
|Description||Currently TKOpenGl can be built either in OpenGL (desktop) and OpenGL ES modes.|
This has a rationale - both share majority of source code and most interested target platforms support one of two.
However, some systems provide both OpenGL and OpenGL ES implementations at once.
This includes desktop Linux (Mesa) and Windows (with help of Angle library).
Therefore, it is proposed moving out OpenGL ES support to a dedicated library TKOpenGles to allow both being built at once.
The main objective is improved development and testing environment - so that changes in common code could be tested within a single build.
Applications will able to choose which library to use, though obviously full-featured desktop OpenGL should be always preferred when both implementations are available.
But some trickery applications would be able to select library at startup (for instance, when OpenGL drivers are unavailable on Windows, while Direct3D driver available and could be used by Angle).
The simplest way to support TKOpenGl + TKOpenGles configuration is reusing existing source code and just building two libraries with different compiler and linker flags.
In this case, both libraries will export the so-named classes of OpenGl package, but this should be fine as both libraries shouldn't be loaded at once anyway.
This is what this first patch is supposed to implement.
The next steps could be aimed on improving package structure.
One approach could be using macros to rename OpenGl_ classes to OpenGles_ within TKOpenGles library.
This, however, would require a considerable and not nice-looking code modifications across the whole package.
Another approach would be moving out the common code into a dedicated base library TKOpenGlBase.
Within this approach OpenGl_GlFunctions function table should be filled with both OpenGL ES and OpenGL functions at once.
This might be challenging, as it would require solving name collisions between glext.h, OpenGl_GLESExtensions.hxx and system-provided headers of OpenGL and OpenGL ES implementations.
OpenGl_Context sub-classes will be responsible for filling in this function tables from OpenGL or OpenGL ES implementations.
The drawback of this solution would be code paths practically unreachable for TKOpenGles (this should be relatively small amounts of code, mostly FFP-compatibility related), and some extra branching at runtime.
But in result packages structure would look cleaner, so that OpenGL-related code at application side or in extra packages can be build without direct dependency from system OpenGL libraries, and export unified OpenGL/OpenGL ES implementation without duplicating toolkits.
|Steps To Reproduce|
and documentation updates
|Tags||No tags attached.|
|parent of ||0032242||verified ||bugmaster ||Configuration, CMake - USE_GLES2 option does not appear in interactive configurator |
|related to ||0032207||verified ||bugmaster ||Draw Harness, ViewerTest - explicitly close 3D Viewer windows at Tcl interpreter closure |
|related to ||0032208||verified ||bugmaster ||Tests - refactor visualization tests to cover several graphic drivers |
|2021-03-14 11:11||kgv||New Issue|
|2021-03-14 11:11||kgv||Assigned To|| => kgv|
|2021-03-14 11:30||kgv||Relationship added||related to 0032207|
|2021-03-14 11:34||kgv||Relationship added||related to 0032208|
|2021-03-18 09:09||kgv||Note Added: 0099566|
|2021-03-18 09:09||kgv||Assigned To||kgv => osa|
|2021-03-18 09:09||kgv||Status||new => resolved|
|2021-03-18 10:32||osa||Note Added: 0099567|
|2021-03-18 10:32||osa||Assigned To||osa => bugmaster|
|2021-03-18 10:32||osa||Status||resolved => reviewed|
|2021-03-20 12:50||bugmaster||Note Added: 0099618|
|2021-03-20 12:50||bugmaster||Status||reviewed => tested|
|2021-03-20 13:00||bugmaster||Test case number|| => Not required|
|2021-03-23 21:46||bugmaster||Changeset attached|| => occt master b8ef513c|
|2021-03-23 21:46||bugmaster||Status||tested => verified|
|2021-03-23 21:46||bugmaster||Resolution||open => fixed|
|2021-03-24 00:31||kgv||Relationship added||parent of 0032242|
Patch is ready for review
- OCCT: branch CR32206;
- OCC Products: branch CR32206.
Patches were reviewed without remarks
OCCT branch : IR-2021-03-19
master SHA - d209b3176e21010e096833052698f1c0da5b04d5
Products branch : IR-2021-03-19 SHA - 6baf3a921c29525981c0ad7881214c9b20ffe3c1
was compiled on Linux, MacOS and Windows platforms and tested in optimize mode.
Number of compiler warnings:
No new/fixed warnings
Total CPU difference: 17753.85000000016 / 17750.250000000156 [+0.02%]
Total CPU difference: 11481.660000000102 / 11540.5800000001 [-0.51%]
Total CPU difference: 19361.09375 / 19341.28125 [+0.10%]
Total CPU difference: 12879.75 / 12869.921875 [+0.08%]
Image differences :
No differences that require special attention
Memory differences :
No differences that require special attention