[Development] Fwd: [graphics] SG13 Chicago Meeting Minutes

[Thiago Macieira]

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 <jzink_1 at yahoo.com>
Para: graphics at isocpp.org <graphics at isocpp.org>

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 graphics+unsubscribe at isocpp.org.
To post to this group, send email to graphics at isocpp.org.
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
-------------- next part --------------
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130928/15dabd20/attachment.sig>