[Cuis-dev] Adding Single Font / Morphic Update

Phil B pbpublist at gmail.com
Sat Jan 25 10:05:20 PST 2020


Juan,

Words can't express you how happy your answer makes me!  I too wish we
could assume higher spec hardware.  But here we are in 2020 and I will soon
be buying a new device that is only OpenGL ES 2.0 capable... <sigh>  Wish
the options were better than what they are for what I want.

Thanks,
Phil

On Sat, Jan 25, 2020 at 9:16 AM Juan Vuletich <juan at jvuletich.org> wrote:

> Hi Phil,
>
> On 1/24/2020 4:48 PM, Phil B wrote:
>
> Juan,
>
> On Thu, Jan 23, 2020 at 2:15 PM Juan Vuletich via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
>
>> The high performance OpenCL implementation of the VectorGraphics engine
>> is in the works. As I usually say at this time of the year, maybe this
>> is the year it will become usable enough to completely replace
>> BitBltCanvas and BitBltCanvasEngine... You can see the commits that
>> affect VectorGraphics.pck.st in GitHub, and see that I'm actually
>> working on it.
>>
>>
> By 'completely replace' I hope you mean 'become the default, but still be
> able to live alongside'.
>
>
> Maybe not even that. By 'completely replace' I mean stop using
> BitBltCanvas and Engine in your image / application if you choose to switch
> to the VectorCanvas and Engine.
>
> Ideally, the kernel image should be headless. Morphic should be an
> installable package, requiring some pair of Canvas+Engine. It might be
> BitBlt, Vector, OpenGL, Cairo or any other graphics backend we might build.
> And maybe we can build a ST-80 style MVC as an alternative to Morphic.
> People really wanting alternatives like web-based GUIs, or native widgets
> should be able to build the appropriate libraries and not be forced to have
> Morphic present if that's what they want.
>
> Still, the default image might be BitBlt based... That's stuff we need to
> discuss. It would be great to build the images we use (that include dev
> tools) based on smaller ones. Or even a full bootstrap from sources.
>
> One of the things I've been hoping we end up with is a more (wait for
> it...) modular drawing system.  It would be great to be able to switch
> between graphics systems and/or have a worlds-like environment where the
> top level could be one drawing system and one of the children another.
>
>
> Yep. Exactly.
>
> Just think how much easier your new Morphic would have been to develop
> (and would be to debug/enhance going forward) if you had that as a starting
> point.
>
>
> Well, that's actually sort of what I did. I renamed the existing hierarchy
> as OldXXXMorph, built the new one, switched to it, and deleted the old one.
> This was a looong time ago!
>
> And then there are the low power/low capability devices that don't even
> have full JIT support yet, let alone OpenCL capable hardware. (lots of ARM
> stuff and some old/low-end PCs fall into this category)
>
>
> Of course. Although I'd love to be able to assume OpenCL is present (not
> just for the graphics engine, but also for FloatArray and other numerics
> and signal processing stuff), I know this is not the case.
>
> Cheers,
>>
>> --
>> Juan Vuletich
>>
>>
> Thanks,
> Phil
>
>
> Thanks,
>
> --
> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200125/caf1b62d/attachment.htm>


More information about the Cuis-dev mailing list