Ok, I finally vote a +1 on Mike's proposal in order to make now a clear decision is made on that point (mike's approach vote majority) and also because thinking about it twice : i think it's the simplest (yet powerful) approach to generic surface handling permitting not to change too much existing widget architecture (like the underlying & complex symbol architecture) and so we can expect not a lot of regression as well which is an important point too ...
As A first increment, I propose to implement the Surface -- Offscreen part of the architecture as we need that one urgently and so that we can *Finally* remove Image::make_current as it was planned. Fabien > Rendering surfaces development plan (for FLTK 2.0.x ) > > ========================= > 1. Bill Proposal > ========================= > A class hierarchy for Bill proposal could be : > ============================================ > Symbol > | > ---- Surface > | | > . ------- OffscreenSurface (all platforms) > . | > . ------- PrintSurface > | > ------- GLSurface > | > -------- ... (any other surface that could be rendered ) > .. > ================ > 3. Mike Proposal > ================ > For 2.0 timeframe I'd like to see something like: > > Surface > Window > Offscreen > Page (+ PrintJob class as a parent) > > where "Surface" handles all of the OS-specific drawing stuff and > Window and Offscreen handle the OS-specific creation stuff. The > Window class (and all widgets) will still use the OS-specific input > (event) stuff, and the only application-visible change is that the > off-screen (and printing) surfaces are now first-class citizens > instead of being buried. It is certainly possible for Window, > Offscreen, and Page to not be subclassed from Surface but instead > just create an appropriate instance for the application - that > might make implementation simpler and allow for more > experimentation. > .. ==================================================================================== > Please Vote for +1,0, -1 for proposal (1) AND for proposal (2) > and feel free to eventually suggest other directions > > (Vote expiration : two weeks from today seems a quite reasonable suggestion) > ==================================================================================== > > Thanks ! > > _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
