MantisBT - Community
View Issue Details
0029753Community[OCCT] OCCT:Visualizationpublic2018-05-11 03:502019-09-04 15:43
Vico Liang 
[OCCT] 7.5.0* 
0029753: Visualization - Virtual Aspect_Window should also consider position(x, y) besides size (length, width)
To reproduce this issue, we use class AndroidQt_Window in sample AndroidQt, and call method SetVirtual(Standard_True) to make it a Virtual window. and also the position(x,y) and size(width, height) are set to make the virtual window centered on the screen device, e.g. the width = screenWidth/2, height = screenHeight/2. But the result is that the rendering area is not obey the virtual windows. it start location is still on the left-lower corner, its width and height do obey the rules but it doesn't consider the position inside virtual window. so i think it might be a bug of TKOpenGL.
No tags attached.
Issue History
2018-05-11 03:50Vico LiangNew Issue
2018-05-11 03:50Vico LiangAssigned To => kgv
2018-05-11 09:53kgvNote Added: 0075936
2018-05-11 09:54kgvNote Edited: 0075936bug_revision_view_page.php?bugnote_id=75936#r19057
2018-05-11 10:30kgvSeverityminor => feature
2018-05-11 10:30kgvSummaryVirtual Aspect_Window should also consider position(x, y) besides size (length, width) => Visualization - Virtual Aspect_Window should also consider position(x, y) besides size (length, width)
2018-05-12 09:38Vico LiangNote Added: 0075948
2019-01-07 10:19mahaidongNote Added: 0081683
2019-09-04 15:43abvTarget Version7.4.0 => 7.5.0*

2018-05-11 09:53   
(edited on: 2018-05-11 09:54)
What you are looking for is an option defining a sub-region within a window viewport. Aspect_Window defines two properties - window size and position on the screen, but both properties are designed to reflect window placement on the screen, and rendering viewport is just expected to cover entire window.

Therefore, existing window placement API cannot be used to specify a window sub-region, because in general case both should be considered - new API should be introduced instead.

Implementation should consider the following issues:
- Introduction of a new API defining a viewport (x, y offset and width, height) within window.
- Updating OpenGl to restrict rendering into specified viewport (e.g. use glViewport() with non-zero offset, handle projection matrix properly, handle tiled rendering properly, handle transformation persistence properly, handle sized of off-screen frame buffers, etc.) and V3d/AIS (to compute proper aspect ratio for Graphic3d_Camera, handle MoveTo/Select properly).
- Define and implement a strategy for clearing the full window viewport (e.g. handling regions outside View viewport) and for rendering multiple Views within single Window.

As you can see, this is not that trivial, as it may look at first glance - there are a lot of details to be considered just at TKOpenGl level even in the simplest case.

Vico Liang   
2018-05-12 09:38   
Dear kgv, thank you for detailed analyzing, you're right, it's not a trivial task. it's really a cool feature in my opinion though its priority may not be high.
2019-01-07 10:19   
It will be very cool if the API also provide some simple GUI for the rest area such as menu,buttons