Hi, Vulkan support. Never with cairo. Pure OpenGL too (try to compile cairo-gl > on mac, good luck!) There is a way to compile it with quartz support. As of > version 2.7.9, *XQuartz does not provide support for high-resolution > Retina displays to X11 apps*, which run in pixel-doubled mode on > high-resolution displays. (https://bugs.freedesktop.org/ > show_bug.cgi?id=92777).
Do not rely on Vulkan for core libraries now. It is very green and it has lot of issues. For making Woden 2 with Vulkan on Linux, I had to fix and debug the Intel Vulkan driver myself. Anyway, Athens over Vulkan it is also not a problem, because I did an (incomplete) Athens backend using Woden 2. I have an abstraction for Vulkan(Linux and Windows, probably never available on apple machines), Metal(OS X and iOS) and D3D 12 (Windows, XBox One devkit). Right now I am working on getting Woden 2 working with Metal, which only works on 64 bits mode. Low-level UI framework (without widgets) consists of multiple parts: > > 1. Vector graphics library to render shapes (fill, stroke, path > builder, composition and blending operators) > 2. Font service library (to support different font formats and collect > information about local fonts installed in the system) > 3. Text layout engine (this is where glyph positioning magic happens, > link above too) > 4. Text shaping engine (for high quality text rendering, to understand > the problem => http://behdad.org/text/) > 5. Complex script library (to support ligatures, split glyphs and > other UTF8 stuff, remember https://github.com/mi > nimaxir/big-list-of-naughty-strings > <https://github.com/minimaxir/big-list-of-naughty-strings>) > 6. Image processing library (for various image effects, like gaussian > blur, morphology filter, gamma, displacement map, just to name a few) > 7. Hardware acceleration. Software rendering is nice, however, modern > UIs are full of fancy stuff that require hardware acceleration. > 8. Window and Event management library. With support of borderless and > semi-transparent windows + good support of touchpad. > 9. Custom written "Glue" library that allows all components to work > together. Since modern libs are implemented in C++ we would need to > implement C wrapper and a lot of integration tests. > 10. Make the whole beast cross platform. > > > Did I miss something? > You cannot have SVG style vectorial graphics and high performance graphics in the same time. SVG style paths are really hard to implement, and they cannot be implemented efficiently on hardware. Path filling and stroking are global operations that are best implemented using a serial software scanliner. GPUs are only able to rasterize points, lines, triangles and quads (usually decomposed in triangles). The primitives supported by GPUs only require local information, so they are very efficient to render. I do not understand why are you trying to copy the whole web rendering architecture, which is awful in terms of performance. I think that it is a far better idea to design a 2D graphics API, with the basic rendering primitives that are required for implementing a Widget toolkit, and then leave the SVG style vectorial graphics for some very special cases, such as drawing an actual SVG. This minimalistic graphics API could be implemented using Athens in the first place, then porting to OpenGL 2.0 ES for getting a performance boost, and then when there is a volunteer, it could be implemented with whatever bleeding edge or platform specific graphics API is available. The basics graphics primitives that I have in mind are the following: - Points - Lines (with width or without it) - Triangles - Convex polygons - Rounded rectangle - Circle / Ellipses - Render into a texture ( required for doing filtering) - Textured primitive - Some 2D filters, with the ability of making them optional - Text/Glyph drawing The graphics API should be explicit in terms that they could be two different memory spaces (CPU memory vs dedicated GPU memory), and that transferring resource such as textures can be very expensive. This kind of 2D graphics API could be also useful for developing 2D games using Pharo and OSWindow, an area where I am bit interested because it is far easier than a full 3D renderer. The API could be made partially stateless by passing the full description of how to render the primitives (colored or not, textured or not, 1 or 10 pixel wide lines, etc). It is impossible to make the API completely stateless, because the framebuffer where the rendering is happening by definition is not stateless ;) Best regards, Ronei 2017-01-26 20:36 GMT-03:00 Martin McClure <[email protected]>: > On 01/26/2017 02:45 PM, Aliaksei Syrel wrote: > > There are some real questions: > > > > 1. Do we need Bloc or Morphic2 or %name your favourite framework%? > > 2. How advanced and modern do you want it to be? > > 3. What technology stack do we want to use for our new graphical > framework? > > 4. What platforms and operating systems do we want to support? > > 5. How flexible technology stack should be? (some parts may change in > > the future) > > 6. Who will pay for it? > > 7. How many engineers can community afford? > > 8. Do you know how much other systems invest in graphical frameworks? > > 9. It is not a science project, isn't it? > > > > [...] > > Thanks for the analysis, Alex. It sounds like using Moz2d saves a lot of > work... > > -Martin > >
