20,741
edits
Canvas widgets: Difference between revisions
Jump to navigation
Jump to search
→Reimplementing CanvasWindow without PUI dependency using osgGA (in progress) {{Pending}}
| Line 197: | Line 197: | ||
{{Progressbar|50}} | {{Progressbar|50}} | ||
* The major thing is we need to switch away from the CanvasWidget approach we are using now - I.e we need a C++ dialog implementation that wraps a canvas and has /no/ PUI dependency at all. (As you already started discussing) Actually that code is going to look quite similar to the osgWidget base class {{Done}} | * <del>The major thing is we need to switch away from the CanvasWidget approach we are using now - I.e we need a C++ dialog implementation that wraps a canvas and has /no/ PUI dependency at all. (As you already started discussing) Actually that code is going to look quite similar to the osgWidget base class</del> {{Done}} | ||
* That will get rid of the legacy (GLUT based) mouse event API that PUI uses, and mean we can support any mouse event supported by osgGA and osgViewer - mouse wheel, buttons and mouse-over. {{Pending}} | * That will get rid of the legacy (GLUT based) mouse event API that PUI uses, and mean we can support any mouse event supported by osgGA and osgViewer - mouse wheel, buttons and mouse-over. {{Pending}} | ||
* Basically we only need to pass mouse/keyboard events and handle dragging/resizing and input focus/stacking order of multiple dialogs. {{Pending}} | * Basically we only need to pass mouse/keyboard events and handle dragging/resizing and input focus/stacking order of multiple dialogs. {{Pending}} | ||
* This is certainly where things need to start, then. I'd hope dragging and resizing can be mostly handled by the Nasal layer, the C++ only needs to keep the window and canvas texture in sync when a resize happens. | * This is certainly where things need to start, then. I'd hope dragging and resizing can be mostly handled by the Nasal layer, the C++ only needs to keep the window and canvas texture in sync when a resize happens. | ||
* We should consider the way osgWidget gets events from osgGA as the 'correct' way. We want to be passing osgGA events around, not raw x,y values, and pretty much all of fg_os.hxx dates from support GLUT and OSG in a single codebase - which forces us to use a very crude API. If we use the real OSG events we get lots of information about button index, event type and modifier state all encapsulated in a clean way. {{Done}} | * <del>We should consider the way osgWidget gets events from osgGA as the 'correct' way. We want to be passing osgGA events around, not raw x,y values, and pretty much all of fg_os.hxx dates from support GLUT and OSG in a single codebase - which forces us to use a very crude API. If we use the real OSG events we get lots of information about button index, event type and modifier state all encapsulated in a clean way.</del> {{Done}} | ||
* On a different note: window management. I've seen that in Tom's private branch, he has started on a window class (albeit, it is just a skeleton currently). I think we indeed want a c++ window manager, which is basically just a dumb "visible thing that renders a texture". That way, the canvas code only has to render stuff to a texture and expose that, which is a nice abstraction point. {{Pending}} | * On a different note: window management. I've seen that in Tom's private branch, he has started on a window class (albeit, it is just a skeleton currently). I think we indeed want a c++ window manager, which is basically just a dumb "visible thing that renders a texture". That way, the canvas code only has to render stuff to a texture and expose that, which is a nice abstraction point. {{Pending}} | ||
* Agreed - I was planning to dive into adapting the window on Tom's branch, with a C++ host for a canvas. Note that the canvas currently assumes render-to-texture, but for the GUI I'm not sure that's actually desirable - simply a separate camera per GUI window may be sufficient. Since the camera already arranges everything beneath the RTT camera this should be fairly minor change, if it's desirable. (Saves some memory, makes re-sizing GUI windows a little easier, might make clipping or other state management less efficient in the main GUI camera ... but probably not) {{Pending}} | * Agreed - I was planning to dive into adapting the window on Tom's branch, with a C++ host for a canvas. Note that the canvas currently assumes render-to-texture, but for the GUI I'm not sure that's actually desirable - simply a separate camera per GUI window may be sufficient. Since the camera already arranges everything beneath the RTT camera this should be fairly minor change, if it's desirable. (Saves some memory, makes re-sizing GUI windows a little easier, might make clipping or other state management less efficient in the main GUI camera ... but probably not) {{Pending}} | ||
| Line 207: | Line 207: | ||
* It should probably event be enough to use just one single camera for all windows. The big advantage we gain with render-to-texture is that by using a larger texture we can get better anti-aliasing. For rendering paths the stencil buffer is used so we only have pixel resolution which can be seen at non horizontal or vertical lines or curves. | * It should probably event be enough to use just one single camera for all windows. The big advantage we gain with render-to-texture is that by using a larger texture we can get better anti-aliasing. For rendering paths the stencil buffer is used so we only have pixel resolution which can be seen at non horizontal or vertical lines or curves. | ||
* We could also use lazy rendering to only update the GUI texture if something changes. Normally dialogs should be pretty much static... {{Pending}} | * We could also use lazy rendering to only update the GUI texture if something changes. Normally dialogs should be pretty much static... {{Pending}} | ||
* The current window manager registers itself to the main viewer and subscribes on osgGA events, so the canvas has no dependencies on the old system. {{Done}} | * <del>The current window manager registers itself to the main viewer and subscribes on osgGA events, so the canvas has no dependencies on the old system.</del> {{Done}} | ||
* What do you think about the current way of handling mouse events? It's also just passing x/y and some more values to the property tree, but we need to forward the values somehow. | * What do you think about the current way of handling mouse events? It's also just passing x/y and some more values to the property tree, but we need to forward the values somehow. | ||
* Also I had to create a new event class (which uses most of the osgGA types) because the coordinates of the mouse where passed in the range [-1,1] which would make handling a bit more complicated... | * <del>Also I had to create a new event class (which uses most of the osgGA types) because the coordinates of the mouse where passed in the range [-1,1] which would make handling a bit more complicated...</del> | ||
=== Nasal requirements {{Feedback}} === | === Nasal requirements {{Feedback}} === | ||