A setof thoughts from'offscreen'.  I think a useful starting point is
whatis  graphics for? It
has a big bearing 2/3D is an obvious distinction. However.
Is GPU& shader  support necessary/desirable:
yes if real-time rendering for thighs like games/VR are important, but in
that case there
is a bigger problem jitter caused by GC,
no if the main driver is application like a GUI. visualisation.
Looking at the history of Smalltalk and graphics in ST the best results
have been where there
has been parsimony between the drover, ST the language & ST the platform:
-BitBlt which was driven by the aims  of the LRG  and early applications.
what is the vision today?
-Moose/Pharao driven by data vis applications
-Croquet driven by a vision of collaborative VR
Trying to be all things to all users might be a nice vision but the
result may be unusable by any one
constituency.
Other issues:
what about input: morphic, tea-time, or something akin to FRP?
what about other Media(sound, video)

I like theidea of not having a blackboc so that you canunderstand/ the
process, Balloon was a nice idea.
However I found it difficult to pick up as the documentation was sparse,
Other platforms to consider for inspiration:
- OpenGL was not the first graphics standard, There was also PHIGS and GKS,
whilst dated these had some useful ideas,
e.g. PHIGS's structures and the ability to edit these. Their input handling
via device abstractions was an improvement on their successors

- VTK The 'Visualization Tool kit' is an Object-Oriented Approach to3
graphics that has had some success in the (scientific)visualisation
 community
If you want to also support other media, then PREMO
(Presentation Environment for Multimedia Objects) might have some ideas
that are worth looking at,
It is anISO/SC24 Standard that was designed with OOP in mind as the
baseline for implementation( arguably premature). I'm familiar with  it as
I worked
on it for some years. Again comes back to that question of what is the goal
and use cases?

The Nile work looks cool, would be nice to incorporate it or at least leave
the door open.

Background. An occassional Squeak user. I did once try to use squeak for
vis, explorong  VTK-like system in Squeak.
However I backed out in part due to lack of documentation, and not the
 right platform community for the community I was working with.
Over the last two decades I've spent time working largely in pure FP
(Haskell) doing large-scale vis.


I'd be interested in tracking any effort and possibly contributing.

--David












-

-


On Tue, Jun 30, 2020 at 12:15 AM Eric Gade <eric.gade at gmail.com> wrote:

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

-- 
David Duke
Professor of Computer Science
School of Computing University of Leeds UK
E:duke.j.david at gmail.com
W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200630/d644d9d1/attachment.html>