Is there anyone who would be willing to offer our expertise in QWindow, QOpenGLContext, QBackingStore, QPainter, etc.? I'm especially interested in avoiding pitfalls we've learned and how to ensure that what gets done in the standardisation process is acceptable from a retained-mode scene graph perspective.
Depending on the actual dates of the November meeting, I might be able to drive up to Redmond. Or someone could piggy-back after a trip to Dev Days SFO. ---------- Forwarded message ---------- Subject: [graphics] SG13 Chicago Meeting Minutes Date: sábado, 28 de setembro de 2013, 15:49:13 From: jason zink <[email protected]> Para: [email protected] <[email protected]> Hello Graphics Enthusiasts, Attached are my meeting minutes from the Chicago meeting of SG13 this morning. These are my notes, so it is completely possible that I have missed a participant or a discussion topic - please feel free to let me know if something should be changed or updated. Also any questions or comments are welcome! Overall the meeting lasted most of the morning, from 9:30 until lunchtime. There were ~10 participants, and the discussion was very constructive. It was a great start, and I'm looking forward to exploring this library with the rest of you in the near future! >> Jason -- You received this message because you are subscribed to the Google Groups "Graphics" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/a/isocpp.org/group/graphics/. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/graphics/1380408553.47962.YahooMailNeo%40web140504.mail.bf1.yahoo.com. ----------------------------------------- -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Study Group 13 - Chicago 9.28.2013
Participants:
Herb Sutter
Beman Dawes
Jason Zink
Michael McLaughlin
Fabian Fracassi
Oliver Giroux
Daniel Garcia
Pete Becker
Larisse Voufo
Bill Seymour
Meeting begins with a presentation from Beman Dawes:
Objectives, Requirements, and Strategies
Key points from the presentation:
- Our objective should be success, don't end up with a never ending proposal
- Avoid being trampled by the giants in this arena
- Target shipping within 2 years
- Recommends starting with an existing implementation (i.e. Cinder,
OpenFrameworks, or other)
- This builds confidence with an existing framework
- Then all modifications (including wholesale replacement of components) have
to stand on their own
- Examples in this area include:
- OSS: LibreOffice forking from Open Office (familiar starting point)
- STL: Library was added as a whole, then iterated on from there (working
starting point, followed by proposed changes)
- Start with an API surface that is C++03 or better, move towards C++11/14
- Keep all dependencies well hidden in the implementation
- The API should be extensible by third parties (which can also be used for
future additions to the API itself)
- In general, we should meet two challenges with minimal, clean code:
- Beman's challenge: Be capable to open a window, print some text (i.e. Hello
World), and drag it around the screen.
- Herb's challenge: Learn the library and build an interesting app within
half a day (originally posed in Going Native 2013)
Next we moved to an open discussion on the presentation, the intention of SG13,
and other random points from the participants. Here is a summary of the major
topics discussed:
- Discussion of what the library is, and what it isn't.
- We want to make the library simple and accessible to beginners, but also
usable to experts as well (avoid glass ceiling if possible). In general, we
would favor approachability over avoiding the glass ceiling - but it should be
possible to achieve both.
- The implementation from Michael McLaughlin took some inspiration from
Cairo. Throughout the discussion, Cairo came up multiple times and it seems to
be the 2D intersection of several existing C++ graphics libraries
(Cinder/OpenFrameworks)
- GIL within Boost is an example of a library that is out of scope for SG13.
It performs very efficient format handling for image processing, which isn't
our goal.
- General scope from the beginning has been: 2D immediate mode rendering,
some input mechanism for interactivity, some text handling for easy output.
- We want to create a library that allows the user to interact with a
graphics window in interesting ways.
- There is a 2D canvas, that can be used in a number of different ways.
- Window as a canvas, PDF as a canvas, etc...
- Need to find the balance of how to add interactivity appropriately
- Typical systems have drawing at one level, input events at another level,
and the user logic at another level
- Find how to make it easy to use (i.e. Window.OnClick()) but be careful
not to force the paradigm (i.e. PDF.OnClick() may not make sense...)
- Herb proposed starting with Cinder as the basis, based on previous
discussions with both Cinder and OpenFrameworks representatives.
- No objections were raised.
- Discussion of using 'native handles' as a way to provide access to the
underlying implementation.
- Allows looking under the hood, which is good for full control
- However, it is also the gateway to non-portable code!
- The general consensus was to allow the use of native handles, but still
work to make them unnecessary in most cases.
- It is also possible that the native handle can be library specific, meaning
it is worse than non-portable (i.e. non-portable even within platforms...)
- Some general statements and questions:
- We should develop the proposal as we think it should be, not what we think
will be accepted. Don't pre-maturely remove content for political reasons!
- Should we be able to implement a basic HTML renderer?
- General thoughts were that it should be possible, assuming some
implementation help (i.e. for SVG, image file loading)
- Things like SVG rendering should be accessible from a high level in the
API (i.e. point to a file and get a texture back)
- Should we interact with iostreams?
- gout instead of cout?
- <joking>Create a stream manipulator for cout like std::graphics to
configure the stream for graphics output!</joking>
- These questions need to be answered throughout the process, rather than
deciding now.
- Discussion of buttons in v1:
- Should they be in? General response was 'no' for v1.
- Let people build their own, and we can build on that experience for
future revs.
- Input discussion:
- v1 should consider mouse and keyboard events (allowing key up/down or
char events, mouse button up/down, movement, etc...)
- We can lump touch together with mouse for v1 (similar to Cinder's
handling --> Herb's 'Herbscript' sample)
- Discussion of ideas for samples/examples in the proposal:
- Example of how to get our 2D contexts into an OpenGL render target for
game UI (highly expected use case), with D3D as a follow up
- Example for a hello world application (sounded like Beman's challenge)
- Example of visualization of a STL sorting algorithm with minimal lines of
code (should be possible with a good design!)
- Should we include 'offscreen rendering'?
- General consensus was yes, it adds lots of interesting potential to the
library
- Question about if double buffering should be implemented using offscreen
buffers. General consensus was that double buffering should happen behind the
scenes, without user intervention (it is an expected feature in modern systems)
- Discussion about fonts:
- We should support them, but perhaps at a 'recommendation' level in v1
(i.e. request a font, get what you get - similar to HTML).
- Should ideally support size queries and specifications from the user code.
- v1 will be somewhat limited in this area, but future expansion is
expected.
- Next steps:
- Mid November meeting, in the Redmond area with representative from Cinder +
SG13
- Potential teleconferences as needed in between
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
