Anyway, implementing a Athens backend from scratch is a really hard problem, because paths can be concave, curve and self intersecting. Drawing a path, unlike drawing a triangle is a global operation, for which GPUs were not designed for. The easiest and most robust technique for drawing a path using the GPU is to flatten the path using De Casteljau's algorithm and then using the stencil buffer technique for drawing concave polygons that was described in the OpenGL red book ( http://www.glprogramming.com/red/chapter14.html#name13 ). The problem of this technique is that involves many state changes(glStencil*) and drawing commands(glDrawElements) per path, which are the most expensive operations when using OpenGL. The alternative is to perform a triangulation in the CPU of paths, or to use one of the newer low level APIs such as Vulkan and Direct 3D 12 which were designed to reduce or eliminate the cost of state changes and drawing commands.
Path stroking is an even harder problem, which I have not solved yet. The standard approach is to convert a stroked path into a path that can be filled. The problem is that bezier offset curves are not bezier curves, so they have to be approximated. Fortunately, since this operation is backend agnostic, it can be used and reused by many Athens backends. Since stroking is not critical for my needs, I do not think I will implement it soon properly. Currently I am just drawing a 1 pixel thick line, which can look horrible, but is better than nothing. One algorithm that seems to be simple to implement is one described in a paper from the Cairo people, which uses the Minkowksi Sum between the outline of the path to be stroked, and shape of the pen that is stroking the path: http://keithp.com/~keithp/talks/cairo2003.pdf <http://keithp.com/%7Ekeithp/talks/cairo2003.pdf>
Thanks because indeed this is a lot of work. Thanks for the reality check.
Soon I will merge the Lowcode instructions into the SqueakVM/Cog VM to integrate these bytecodes into the mainline VM.
I will not publish Woden 2 until the dependencies and Woden 2 itself can be loaded easily. Soon I will publish properly the Dastrel shader language and the Slovim backend. Slovim name comes from Smalltalk Low levelish VIrtual Machine, an intermediate representation heavily modeled after the one used in LLVM, implemented in Pharo, some very basic optimizations(basic constant folding, inlining and some dead code generation), and a code generator backend for SpirV, GLSL and C++. My biggest issue before publishing this compiler are: - Implementing a command line interface. - Doing an easy to install and use package for Linux, OS X and Windows. - Documenting the language and the compiler.
Best regards, Ronie
2016-07-28 19:31 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>>:
I would love to see an athens back-end for it.
Isn't it what Ronie is working on?
Alexandre
Le 19/7/16 à 13:19, Thibault Raffaillac a écrit :
Hi all,
My tiny binding for OpenGLES2 is ready :) http://smalltalkhub.com/#!/~ThibaultRaffaillac/OpenGLES2/ <http://smalltalkhub.com/#%21/%7EThibaultRaffaillac/OpenGLES2/>
It takes a different direction than that of NBOpenGL. I found the support for all versions of OpenGL overwhelming, both for beginners and to maintain. With a limited number of functions I could carefully name all messages.
A demo using either SDL2 or GLFW (faster) is included, supporting VSync and retina displays. Tested only on Mac OSX, patches welcome!
Cheers, Thibault