(I was going to answer a big mail but my observations/concerns are mostly targeted by Norbert and Stef)
> On 27 Jan 2017, at 10:49, Tudor Girba <tu...@tudorgirba.com> wrote: > > Hi, > > Thanks for the detailed analysis. > > In summary, Cairo+Pango+SDL2 provide enough support to get a subset of Sparta > working that would be equivalent with the Athens that we already have. In > other words, with such a backend, when we would tell Sparta to use a blur > effect, it will simply do nothing and the image environment can continue to > work as it does now. > > I hope that everyone agrees that this is a reasonable fallback scenario that > we can count on. And I think this is in line with what Stef was saying as > well. > > With this in mind, we should also remember that the Moz2D backend works now > which means that we can now focus on Brick to close the loop and provide a > complete stack that more people can start utilizing, and we can come back to > the alternative backend later. > > Does this path to action address the worry related to the future of Sparta > backends? thanks Doru…. I think having a base system that works in all scenarios (even if we miss some features) and is easy to maintain is important. Then you can have a different backend for complex stuff (is more or less the same about Ronie’s Wooden… I love to have the possibility of doing the things Ronie do with that, but I would never target to build my UI system on top of it). Even with this simplification, I would like to know why you choose to strip a library from a project instead testing, for example Skia (I know, Skia api is not stable, and is C++ and C bindings are still unstable), but well… others maybe. And some precisions: - SDL2 do allow transparent windows and windows without decorations. https://wiki.libsdl.org/SDL_SetWindowOpacity <https://wiki.libsdl.org/SDL_SetWindowOpacity>, https://wiki.libsdl.org/SDL_CreateWindow <https://wiki.libsdl.org/SDL_CreateWindow> (and the flags section) - Cairo do allow acceleration, we need to compile it with right backend. - I disagree is a dead technology. Instead, is a very mature technology… that’s why forum is not too active (even if as far as I see, it was never too active). Yes, maybe is not in the hype, but is cool and allow us to do very nice things. - examples on images are slow because of how they are programmed, not because of cairo :) cheers! Esteban ps: instead “not doing anything” non-suported-operations could throw a notification (a silent one)? > > Cheers, > Doru > > > >> On Jan 26, 2017, at 11:45 PM, Aliaksei Syrel <alex.sy...@gmail.com> wrote: >> >> Hi >> >> (My previous email was not a joke, I don't try to troll anyone. Let tolls do >> their job in other places) >> Let's forget Moz2D for a moment :) Imagine that it does not exist. It was >> done just for fun and is even not in pharo repo. >> (https://github.com/syrel/Moz2D). We needed something that works and it was >> made investing just a few months of time of a single anonymous student >> during summer exams session and vacations. >> >> I would like to start maybe one of the most important discussion that will >> influence Pharo and will dictate how system will look like in a few years. I >> invite everyone to join this discussion, especially board and consortium >> members. Because here is where business starts. >> >> There are some real questions: >> • Do we need Bloc or Morphic2 or %name your favourite framework%? >> • How advanced and modern do you want it to be? >> • What technology stack do we want to use for our new graphical >> framework? >> • What platforms and operating systems do we want to support? >> • How flexible technology stack should be? (some parts may change in >> the future) >> • Who will pay for it? >> • How many engineers can community afford? >> • Do you know how much other systems invest in graphical frameworks? >> • It is not a science project, isn't it? >> Let me first put my two cents in. >> >> Low-level UI framework (without widgets) consists of multiple parts: >> • Vector graphics library to render shapes (fill, stroke, path builder, >> composition and blending operators) >> • Font service library (to support different font formats and collect >> information about local fonts installed in the system) >> • Text layout engine (this is where glyph positioning magic happens, >> link above too) >> • Text shaping engine (for high quality text rendering, to understand >> the problem => http://behdad.org/text/) >> • Complex script library (to support ligatures, split glyphs and other >> UTF8 stuff, remember >> https://github.com/minimaxir/big-list-of-naughty-strings) >> • Image processing library (for various image effects, like gaussian >> blur, morphology filter, gamma, displacement map, just to name a few) >> • Hardware acceleration. Software rendering is nice, however, modern >> UIs are full of fancy stuff that require hardware acceleration. >> • Window and Event management library. With support of borderless and >> semi-transparent windows + good support of touchpad. >> • 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. >> • Make the whole beast cross platform. >> >> Did I miss something? >> >> Here are some modern technologies commonly used for mentioned parts: >> • Skia, Direct2D, CoreGraphics, Cairo >> • Fontconfig, Freetype2 >> • HarfBuzz >> • Pango, OpenType >> • Graphite2, FriBidi >> • Imagemagic, SVG filters libraries >> • Vulkan, OpenGL >> • wxWidgets, QT, GTK, SDL2 >> • todo >> • todo >> Luckily Pango covers bullets 2 - 5. It indeed sounds like a great idea! >> >> Let's assume that we stop on Cairo + Pango. According to pango.com >> >> The integration of Pango with Cairo (http://cairographics.org/) provides a >> complete solution with high quality text handling and graphics rendering. >> >> According to the this potential technology stack we will have: >> • Cairo for vector graphics and rendering of basic shapes >> • Pango for text rendering >> • SDL2 for window and events management >> What we will not get: >> • Support of filters; Cairo does not support gaussian blur. 3D >> transformations, we will not be able to not implement card flip animation. >> Never reach the same performance if using platform native frameworks (e.g. >> Direct2D on windows). Cairo will not die, but there is zero progress. >> • 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). >> • Borderless or transparent window with SDL2. Also, did you notice that >> sdl2 window turns black/white while resizing? There is no way to get a >> continuous window resize event with SDL2 >> (https://bugzilla.libsdl.org/show_bug.cgi?id=2077). The issue is that events >> stop firing while user is resizing a window because main thread is blocked. >> Bug is already 3 years old. Indeed SDL2 is used for games, however how often >> do gamers resize game window? >> • Stateless API. Must have for a graphical framework like Bloc where >> canvas state is not shared between visual elements. It means that while >> rendering users must not clean the state of a canvas after every draw call. >> Bloc is not my or Glenn's or Doru's personal property. We suggest, you >> decide. It would be great if community could invest money and time in a >> working and appropriate solution. >> >> P.S. If we would not care, we would agree with you instantly and even not >> bothered ourselves trying to spend time on finding cheap solution for such a >> complex problem. >> >> P.P.S Sorry for a long email :) >> >> Cheers, >> Alex >> >> On 26 January 2017 at 21:10, Aliaksei Syrel <alex.sy...@gmail.com> wrote: >> Hi, >> >> Then we will need Cairo + SDL2 (that does not work for us) + Freetype2 (for >> fonts) + Graphite (glyphs shaping technology in order to use them within >> vector graphics engine) + cross platform OpenGL / Vulkan context/device >> provider for hardware acceleration + implement Filters for effects (blur, >> lights, color matrix filters, etc...). >> >> Without all those technologies bloc WILL progress, from 80's to 00's. Still >> decades behind :) >> >> Cheers >> >> On Jan 26, 2017 20:40, "stepharong" <stephar...@free.fr> wrote: >> I think that instead of investigating gtk (yet another library to bind and >> carry around), >> it would be smarter to have Sparta back-end using an accelerated Cairo + >> pango. >> Why? Because >> - For example Cairo will not disappear in the future (here you will >> tell me that it does not have all the full >> features.... I think that Bloc should deliver Brick first and focus >> on this because else it will stay a nice >> experiment.) >> - We do not have bench with an accelerated compiled version so no >> idea if this is good enough. >> - Cairo is about 1.5 mb vs 20Mb and it is packaged. >> >> I share the concerns of Esteban about the maintenance of such Mozz2d >> bundling and he was pretty >> clear with me, he will not maintain it nor take any responsibility about >> pharo using it. >> >> So having a Cairo Sparta back-end would be a smart move. >> Stef >> >> >> >> >> >> Hi, >> >> Thank you for the intensive set of issues you raised during the Bloc >> presentation. I think it is worthwhile addressing them more thoroughly, so >> let me start with the issue that seemed to have caused the most worries: >> Sparta & Moz2D. >> >> Please keep in mind that while I am involved to some extent in Bloc, the >> real credits for the current state go to Glenn and Alex. >> >> Moz2D (https://github.com/mozilla/moz2d, >> https://wiki.mozilla.org/Platform/GFX/Moz2D) offers an advanced backend and >> using it puts us on par with the rendering speed of a web browser, which is >> a significant added value over what we have now. >> >> However, as it was noted, it does come with a cost due to the fact that it >> is not available as standalone with only the features we are interested in. >> The vector graphics part is actually buildable out of the box. However, the >> text support needs to be extracted out of Moz2D, and this is where the >> patching scripts are used. The patches are there only for compilation >> purposes and not for features and they are applied automatically. You can >> see it here: >> https://github.com/syrel/Moz2D >> >> Alex updated recently the Moz2D version and it worked without problems. Of >> course, future changes in Moz2D might imply changes in this script as well, >> and this implies that we will need to maintain that script. And we could >> imagine applying these patches on the trunk of Moz2D to see if they work, >> and we can also imagine engaging with the Moz2D owners to see if we can find >> a middle ground. >> >> Now, let’s put this into perspective. We are currently using Athens and the >> Cairo backend. While Cairo is provided as a standalone library it has not >> seen significant advances since Mozzila shifted its focus towards Moz2D. So, >> sticking with it might not be an ideal strategy either. >> >> Furthermore, just like Athens, Sparta is an abstraction that allows us to >> switch the underlying backend should we need to. Until now we did not find a >> cross-platform backend that is as advanced and complete as Moz2D, but there >> is no reason to think that none other will appear in the future. Skia is an >> alternative but it is only a vector graphic engine without text support, so >> using it would imply to have another library for the text support. >> >> Sparta also comes with a reasonable set of tests that is aimed at testing >> the basic Moz2D functionality to make sure that the assumptions on top of >> which Sparta is built are correct. >> >> All in all, I think that the current situation is not ideal, but there is >> already enough engineering in place to actually make it work. And I >> definitely think that the potential it opens is rather significant. >> >> And, if more people look at the scripts, we might find even better and >> cheaper ways to express it. >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "We cannot reach the flow of things unless we let go." >> >> >> >> >> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing should have the right to be different." > > > > >
