<div dir="ltr">On Thu, 2 Jul 2020 at 09:22, karl ramberg <<a href="mailto:karlramberg@gmail.com">karlramberg@gmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Faster, smoother graphics would be really good.<br><div class="gmail_quote"><div>At the same time I like access to everything within the image.</div><div></div></div></div><br></blockquote><div>If you could only choose one of these, which would you choose? "Access to everything within the image" is a really large anchor to attach to a graphics subsystem these days.  We have a single-threaded Smalltalk that has deep assumptions about a single memory space and a single rectangular display area of consistent properties wired in over forty years of development.  Meanwhile, modern graphics subsystems are *very* heavily parallel, use custom hardware, and you try to offload everything you can to the coprocessor because you don't want it even in your memory space.</div><div><br></div><div>If we want a teaching and learning system that can be understood and modified by a normal programmer, we keep everything in the image and accept limited facilities and slowness.  If we want something that makes use of all of the varied and wonderful capabilities of modern graphics hardware then a) what's the smallest subset we'll accept (to make it easy to port Squeak to new platforms), b) what knowledge do we require of anyone who wishes to investigate the graphics subsystem?</div><div><br></div><div>Cheers,</div><div><br></div><div>- Peter<br></div></div></div>