Hi everyone,

I am of particularly low expertise in these matters, but in the grand
tradition of online discourse I thought I'd chime in anyway.


> 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.
>

Not sure if everyone keeps up with the guys on the other side of the
tracks, but the Bloc library in Pharo took the approach of using Skia
<https://skia.org/> (originally it used Moz2D). A lot of work went into it,
and a year or two ago I was able to get some interesting things up in my
own experiments. This work is now no longer being done on the mainline
branch, but instead as part of the Feenk GToolkit project. I'm not sure if
or when the Pharo people will pick it up for incorporation.

When talking about incorporating 3rd party libraries, do we mean as VM
plugins or through FFI? Is there some advantage of one over the other? On
an unrelated thread (in which I posted off-topic, shame) I mentioned that
Vulkan provides a complete XML description of its API
<https://github.com/KhronosGroup/Vulkan-Docs/blob/master/xml/vk.xml>,
which, as far as I'm able to understand these things, means the enormous
pain of creating FFI bindings is somewhat ameliorated here. That said, I
don't really know anything about Vulkan other than the fact it's supposed
to be the "next generation" graphics api from the same producers that
brought us *OpenGL* and *OpenGL 2: The Reckoning*.

On Sun, Jun 28, 2020 at 11:01 PM Jecel Assumpcao Jr <jecel at merlintec.com>
> wrote:
>


> 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.
>

Nile seems like a fascinating option and I've tried to read as much about
it as I can. Unfortunately aside from the various posted talks online and
the VPRI papers, there's not a lot of information about using it (unless I
am missing something -- you can track a github issue about its status here
<https://github.com/damelang/nile/issues/3>). My guess is that the Gezira
part, of which there is even less information, is very closely tied to the
specific Frank environment in which it was used -- is that correct? Using
plain Squeak how would one even incorporate Nile?

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.
>

One thing about Squeak and friends that is very nice is the way it can
abstract over essential "kinds" of activity in the computer. For example,
the global `Processor` class manages everything I really need from my
actual computer's processor: scheduling different things to run and then
doing so, while providing me a no-nonsense interface into itself. The
current BitBlt graphics stack is also a sweet-spot abstraction for the
kinds of graphics it's working with. Once you dig down and get the hang of
bits, forms, and canvases, it all comes together in a delightfully lively
way. I see what Jecel is saying here and I think it's a worthy goal -- what
would be the equivalent of the `Processor` global for the GPU (even in
cases where the actual machine doesn't have a "real" GPU)?
-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200629/38f50a02/attachment-0001.html>