<div dir="ltr"><div>Hi everyone,</div><div><br></div><div>I am of particularly low expertise in these matters, but in the grand tradition of online discourse I thought I'd chime in anyway.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Tim Rowledge wrote on Sun, 28 Jun 2020 17:53:21 -0700<br>
> Seriously. We've been sitting around twiddling thumbs about better graphics for decades now. <br>
> <br>
> We had Balloon2D & 3D.<br>
> We had 'Pooh graphics' to do vector forms.<br>
> We have some excellent stuff being done by the Cuis crew.<br>
> We have some amazing ideas from Nile/Gezira.<br>
> We have a number of potential 3rd party graphics libraries we might adopt.<br>
> 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.<br>
> We probably have other options I've not even heard of.</div></blockquote><div><br></div><div>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 <a href="https://skia.org/">Skia</a> (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.</div><div>  </div><div>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 <a href="https://github.com/KhronosGroup/Vulkan-Docs/blob/master/xml/vk.xml">complete XML description of its API</a>, 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 <i>OpenGL</i> and <i>OpenGL 2: The Reckoning</i>.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Sun, Jun 28, 2020 at 11:01 PM Jecel Assumpcao Jr <<a href="mailto:jecel@merlintec.com">jecel@merlintec.com</a>> wrote:</div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Nile/Gezira + JIT would be my vote, but it has been planned for a long<br>
time and, as far as I know, is not happening right now.</div></blockquote><div><br></div><div>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 <a href="https://github.com/damelang/nile/issues/3">github issue about its status here</a>). 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?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Though the survey I did for the Board pointed to OpenGL ES as our best<br>
option (at the time, things have changed since), it is not something I<br>
personally like. I want something that is not a black box so I can<br>
single step from the highest level to individual pixels when debugging<br>
issues. But I also want it to take advantage of all available resources<br>
(including GPUs, extra processors) by translating debugged code into<br>
something else. I just don't want to debug in that something else, which<br>
would be the case for OpenGL ES shaders.</div></blockquote><div><br></div><div>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)? <br></div><div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Eric</div></div></div></div></div>