On Fri, Sep 12, 2014 at 12:00 AM, Clifford Yapp <cliffy...@gmail.com> wrote: > On Sun, Sep 7, 2014 at 5:28 PM, Vlad Bogolin <vladbogo...@gmail.com> wrote: >> >> The option b sounds really interesting to me so I will focus in the next >> days on finding out more details and start making a plan. >> >> Cheers, >> Vlad > > Vlad, > > Just a heads up - I definitely broke the Qt embedded framebuffer with > my latest updates - I'm working on updating the code to the new > approach, but I'm not quite there yet.
Vlad, I've got things mostly working again as of 62710. The embedded framebuffer doesn't want to linger in MGED, which IIRC is a problem you experienced earlier and found a workaround for, but looking at how it's working (or not working) both pre and post refactor I think we may want to reconsider how that's being handled anyway. At least here, the overlay/underlay mechanism for the embedded framebuffer only worked after the raytrace was complete, not during the raytrace - that's not consistent with the other dm implementations. Could we improve the overall behavior generally by doing 2 things: 1. Add a libdm level function mechanism to show/hide the framebuffer in the display manager - since the dm is providing a built-in framebuffer now, I think it makes sense to push the management logic for that out of MGED and further down. For Qt, it also lets us do whatever makes sense without involving MGED. 2. At the Qt level, have two drawing images or "layers" - one for the display manager wireframes (and eventually polygons) and the other for the framebuffer image. Based on the visibility settings, those two images would be composited (or not, as the case may be) in the appropriate fashion into a final, "rendered" image which is what would be presented to the application. That way, whatever is needed to do the "update raytrace as it happens but stay in underlay at the same time" process in Qt can be done behind the scenes and all MGED has to do is provide the appropriate number to dm_set_fb_visible. Does that sound like it would work? Cheers, CY ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
