On Mon, Jun 29, 2020 at 12:01:07AM -0300, Jecel Assumpcao Jr wrote:
> Tim Rowledge wrote on Sun, 28 Jun 2020 17:53:21 -0700
> > Seriously. We've been sitting around twiddling thumbs about better graphics for decades now. 
> > 
> > We had Balloon2D & 3D.
> > We had 'Pooh graphics' to do vector forms.
> > We have some excellent stuff being done by the Cuis crew.
> > We have some amazing ideas from Nile/Gezira.
> > We have a number of potential 3rd party graphics libraries we might adopt.
> > We have an advanced JIT that could be used to make on-demand graphics routines either on their own or working with pretty much any of the above.
> > We probably have other options I've not even heard of.
> 
> You didn't mention the original BitBlt and WarpBlit, which is
> understandable if your focus is on vector graphics.
> 
> > Maybe we should actually do something? Can we at least talk about it?
> 
> Though the survey I did for the Board pointed to OpenGL ES as our best
> option (at the time, things have changed since), it is not something I
> personally like. I want something that is not a black box so I can
> single step from the highest level to individual pixels when debugging
> issues. But I also want it to take advantage of all available resources
> (including GPUs, extra processors) by translating debugged code into
> something else. I just don't want to debug in that something else, which
> would be the case for OpenGL ES shaders.
> 
> Nile/Gezira + JIT would be my vote, but it has been planned for a long
> time and, as far as I know, is not happening right now.
> 
> -- Jecel
> 

During the 2017 time frame, when Jecel was serving on the Squeak Oversight
Board, we had a number of conversations on this topic and Jacel provided
some welcome insight and direction. I looked through our notes from that
time, and excerpted the following from our SOB minutes on Google docs:

Squeak board meeting 2017-04-19:
--------------------------------

Mo’ better graphics; so what about adopting Nile etc? (Bert says
unfinished and unlikely to get finished. OpenGL might be an option but
tricky to use. Juan’s Morphic3 looks fab but is nowhere near
complete so far as we can tell.)

Squeak board meeting 2017-06-07:
--------------------------------

Jecel researched OpenCL. Here are 3 plans based on that:
1) Juan is using FFI to talk to OpenCL, and "kernels" are just Smalltalk
   strings
2) we could extend Slang to have OpenCL functionality. Then it would be
   possible to debug (very sloooowly) in the normal Squeak. The .cl kernel
   code would then be generated from Slang
3) Nile (or equivalent) could be used instead of Slang and would be
   translated to Squeak for debugging and later to OpenCL for performance
   OpenGL could be an alternative to OpenCL and would work on the Raspberry Pi

Squeak board meeting 2017-08-16:
--------------------------------

Many Squeaky 3D-graphics implementations…
- OpenGL
- CroquetGL (checked out on Pi, does the OpenGL>example at 150fps)
- MorphicGL
- Athens (large, complex, system to be able to use GL, Cairo, bitblt, anything)
- Rome ( Cairo base, used in Sophie project?)
- WebGL / three.js / A-Frame via SqueakJS
- Terf stuff

Graphics conclusions, draft based on Dave's (mis)understanding:
  For future work in 3D graphics, the preferred direction is OpenGL-ES.

(Did we rule out Vulkan yet? -- Ah, bad for 2D. Nevermind, then. Apple
doesn't plan to support Vulkan since it has Metal instead)

Existing Squeak GL interfaces (generally Croquet based) are based on older
versions of OpenGL and are not our preferred direction.

We do not currently have an implementation of OpenGL-ES for Squeak, and
no people or funding are currently dedicated to the problem. Funding
and/or volunteer efforts would be welcome.