[9fans] Understanding /dev/draw

[9fans] Understanding /dev/draw

[Chris McGee]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

Hi All,

I'm looking at creating an alternate filesystem for /dev/draw, /dev/mouse
and /dev/kbd that hooks up to a web server providing HTML interfaces (e.g.
canvas) for Plan 9 UI. I've been reading over the manual pages, which are
quite detailed, which is great, but there are some points of confusion for
me.

In particular, /dev/draw's interface and documentation keep referring to
the concept of a "window" indirectly. It seems that in some cases the
server providing /dev/draw needs to track windows and refresh them. But,
what defines a window in this protocol? Is every image a window or only
some of them?

Also, I'm trying to understand how off-screen images, such as fonts are
loaded. It seems that every image must be associated with a screen and be
given a position within the screen. So, how do you prevent the image from
being visible to the user?

Hopefully, if I can understand some of the high-level concepts here then
the manual page will be all that I need. Does anyone have experience with
this area or could point me to information that might help clarify it?

My next step will probably be to figure out how libmemdraw does all of this
on top of a frame buffer.

Thanks,
Chris

[-- Attachment #2: Type: text/html, Size: 1424 bytes --]

Re: [9fans] Understanding /dev/draw

[Lucio De Re]

Whatever you do, do not start with Linux-type assumptions, or MIT-X
assumptions. They will cripple your understanding.

Everything is in the man pages, except the actual device driver,
/dev/draw. VGA, if I understand your interest, you will be spared.

I never quite understood everything involved in the Plan 9 graphics,
but it all looked quite manageable.

Lucio.


On 4/18/19, Chris McGee <newton688@gmail.com> wrote:
> Hi All,
>
> I'm looking at creating an alternate filesystem for /dev/draw, /dev/mouse
> and /dev/kbd that hooks up to a web server providing HTML interfaces (e.g.
> canvas) for Plan 9 UI. I've been reading over the manual pages, which are
> quite detailed, which is great, but there are some points of confusion for
> me.
>
> In particular, /dev/draw's interface and documentation keep referring to
> the concept of a "window" indirectly. It seems that in some cases the
> server providing /dev/draw needs to track windows and refresh them. But,
> what defines a window in this protocol? Is every image a window or only
> some of them?
>
> Also, I'm trying to understand how off-screen images, such as fonts are
> loaded. It seems that every image must be associated with a screen and be
> given a position within the screen. So, how do you prevent the image from
> being visible to the user?
>
> Hopefully, if I can understand some of the high-level concepts here then
> the manual page will be all that I need. Does anyone have experience with
> this area or could point me to information that might help clarify it?
>
> My next step will probably be to figure out how libmemdraw does all of this
> on top of a frame buffer.
>
> Thanks,
> Chris
>


--
Lucio De Re
2 Piet Retief St
Kestell (Eastern Free State)
9860 South Africa

Ph.: +27 58 653 1433
Cell: +27 83 251 5824
FAX: +27 58 653 1435

Re: [9fans] Understanding /dev/draw

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

This might be a good place to start:

https://bitbucket.org/dhoskin/9webdraw/src/default/

On Thu, Apr 18, 2019 at 7:36 AM Chris McGee <newton688@gmail.com> wrote:

> Hi All,
>
> I'm looking at creating an alternate filesystem for /dev/draw, /dev/mouse
> and /dev/kbd that hooks up to a web server providing HTML interfaces (e.g.
> canvas) for Plan 9 UI. I've been reading over the manual pages, which are
> quite detailed, which is great, but there are some points of confusion for
> me.
>
> In particular, /dev/draw's interface and documentation keep referring to
> the concept of a "window" indirectly. It seems that in some cases the
> server providing /dev/draw needs to track windows and refresh them. But,
> what defines a window in this protocol? Is every image a window or only
> some of them?
>
> Also, I'm trying to understand how off-screen images, such as fonts are
> loaded. It seems that every image must be associated with a screen and be
> given a position within the screen. So, how do you prevent the image from
> being visible to the user?
>
> Hopefully, if I can understand some of the high-level concepts here then
> the manual page will be all that I need. Does anyone have experience with
> this area or could point me to information that might help clarify it?
>
> My next step will probably be to figure out how libmemdraw does all of
> this on top of a frame buffer.
>
> Thanks,
> Chris
>

[-- Attachment #2: Type: text/html, Size: 1962 bytes --]

Re: [9fans] Understanding /dev/draw

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

I've been hoping someone would resurrect this project, especially given
that Typescript and Go (wasm) are both much better options for implementing
it.

On Thu, Apr 18, 2019 at 8:25 AM Skip Tavakkolian <skip.tavakkolian@gmail.com>
wrote:

> This might be a good place to start:
>
> https://bitbucket.org/dhoskin/9webdraw/src/default/
>
> On Thu, Apr 18, 2019 at 7:36 AM Chris McGee <newton688@gmail.com> wrote:
>
>> Hi All,
>>
>> I'm looking at creating an alternate filesystem for /dev/draw, /dev/mouse
>> and /dev/kbd that hooks up to a web server providing HTML interfaces (e.g.
>> canvas) for Plan 9 UI. I've been reading over the manual pages, which are
>> quite detailed, which is great, but there are some points of confusion for
>> me.
>>
>> In particular, /dev/draw's interface and documentation keep referring to
>> the concept of a "window" indirectly. It seems that in some cases the
>> server providing /dev/draw needs to track windows and refresh them. But,
>> what defines a window in this protocol? Is every image a window or only
>> some of them?
>>
>> Also, I'm trying to understand how off-screen images, such as fonts are
>> loaded. It seems that every image must be associated with a screen and be
>> given a position within the screen. So, how do you prevent the image from
>> being visible to the user?
>>
>> Hopefully, if I can understand some of the high-level concepts here then
>> the manual page will be all that I need. Does anyone have experience with
>> this area or could point me to information that might help clarify it?
>>
>> My next step will probably be to figure out how libmemdraw does all of
>> this on top of a frame buffer.
>>
>> Thanks,
>> Chris
>>
>

[-- Attachment #2: Type: text/html, Size: 2523 bytes --]

Re: [9fans] Understanding /dev/draw

[Chris McGee]

[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]

Thanks, this looks to be exactly what I was hoping to do. The idea wasn't
as original as I thought.

On Thu, Apr 18, 2019 at 11:27 AM Skip Tavakkolian <
skip.tavakkolian@gmail.com> wrote:

> This might be a good place to start:
>
> https://bitbucket.org/dhoskin/9webdraw/src/default/
>
> On Thu, Apr 18, 2019 at 7:36 AM Chris McGee <newton688@gmail.com> wrote:
>
>> Hi All,
>>
>> I'm looking at creating an alternate filesystem for /dev/draw, /dev/mouse
>> and /dev/kbd that hooks up to a web server providing HTML interfaces (e.g.
>> canvas) for Plan 9 UI. I've been reading over the manual pages, which are
>> quite detailed, which is great, but there are some points of confusion for
>> me.
>>
>> In particular, /dev/draw's interface and documentation keep referring to
>> the concept of a "window" indirectly. It seems that in some cases the
>> server providing /dev/draw needs to track windows and refresh them. But,
>> what defines a window in this protocol? Is every image a window or only
>> some of them?
>>
>> Also, I'm trying to understand how off-screen images, such as fonts are
>> loaded. It seems that every image must be associated with a screen and be
>> given a position within the screen. So, how do you prevent the image from
>> being visible to the user?
>>
>> Hopefully, if I can understand some of the high-level concepts here then
>> the manual page will be all that I need. Does anyone have experience with
>> this area or could point me to information that might help clarify it?
>>
>> My next step will probably be to figure out how libmemdraw does all of
>> this on top of a frame buffer.
>>
>> Thanks,
>> Chris
>>
>

[-- Attachment #2: Type: text/html, Size: 2476 bytes --]

Re: [9fans] Understanding /dev/draw

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]

Improving or reimplementing it better are just as important as originality.

On Thu, Apr 18, 2019 at 9:51 AM Chris McGee <newton688@gmail.com> wrote:

> Thanks, this looks to be exactly what I was hoping to do. The idea wasn't
> as original as I thought.
>
> On Thu, Apr 18, 2019 at 11:27 AM Skip Tavakkolian <
> skip.tavakkolian@gmail.com> wrote:
>
>> This might be a good place to start:
>>
>> https://bitbucket.org/dhoskin/9webdraw/src/default/
>>
>> On Thu, Apr 18, 2019 at 7:36 AM Chris McGee <newton688@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> I'm looking at creating an alternate filesystem for /dev/draw,
>>> /dev/mouse and /dev/kbd that hooks up to a web server providing HTML
>>> interfaces (e.g. canvas) for Plan 9 UI. I've been reading over the manual
>>> pages, which are quite detailed, which is great, but there are some points
>>> of confusion for me.
>>>
>>> In particular, /dev/draw's interface and documentation keep referring to
>>> the concept of a "window" indirectly. It seems that in some cases the
>>> server providing /dev/draw needs to track windows and refresh them. But,
>>> what defines a window in this protocol? Is every image a window or only
>>> some of them?
>>>
>>> Also, I'm trying to understand how off-screen images, such as fonts are
>>> loaded. It seems that every image must be associated with a screen and be
>>> given a position within the screen. So, how do you prevent the image from
>>> being visible to the user?
>>>
>>> Hopefully, if I can understand some of the high-level concepts here then
>>> the manual page will be all that I need. Does anyone have experience with
>>> this area or could point me to information that might help clarify it?
>>>
>>> My next step will probably be to figure out how libmemdraw does all of
>>> this on top of a frame buffer.
>>>
>>> Thanks,
>>> Chris
>>>
>>

[-- Attachment #2: Type: text/html, Size: 2922 bytes --]

Re: [9fans] Understanding /dev/draw

[erik quanstrom]

[-- Attachment #1: Type: text/html, Size: 3300 bytes --]

Re: [9fans] Understanding /dev/draw

[hiro]

> In particular, /dev/draw's interface and documentation keep referring to
> the concept of a "window" indirectly. It seems that in some cases the
> server providing /dev/draw needs to track windows and refresh them. But,
> what defines a window in this protocol? Is every image a window or only
> some of them?

i'm not aware of "window"s on that layer, what specifically do you
mean with indirectly?

perhaps you mean layers? they can be put to "top" and "bottom".

> Also, I'm trying to understand how off-screen images, such as fonts are
> loaded. It seems that every image must be associated with a screen and be
> given a position within the screen. So, how do you prevent the image from
> being visible to the user?

on-screen images actually seem less intuitive, i don't know what makes
you think they have to be associated with a screen. they don't have
to, commonly aren't (though there will be a main screenimage for each
rio window for example (which will point to the same memory data in
the back though!)).

How do you make it visible to the user would be the correct question.

> Hopefully, if I can understand some of the high-level concepts here then
> the manual page will be all that I need. Does anyone have experience with
> this area or could point me to information that might help clarify it?

Perhaps start with the good old bitblt documentation. it's smaller and
doesn't have most of the less obvious features.
devdraw is a lot more convoluted and the way it interacts with
/dev/mouse and /dev/winname for example is extremely non-intuitive and
a lot of back and forth.

Have fun.

Re: [9fans] Understanding /dev/draw

[Chris McGee]

[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]

Hi All,

I managed to get it running after all of these years. In case anyone tries
it again here's a few things that I had to do to get it to work on the
latest 9front.

* Copy the latin1.h header file from the bell labs distribution and copy it
into /sys/src/9/port
* Run ip/httpd/httpd -w /sys/web/9wd (this is where the installation copies
the web app)
* Patch /usr/web/9wd/js/draw/data.js by commenting out the "delete
conn.imgs[id];" line
    * Future draw commands come in referring to the old image for some
reason and the server doesn't handle it well

Yes, when I coerce the websocket tool to launch rio instead of acme there's
some oddness when I launch new graphical apps within rio from the windows,
such as acme. They tend to think that they should occupy the entire screen.
Also, be patient because it is quite slow for now.

Does anyone know if David is still active in this space?

Erik, where can I learn more about the layers?

Thanks,
Chris

On Thu, Apr 18, 2019 at 2:08 PM erik quanstrom <quanstro@quanstro.net>
wrote:

> this implementation is enough to run acme,but not a full p9 terminal.
> you'll need layers for that.
>

[-- Attachment #2: Type: text/html, Size: 1684 bytes --]

Re: [9fans] Understanding /dev/draw

[Joseph Stewart]

[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]

I'm greedily watching this space... if you need testers, please let me
know. I have an interest in how/if this could be applied to Inferno was
well.

On Thu, Apr 18, 2019 at 12:05 PM Chris McGee <newton688@gmail.com> wrote:

> Hi All,
>
> I managed to get it running after all of these years. In case anyone tries
> it again here's a few things that I had to do to get it to work on the
> latest 9front.
>
> * Copy the latin1.h header file from the bell labs distribution and copy
> it into /sys/src/9/port
> * Run ip/httpd/httpd -w /sys/web/9wd (this is where the installation
> copies the web app)
> * Patch /usr/web/9wd/js/draw/data.js by commenting out the "delete
> conn.imgs[id];" line
>     * Future draw commands come in referring to the old image for some
> reason and the server doesn't handle it well
>
> Yes, when I coerce the websocket tool to launch rio instead of acme
> there's some oddness when I launch new graphical apps within rio from the
> windows, such as acme. They tend to think that they should occupy the
> entire screen. Also, be patient because it is quite slow for now.
>
> Does anyone know if David is still active in this space?
>
> Erik, where can I learn more about the layers?
>
> Thanks,
> Chris
>
> On Thu, Apr 18, 2019 at 2:08 PM erik quanstrom <quanstro@quanstro.net>
> wrote:
>
>> this implementation is enough to run acme,but not a full p9 terminal.
>> you'll need layers for that.
>>
>

[-- Attachment #2: Type: text/html, Size: 2292 bytes --]

Re: [9fans] Understanding /dev/draw

[erik quanstrom]

[-- Attachment #1: Type: text/html, Size: 2021 bytes --]

Re: [9fans] Understanding /dev/draw

[David Hoskin]

> Does anyone know if David is still active in this space?

Hi Chris,

I'm still lurking the list, but I haven't touched this code in years.
The basic drawing ops are alright but layers are maybe quarter baked.
All of it is hacky student code written in a sort of lowest common
denominator of Javascript in the style of C.

That's cool that you were actually able to run it!

-- David

Sorry on behalf of my mail server:


***  Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

Re: [9fans] Understanding /dev/draw

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]

Joseph, others, have you thought about Dis-to-wasm JIT?  I recall
Charles/Vita Nuova doing a browser plugin a few years ago, but things could
be a lot simpler now. HTML5 also has storage api's; a lot of local
resources can be available via 9p/sytx (devdraw, fs, cons)


On Thu, Apr 18, 2019 at 12:55 PM Joseph Stewart <joseph.stewart@gmail.com>
wrote:

> I'm greedily watching this space... if you need testers, please let me
> know. I have an interest in how/if this could be applied to Inferno was
> well.
>
> On Thu, Apr 18, 2019 at 12:05 PM Chris McGee <newton688@gmail.com> wrote:
>
>> Hi All,
>>
>> I managed to get it running after all of these years. In case anyone
>> tries it again here's a few things that I had to do to get it to work on
>> the latest 9front.
>>
>> * Copy the latin1.h header file from the bell labs distribution and copy
>> it into /sys/src/9/port
>> * Run ip/httpd/httpd -w /sys/web/9wd (this is where the installation
>> copies the web app)
>> * Patch /usr/web/9wd/js/draw/data.js by commenting out the "delete
>> conn.imgs[id];" line
>>     * Future draw commands come in referring to the old image for some
>> reason and the server doesn't handle it well
>>
>> Yes, when I coerce the websocket tool to launch rio instead of acme
>> there's some oddness when I launch new graphical apps within rio from the
>> windows, such as acme. They tend to think that they should occupy the
>> entire screen. Also, be patient because it is quite slow for now.
>>
>> Does anyone know if David is still active in this space?
>>
>> Erik, where can I learn more about the layers?
>>
>> Thanks,
>> Chris
>>
>> On Thu, Apr 18, 2019 at 2:08 PM erik quanstrom <quanstro@quanstro.net>
>> wrote:
>>
>>> this implementation is enough to run acme,but not a full p9 terminal.
>>> you'll need layers for that.
>>>
>>

[-- Attachment #2: Type: text/html, Size: 2880 bytes --]

Re: [9fans] Understanding /dev/draw

[Joseph Stewart]

[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]

Skip/all: there's a lot I think about especially surrounding plan9 and
Inferno. Sadly little action results.

On Thu, Apr 18, 2019 at 2:52 PM Skip Tavakkolian <skip.tavakkolian@gmail.com>
wrote:

> Joseph, others, have you thought about Dis-to-wasm JIT?  I recall
> Charles/Vita Nuova doing a browser plugin a few years ago, but things could
> be a lot simpler now. HTML5 also has storage api's; a lot of local
> resources can be available via 9p/sytx (devdraw, fs, cons)
>
>
> On Thu, Apr 18, 2019 at 12:55 PM Joseph Stewart <joseph.stewart@gmail.com>
> wrote:
>
>> I'm greedily watching this space... if you need testers, please let me
>> know. I have an interest in how/if this could be applied to Inferno was
>> well.
>>
>> On Thu, Apr 18, 2019 at 12:05 PM Chris McGee <newton688@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> I managed to get it running after all of these years. In case anyone
>>> tries it again here's a few things that I had to do to get it to work on
>>> the latest 9front.
>>>
>>> * Copy the latin1.h header file from the bell labs distribution and copy
>>> it into /sys/src/9/port
>>> * Run ip/httpd/httpd -w /sys/web/9wd (this is where the installation
>>> copies the web app)
>>> * Patch /usr/web/9wd/js/draw/data.js by commenting out the "delete
>>> conn.imgs[id];" line
>>>     * Future draw commands come in referring to the old image for some
>>> reason and the server doesn't handle it well
>>>
>>> Yes, when I coerce the websocket tool to launch rio instead of acme
>>> there's some oddness when I launch new graphical apps within rio from the
>>> windows, such as acme. They tend to think that they should occupy the
>>> entire screen. Also, be patient because it is quite slow for now.
>>>
>>> Does anyone know if David is still active in this space?
>>>
>>> Erik, where can I learn more about the layers?
>>>
>>> Thanks,
>>> Chris
>>>
>>> On Thu, Apr 18, 2019 at 2:08 PM erik quanstrom <quanstro@quanstro.net>
>>> wrote:
>>>
>>>> this implementation is enough to run acme,but not a full p9 terminal.
>>>> you'll need layers for that.
>>>>
>>>

[-- Attachment #2: Type: text/html, Size: 3550 bytes --]

Re: [9fans] Understanding /dev/draw

[hiro]

hmm? what would you like, please tell us more

On 4/19/19, Joseph Stewart <joseph.stewart@gmail.com> wrote:
> Skip/all: there's a lot I think about especially surrounding plan9 and
> Inferno. Sadly little action results.
>
> On Thu, Apr 18, 2019 at 2:52 PM Skip Tavakkolian
> <skip.tavakkolian@gmail.com>
> wrote:
>
>> Joseph, others, have you thought about Dis-to-wasm JIT?  I recall
>> Charles/Vita Nuova doing a browser plugin a few years ago, but things
>> could
>> be a lot simpler now. HTML5 also has storage api's; a lot of local
>> resources can be available via 9p/sytx (devdraw, fs, cons)
>>
>>
>> On Thu, Apr 18, 2019 at 12:55 PM Joseph Stewart
>> <joseph.stewart@gmail.com>
>> wrote:
>>
>>> I'm greedily watching this space... if you need testers, please let me
>>> know. I have an interest in how/if this could be applied to Inferno was
>>> well.
>>>
>>> On Thu, Apr 18, 2019 at 12:05 PM Chris McGee <newton688@gmail.com>
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I managed to get it running after all of these years. In case anyone
>>>> tries it again here's a few things that I had to do to get it to work
>>>> on
>>>> the latest 9front.
>>>>
>>>> * Copy the latin1.h header file from the bell labs distribution and
>>>> copy
>>>> it into /sys/src/9/port
>>>> * Run ip/httpd/httpd -w /sys/web/9wd (this is where the installation
>>>> copies the web app)
>>>> * Patch /usr/web/9wd/js/draw/data.js by commenting out the "delete
>>>> conn.imgs[id];" line
>>>>     * Future draw commands come in referring to the old image for some
>>>> reason and the server doesn't handle it well
>>>>
>>>> Yes, when I coerce the websocket tool to launch rio instead of acme
>>>> there's some oddness when I launch new graphical apps within rio from
>>>> the
>>>> windows, such as acme. They tend to think that they should occupy the
>>>> entire screen. Also, be patient because it is quite slow for now.
>>>>
>>>> Does anyone know if David is still active in this space?
>>>>
>>>> Erik, where can I learn more about the layers?
>>>>
>>>> Thanks,
>>>> Chris
>>>>
>>>> On Thu, Apr 18, 2019 at 2:08 PM erik quanstrom <quanstro@quanstro.net>
>>>> wrote:
>>>>
>>>>> this implementation is enough to run acme,but not a full p9 terminal.
>>>>> you'll need layers for that.
>>>>>
>>>>
>

Re: [9fans] Understanding /dev/draw

[Chris McGee]

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]

Thanks David, you have saved me a bunch of work. If I were to fix/extend
the project would you be interested in the changes or should I just fork it?

On Thu, Apr 18, 2019 at 4:37 PM David Hoskin <dhoskin@fortinet.com> wrote:

> > Does anyone know if David is still active in this space?
>
> Hi Chris,
>
> I'm still lurking the list, but I haven't touched this code in years.
> The basic drawing ops are alright but layers are maybe quarter baked.
> All of it is hacky student code written in a sort of lowest common
> denominator of Javascript in the style of C.
>
> That's cool that you were actually able to run it!
>
> -- David
>
> Sorry on behalf of my mail server:
>
>
> ***  Please note that this message and any attachments may contain
> confidential and proprietary material and information and are intended only
> for the use of the intended recipient(s). If you are not the intended
> recipient, you are hereby notified that any review, use, disclosure,
> dissemination, distribution or copying of this message and any attachments
> is strictly prohibited. If you have received this email in error, please
> immediately notify the sender and destroy this e-mail and any attachments
> and all copies, whether electronic or printed. Please also note that any
> views, opinions, conclusions or commitments expressed in this message are
> those of the individual sender and do not necessarily reflect the views of
> Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and
> only a writing manually signed by Fortinet's General Counsel can be a
> binding commitment of Fortinet to Fortinet's customers or partners. Thank
> you. ***
>
>
>

[-- Attachment #2: Type: text/html, Size: 2025 bytes --]

Re: [9fans] Understanding /dev/draw

[David Hoskin]

Hi Chris, I hope it's a useful starting point for you.

I'm definitely interested in seeing any changes you make, but it might
make more sense for you to fork it.

Good luck,
-- David

--------------------
From: Chris McGee <newton688@gmail.com>
Subject: Re: [9fans] Understanding /dev/draw
Date: Thu, 18 Apr 2019 20:22:31 -0400

> Thanks David, you have saved me a bunch of work. If I were to fix/extend
> the project would you be interested in the changes or should I just fork it?
>
> On Thu, Apr 18, 2019 at 4:37 PM David Hoskin <dhoskin@fortinet.com> wrote:
>
>> > Does anyone know if David is still active in this space?
>>
>> Hi Chris,
>>
>> I'm still lurking the list, but I haven't touched this code in years.
>> The basic drawing ops are alright but layers are maybe quarter baked.
>> All of it is hacky student code written in a sort of lowest common
>> denominator of Javascript in the style of C.
>>
>> That's cool that you were actually able to run it!
>>
>> -- David
>>
>> Sorry on behalf of my mail server:


***  Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***